This is a follow-up to the Kernel Object Namespace and Vista post. Those previous findings were made using an administrative user in Vista. When I tried creating a ‘Session\AppName’ Mutex as a non-administrative user though, the application hung!
Just to be clear, here is how (simplified) I’m creating the Mutex:
string MutexName = @"Session\AppName";
MutexSecurity mSec = new MutexSecurity();
MutexAccessRule rule = new MutexAccessRule(
new SecurityIdentifier(WellKnownSidType.WorldSid, null),
Mutex m = new Mutex(false, mutexName, out mutexWasCreated, mSec);
The hang occurs when the Mutex is created. By hang I mean that the process just spins its wheels sucking 50-60% of the CPU and will continue until it’s killed. Based on WinDbg analysis it’s either stuck in the underlaying Win32
CreateMutex() call or
CreateMutex() is being called repeatedly. It’s probably the later.
When ‘Local\’ or ‘Global\’ are used, the Mutex is created fine! As noted before, ‘Local\’ doesn’t work for other reasons so I’m stuck using the ‘Global\’ namespace. Go figure?
Just a quick development note:
According to Kernel Object Namespaces objects can have one of three predefined prefixes — ‘Local\’, ‘Global\’, or ‘Session\’. For Win2K/XP I’ve always used the ‘Local\’ prefix, which works fine. My primary use is with a Mutex to determine that a single instance of an application is running (like here). I also use the Mutex from a system service to discover if a GUI application is available for messaging. When trying to run the some code on Vista I found that the ‘Local\’ namespace does not work when Mutex.OpenExisting() is called from a the system service which is owned by a different user (from the same user, it works fine). So it appears that the ‘Local\’ prefix in Vista has a different behavior for the client session namespace than it does in Win2K/XP.
I searched around for a solution, but was unable to find a definitive answer. I did find a post about the Private Object Namespace which alludes to Vista kernel changes, but that’s all. Here’s what I determined empirically:
The NO entries in the table mean that the namespace did not work. So, it appears that in order to support all three Windows versions I’d have to use the ‘Global\’ namespace. This is not a good solution. Unless I find another way, I’ll have to determine the OS version and select the appropriate namespace at runtime (‘Session\’ for Vista, ‘Local\’ for Win2K/XP).