Just to be clear, here is how (simplified) I’m creating the Mutex:

string MutexName = @"Session\AppName";
bool mutexWasCreated;
MutexSecurity mSec = new MutexSecurity();
MutexAccessRule rule = new MutexAccessRule(
      new SecurityIdentifier(WellKnownSidType.WorldSid, null),
      MutexRights.FullControl,AccessControlType.Allow);
mSec.AddAccessRule(rule);
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?

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).