I made a small hint about it was run on a terminal (meaning I’m logged in as a user on a Windows Server with Terminal Services running (just to be clear)).

The Smells

So lets look at what possible smells we can find in the code:

That application specific GUID sure seems like it can be trouble.

Hmm, the GUID is now used as the name for this Mutex. And now the last piece of the puzzle:

Ok, this sure works when I’m sitting alone on my computer with my application, but what happens when multiple users on a terminal server tries to start the same application?

The Problem

Multiple NamedPipeServerStreams with the same identifier will be tried made, and then you will get: “IOException:  All pipe instances are busy.” But shouldn’t it stop at the Mutex before it tries to make the server? After all, the named Mutex is using the same GUID as identifier as well.

It seems that the assumption that the Mutex and the named pipe operated on the same system level are flat out wrong. They don’t!

Mutexes defaults to session locality when run on terminal services and named pipes does not!

You can prefix your mutex identifier with Global\ to ensure a system wide lock even on a terminal services system, but this isn’t really what we want in this situation. We would really like all users to get a single instance each.

The Solution

With the problem identified, the solution was easy. We just incorporated the logged in username into the identifier, and everything was humming along.

Until next mystery, go solve some yourselves.

What happened? Can you spot the error?