I'm attempting to share memory between two services on a Windows Server 2008 Core box. One service is postgres running as a user created just for that purpose, and the other service is my application running as the Local System user. The issue I'm seeing is that it seems that the two services do not agree on the location of the shared memory files. The postgres service is looking at "C:\Users\<user>\AppData\Local\Temp\boost_interprocess", while my application is looking at "C:\Windows\TEMP". Diving into the code I found that it first tries to use the value of a registry key, "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common AppData", however this key doesn't exist in Windows Server 2008 R2 Core, presumably because there is no explorer.exe running on the box, and thus, no shell folders under it. When that fails, the code attempts to use the TMP environment variable, however that is dependent upon the environment that the user has setup, so the TMP variable is not guaranteed to be the same across users. Indeed in my case the TMP variable for the Local System user was "C:\Windows\TEMP", while the TMP variable for the other user was in its user folder. I'm not sure what the correct answer here is, but I have some ideas: -- The "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\Common AppData" registry key seems to exist for Windows XP, Windows Server 2008 R2 Core, and Windows 7. And according to TechNet, "The entries that appear in user User Shell Folders take precedence over those in Shell Folders." So maybe that registry key should be used instead. -- Use the ALLUSERESPROFILE variable, which is "C:\Documents and Settings\All Users" on Windows XP, and "C:\ProgramData" on Windows Server 2008 R2 Core and Windows 7. The TMP variable seems to be different for every user. -- Provide a way to tell the library what directory to use. (This doesn't exist does it?) Or hint at what library to use. -- Can/Should the code assert when the folder chosen contains a user name. Might be impracticable, but sure helpful. --- Aaron Wright