Deadlock Management

For Windows 7, deadlock is delineated as the condition hang. A deadlock/hang is caused

when two or more threads come into conflict over some resource, in such a way that no
execution is possible.
When an application (or more accurately, a thread) creates a window on the desktop, it enters into
an implicit contract with the Desktop Window Manager (DWM) to process window messages in a
timely fashion. The DWM posts messages (keyboard/mouse input and messages from other
windows, as well AS itself) into the thread-specific message queue. The thread retrieves and
dispatches those messages via its message queue. If the thread does not service the queue by
calling GetMessage(), messages are not processed, and the window hangs: it can neither redraw
nor can it accept input from the user. The operating system detects this state by attaching a timer
to pending messages in the message queue. If a message has not been retrieved within 5 seconds,
the DWM declares the window to be hung. You can query this particular window state via the
IsHungAppWindow() API.

Detection is only the first step. At this point, the user still cannot even terminate the application -
clicking the X (Close) button would result in a WM_CLOSE message, which would be stuck in
the message queue just like any other message. The Desktop Window Manager assists by
seamlessly hiding and then replacing the hung window with a 'ghost' copy displaying a bitmap of
the original window's previous client area (and adding "Not Responding" to the title bar). As long
as the original window's thread does not retrieve messages, the DWM manages both windows
simultaneously, but allows the user to interact only with the ghost copy. Using this ghost window,
the user can only move, minimize, and - most importantly - close the unresponsive application, but
not change its internal state.
The whole ghost experience looks like this:

The Desktop Window Manager does one last thing; it integrates with Windows Error Reporting,
allowing the user to not only close and optionally restart the application, but also send valuable
debugging data back to Microsoft. You can get this hang data for your own applications by
signing up at the Winqual website.


Deadlock Detection
Deadlock Detection monitors the driver's use of resources which need to be locked -- spin
locks, mutexes, and fast mutexes. This Driver Verifier option will detect code logic that has
the potential to cause a deadlock at some future point.
The Deadlock Detection option of Driver Verifier, along with the !deadlock kernel debugger
extension, is an effective tool for making sure your code avoids poor use of these resources.
The most common form of deadlock occurs when two or more threads wait for a resource that
is owned by the other thread. If both sequences happen at the same time, Thread 1 will never
get Lock B because it is owned by Thread 2, and Thread 2 will never get Lock A because it is
owned by Thread 1. At best this causes the threads involved to halt, and at worst causes the
system to stop responding.
Effects of Deadlock Detection
Driver Verifier's Deadlock Detection routines find lock hierarchy violations that are not
necessarily simultaneous. Most of the time, these violations identify code paths that will deadlock
when given the chance.
To find potential deadlocks, Driver Verifier builds a graph of resource acquisition order and
checks for loops. If you were to create a node for each resource, and draw an arrow any time one
lock is acquired before another, then path loops would represent lock hierarchy violations.
Driver Verifier will issue a bug check when one of these violations is discovered. This will happen
before any actual deadlocks occur.
Note Even if the conflicting code paths can never happen simultaneously, they should still be
rewritten if they involve lock hierarchy violations. Such code is a "deadlock waiting to happen"
that could cause real deadlocks if the code is rewritten slightly.
When Deadlock Detection finds a violation, it will issue bug check 0xC4. The first parameter of
this bug check will indicate the exact violation. Possible violations include:
Two or more threads involved in a lock hierarchy violation
A resource that is released out of sequence
A thread that tries to acquire the same resource twice (a self-deadlock)
A resource that is released without having been acquired first
A resource that is released by a different thread than the one that acquired it
A resource that is initialized more than once, or not initialized at all
A thread that is deleted while still owning resources
Starting in Windows 7, Driver Verifier can predict possible deadlocks.