Using mutex objects windows

An abandoned mutex often indicates a serious error in the code. When a thread exits without releasing the mutex, the data structures protected by the mutex might not be in a consistent state. The next thread to request ownership of the mutex can handle this exception and proceed, if the integrity of the data structures can be verified.

In the case of a system-wide mutex, an abandoned mutex might indicate that an application has been terminated abruptly for example, by using Windows Task Manager.

Mutexes are of two types: local mutexes, which are unnamed, and named system mutexes. A local mutex exists only within your process. It can be used by any thread in your process that has a reference to the Mutex object that represents the mutex. Each unnamed Mutex object represents a separate local mutex. Named system mutexes are visible throughout the operating system, and can be used to synchronize the activities of processes.

You can create a Mutex object that represents a named system mutex by using a constructor that accepts a name. The operating-system object can be created at the same time, or it can exist before the creation of the Mutex object.

You can create multiple Mutex objects that represent the same named system mutex, and you can use the OpenExisting method to open an existing named system mutex.

On a server that is running Terminal Services, a named system mutex can have two levels of visibility. In that case, a separate mutex with the same name can exist in each of the other terminal server sessions on the server.

Within a terminal server session, two mutexes whose names differ only by their prefixes are separate mutexes, and both are visible to all processes in the terminal server session.

Otherwise, a DirectoryNotFoundException may be thrown, even though the name of the mutex represents an existing file. Initializes a new instance of the Mutex class with default properties.

Initializes a new instance of the Mutex class with a Boolean value that indicates whether the calling thread should have initial ownership of the mutex. Initializes a new instance of the Mutex class with a Boolean value that indicates whether the calling thread should have initial ownership of the mutex, and a string that is the name of the mutex. Initializes a new instance of the Mutex class with a Boolean value that indicates whether the calling thread should have initial ownership of the mutex, a string that is the name of the mutex, and a Boolean value that, when the method returns, indicates whether the calling thread was granted initial ownership of the mutex.

Initializes a new instance of the Mutex class with a Boolean value that indicates whether the calling thread should have initial ownership of the mutex, a string that is the name of the mutex, a Boolean variable that, when the method returns, indicates whether the calling thread was granted initial ownership of the mutex, and the access control security to be applied to the named mutex.

Indicates that a WaitAny WaitHandle[], Int32, Boolean operation timed out before any of the wait handles were signaled. This field is constant. Releases all resources held by the current WaitHandle. Creates an object that contains all the relevant information required to generate a proxy used to communicate with a remote object. Releases all resources used by the current instance of the WaitHandle class.

When overridden in a derived class, releases the unmanaged resources used by the WaitHandle , and optionally releases the managed resources. Gets a MutexSecurity object that represents the access control security for the named mutex. Retrieves the current lifetime service object that controls the lifetime policy for this instance. Gets the Type of the current instance.

You can use a mutex object to protect a shared resource from simultaneous access by multiple threads or processes. Each thread must wait for ownership of the mutex before it can execute the code that accesses the shared resource. For example, if several threads share access to a database, the threads can use a mutex object to permit only one thread at a time to write to the database.

The following example uses the CreateMutex function to create a mutex object and the CreateThread function to create worker threads. When a thread of this process writes to the database, it first requests ownership of the mutex using the WaitForSingleObject function. The state of a mutex object is signaled when it is not owned by any thread.

The creating thread can use the bInitialOwner flag to request immediate ownership of the mutex. Otherwise, a thread must use one of the wait functions to request ownership. When the mutex's state is signaled, one waiting thread is granted ownership, the mutex's state changes to nonsignaled, and the wait function returns.

Only one thread can own a mutex at any given time. The owning thread uses the ReleaseMutex function to release its ownership. The thread that owns a mutex can specify the same mutex in repeated wait function calls without blocking its execution. Typically, you would not wait repeatedly for the same mutex, but this mechanism prevents a thread from deadlocking itself while waiting for a mutex that it already owns.

However, to release its ownership, the thread must call ReleaseMutex once for each time that the mutex satisfied a wait. Two or more processes can call CreateMutex to create the same named mutex.

The first process actually creates the mutex, and subsequent processes with sufficient access rights simply open a handle to the existing mutex. This enables multiple processes to get handles of the same mutex, while relieving the user of the responsibility of ensuring that the creating process is started first.

When using this technique, you should set the bInitialOwner flag to FALSE ; otherwise, it can be difficult to be certain which process has initial ownership. Multiple processes can have handles of the same mutex object, enabling use of the object for interprocess synchronization.

The following object-sharing mechanisms are available:. This utility lists various handle types that are open on the system; to list only mutex objects look for those of type "Mutant" like this:. GUI tools Process Explorer and Process Hacker tools can list open handles on the host, including those that refer to mutex objects. Both tools include an option to search for an open handle or DLL by name. The Performance Monitor tool, built into Windows, also offers these capabilities, as outlined by Mark Baggett.

Here's what this feature looks like in Process Hacker:. It is also possible to search for mutex names when examining a memory snapshot of a compromised system.

For instance, the popular memory forensics framework Volatility can enumerate mutant values using the "mutantscan" command. For another potential use of mutex values, consider the possibility of proactively generating mutant objects, so that malware believes it is already active on the host and refuses detection. As you saw in this article, mutex names can be used for creating indicators of compromise, which would allow incident responders to identify hosts infected with malware that uses those mutex objects.

It might also be possible to define heuristics that alert when unusually-random mutex names are discovered on the host, though this approach could produce some false positives. There are several command-line tools to list mutex names, though there is room for maturing this approach to malware discovery. He is active on Twitter and writes a security blog.