I need a way to store a value somewhere for temporarily by say Process A. Process A can exit the after storing the value in memory. After sometime Process B comes accesses the same location of memory and read the value. I need to store in memory, because I dont want the data to persistent across reboots. But as long as the system is up, it Independent of the Process the data must be accessible. I tried MailSlots and Temporary files in windows, both seem to have problem where the process reference count drops to zero , the entities dont persist in memory. What is a suitable mechanism for this in Windows preferably using Win32 API?
Ganesh
Write a service that is started at boot time, and let it create some shared memory.
This shared memory can then be filled by process A, and process B can read it afterwards.
If your system is rebooted, the shared memory is gone and you have a fresh, new piece of shared memory.
Make sure that your service correctly 'initializes' the shared memory.
Is there a reason why the data must be resident in memory when ProcessA quits as opposed to being stored somewhere on disk? I ask as you mention temporary files which should work unless ProcessA fails in an unexpected way.
Depending on your needs a nice way to provide shared/fast/atomic data is via the ESENT API.
Try the following. I can't say I know this works, but it seems reasonable.
Create a shared memory file in the global namespace using OpenFileMapping. Then call Duplicatehandle and for the target process handle use some process that will live longer than process A. You may be able to add the handle to winlogon.exe This should stop the shared memory from being destroyed when process A terminates. Then in process B you can look up the shared memory file.
Well, I managed to a create a MailSlot on a Process which doesnt exit, the other two Processes can read and write to the MailSlot server as clients... Even if the clients exit, the Mailslot will still have the data... the MailSlot server enables me to store data in volatile memory has long as the MailSlot server process is up.. or the OS is up.. and vanishes on OS reboot... Thanks for all the ideas and help.... :)
Related
We have a serie of applications running on windows that uses file locking for protecting concurrent access to their data (shared files on network drive).
Sometimes, it seems one of these process fails to release one of these locks and everything freezes until the process is killed. Finding out who holds that lock is not always trivial (needs an admin to go on the file server and check network open files, go one workstation, find process and kill it).
We have a message queue system between the applications that is serviced by a background thread so, in theory, it would be possible to send out a message to every process asking them if they hold a lock to a specific file and if they do, mybe take an action like kill the process if the lock is held longer than a few seconds)
So, the question is: is there a way for a thread to know if a different thread of the same process holds a lock (LockFile) against a given file?
I'm not sure if there is a API to query this but a process can query itself with the LockFileEx function:
A shared lock can overlap an exclusive lock if both locks were created using the same file handle. When a shared lock overlaps an exclusive lock, the only possible access is a read by the owner of the locks.
The other thread could query and see if it can get shared access.
If you control the file format you could write the computer name and process id to the start of the file every time you take the lock. File memory mappings can view the file contents even while it is locked.
So, I wrote a program which is able to successfully read memory from most of processes using VirtualQueryEx. However, I've come across a process for which this function fails. It's not a system process, just a game process. Without Debug privileges I couldn't even open the process's handle. With them I am able to get the process's handle but still get access denied for VirtualQueryEx.
I'm not sure but maybe the process is private? If that's the case, what should I do to successfully use VirtualQueryEx function?
I've also read somewhere that I might have to suspend whole process's threads before running VirtualQueryEx, but so far I didn't need that... And when I used function Thread32First to get the first thread it gave me an error: ERROR_BAD_LENGTH...
I would be very grateful for any help in this matter!
How are you opening the process handle? From the doc:
The handle must have been opened with the PROCESS_QUERY_INFORMATION
access right, which enables using the handle to read information from
the process object.
Another possibility is that the target process and your process are different bitness (32 vs 64). In that case you either need to use MEMORY_BASIC_INFORMATION32 or something like VirtualQueryEx64 from wow64ext library.
Is there a version of CreateFileMapping or a similar function that is not reference counted? I have a situation where I would like a file mapping to stay up forever, even after terminating all processes that are using it. If I have to, I can use a service that stays up forever, but I would prefer not to.
The system I'm working on has many processes running. In the context of shared memory, some are servers and some are clients.
They create/access the shared memory through CreateFileMapping and MapViewOfFile.
I recently changed a structure on one of the clients, which led the client to attempt to map a region of shared memory which is bigger than what was created by the server process. The result is Access Denied.
My problem is, I have no idea which darn process created the memory in the first place. Is there a way of accessing such meta-information about shared memory in order to determine which server program needs to be recompiled?
To confirm, it is MapViewOfFile which is failing, with an error code of 5: Access denied.
Two types of shared memory exist: dynamic (using CreateFileMapping...your scenario) and static (memory mapping declared in PE Section(s) characteristics). One could test the existence of PE sections with shared memory characteristics on file and process level.
On the other side, the reason why MapViewOfFile failed might be other than the different sizes of mapped memory (e.g. credentials, offset of memory, ....)
My service needs to store a few bits of information (at minimum, at least 20 bits or so, but I can easily make use of more) such that
it persists across service restarts, even if the service crashed or was otherwise terminated abnormally
it does not persist across a reboot
can be read and updated with very little overhead
If I store this information in the registry or in a file, it will not get automatically emptied when the system reboots.
Now, if I were on a modern POSIX system, I would use shm_open, which would create a shared memory segment which persists across process restarts but not system reboots, and I could use shm_unlink to clean it up if the persistent data somehow got corrupted.
I found MSDN : Creating Named Shared Memory and started reimplementing pieces of it within my service; this basically uses CreateFileMapping(INVALID_HANDLE_NAME, ..., PAGE_READWRITE, ..., "Global\\my_service") instead of shm_open("/my_service", O_RDWR, O_CREAT).
However, I have a few concerns, especially centered around the lifetime of this pagefile-backed mapping. I haven't found answers to these questions in the MSDN documentation:
Does the mapping persist across reboots?
If not, does the mapping disappear when all open handles to it are closed?
If not, is there a way to remove or clear the mapping? Doesn't need to be while it's in use.
If it does persist across reboots, or does disappear when unreferenced, or is not able to be reset manually, this method is useless to me.
Can you verify or find faults in these points, and/or recommend a different approach?
If there were a directory that were guaranteed to be cleaned out upon reboot, I could save data in a temporary file there, but it still wouldn't be ideal: under certain system loads, we are encountering file open/write failures (rare, under 0.01% of the time, but still happening), and this functionality is to be used in the logging path. I would like not to introduce any more file operations here.
The shared memory mapping would not persist across reboots and it will disappear when all of its handles are closed. A memory mapping object is a kernel object - they always get deleted when the last reference to them goes away, either explicitly via a CloseHandle or when the process containing the reference exits.
Try creating a registry key with RegCreateKeyEx with REG_OPTION_VOLATILE - the data will not preserved when the corresponding hive is unloaded. This will be at system shutdown for HKLM or user logoff for HKCU.
sounds like maybe you want serialization instead of shared memory? If that is indeed appropriate for your application, the way you serialize will depend on your language. If you're using c++, check out boost::serialize. C# undoubtedly has lots of serializations options (like java), if that's what you're using.