Windows Memory Sharing Permissions

Question

I developed a Windows application using shared memory --- --- memory mapped files for interprocess communication. I have a windows service that does some processing and periodically writes data to a memory mapped file. I have a separate Windows application that reads from a memory mapped file and displays information. The application works as expected in Windows XP, XP Pro, and Server 2003, but not in Vista.

I see that the data written to the memory mapped file is executed correctly by the Windows service, because I can open the file with a text editor and view the saved messages, but the consumer application cannot read from the file. It is interesting to note that if I close the consumer application and restart it, it consumes messages that were previously written to the memory mapping file.

In addition, another strange thing is that I get the same behavior when I connect to a Windows host using Remote Desktop and the consumer application is called / used through Remote Desktop. However, if I call Remote Desktop and connect to the target host console session with the following command: mstsc -v:servername /F -console , everything works fine.

So why I think the problem is with permissions. Can anyone comment on this?

EDIT:

The ACL that I use to create a memory mapped file and Mutex objects that synchronize access is as follows:

 TCHAR * szSD = TEXT("D:") TEXT("(A;;RPWPCCDCLCSWRCWDWOGAFA;;;S-1-1-0)") TEXT("(A;;GA;;;BG)") TEXT("(A;;GA;;;AN)") TEXT("(A;;GA;;;AU)") TEXT("(A;;GA;;;LS)") TEXT("(A;;GA;;;RD)") TEXT("(A;;GA;;;WD)") TEXT("(A;;GA;;;BA)"); 

I think this may be part of the problem.

Answer 1

So, I found a solution to my problem:

In Windows XP, all named kernel objects, such as mutex, semaphore, and memory mapped objects, are stored in the same namespace. Therefore, when different processes in different user sessions refer to a specific object using its name, they receive a handle to that object. However, as a precaution, Windows Terminal Services creates a separate namespace for kernel objects referenced by processes running in this session. This behavior is also integrated in Windows Vista, which is why the application does not work correctly in Vista. To clarify, I have a Windows service that runs in a null session and an application that runs in a user session, so my named objects were created in different namespaces.

A quick fix to this problem was to use the global namespace by adding “Global” to each kernel object name I used, and this did the trick.

Answer 2

The prefix "Global" may not work in shared memory. See "Impact of Session 0 Isolation on Services and Drivers in Windows Vista" for a solution.

Answer 3

What access do you open the shared memory section with? Try it with FILE_MAP_ALL_ACCESS and FILE_MAP_ALL_ACCESS your way down. Also make sure that you do not have race conditions between the manufacturer and consumers - which one creates shared memory? Make sure they are created before another tries to open it. One way is to create a section in the parent before the start of the child process - if you use the parent / child architecture.

Your child may need a Vista upgrade to access shared memory. It may also be associated with the window session that you are using. Services start in session 0 (I think), while other applications (especially if you log in via Remote Desktop) can start in another session.

Answer 4

You tried to move the file to another location. Try putting it in the Shared Documents folder, which is probably the most accessible folder in Vista.