Till I die I'm still screamin' that... Driver Verifier is probably the best damn feature in Windows since the IRP.  Exercising your driver aggressively, with all the Driver Verifier options enabled (except perhaps low-resource simulation), is one of the most basic things that any developer can do to help ensure driver quality.

One of my personal favorite featues provided by Driver Verifier is Deadlock Verification, which was implemented starting in Windows XP.  This feature monitors your driver's use of Spinlocks, mutexes, and fast mutexes and builds the graph that represents the implied locking hierarchy implemented by your driver.  Whenever Deadlock Verification finds what appears to be a violation of the implied hierarchy, it crashes the system with a bugcheck code of 0xC4 (ha ha "C4"... Like the explosive, get it?), and a parameter 1 value between 0x1000 and 0x1007.

Just to be clear, what this means is that when enabled, Deadlock Verifier watches your driver as it runs, and records the various locks that your driver acquires. When multiple locks are acquired simultaneously, Deadlock Verifier also notes the order in which they have been acquired.  So, let's say for example that your driver uses two spinlocks: One named "fred" and the other named "bob".  If your driver at some point acquires both of these spinlocks simultaneously, first acquring bob and then acquring fred, Deadlock Verifier will note this.  If later, your driver acquires both of these locks again, but does so in the opposite order -- first acquiring fred and next acquiring bob, you have a locking hierarchy violation, that could potentially lead to a nasty deadlock.  As a result, when Deadlock Verifier notices this, it'll slap you with a bugcheck 0xC4, in this case with Parameter 1 set to 0x1001.

Whenever you get a Deadlock Verifier related bugcheck, you use the !deadlock command in WinDbg to get more information about the violation.  You'll get all sorts of cool information, including the locks and their types.

I'm sure you're thinking that this is all great, and it is.  But there's a gotcha for those of us who've been relying on this feature: In uniprocessor builds of Windows-64 for the x64 processors (that is, AMD64 and Intel EM64T), you can request that Deadlock Verifier be enabled in Driver Verifier, but it never actually gets turned on.

Before you go all whiney on me, this isn't a bug in Windows.  I hear it has something to do with compiler optimizations and such.  In any case, I don't expect it to get changed any time soon.

The work-around?  Make sure you test with Deadlock Verifier enabled on x86 systems, either uniprocessor or multiprocessor, or test (like you should be doing anyhow) with Deadlock Verifier enabled on multiprocessor x64 systems.  Better yet, do what we've been telling you to do for years: Test your driver with the checked build of the kernel and HAL. Because the checked versions are always multiprocessor enabled, there's no problem!