First, thanks to the monks who have tested this program for me! I'm still hoping to find someone who can reproduce my hangs; then we can play Sherlock Holmes to try to figure what is different about the hanging machines versus the non-hanging ones. Oh, and I get the hangs with debug builds too, which is good news.

I'm learning far more about critical sections than I ever wanted to. When I issue the !cs command in WinDbg to display all critical sections, I get this on the offending critical section:

DebugInfo          = 0x00043bf0
Critical section   = 0x00222d44 (+0x222D44)
LOCKED
LockCount          = 0x0
OwningThread       = 0x00000000
RecursionCount     = 0x0
LockSemaphore      = 0x7B0
SpinCount          = 0x00000000
[download]

As noted here having an OwningThread of zero is "illogical" with a LockCount of zero:

While examining a deadlocked program, we also found a state for which there seemed to be no logical explanation. The LockCount field for one heavily used critical section contained a value greater than -1; that is, it was owned, but the OwningThread field was zero (which destroyed evidence against the guilty thread). The test program was multithreaded, and the condition arose on both single and multiprocessor machines. Although LockCount and other values differed from run to run, the program always deadlocked on the same critical section. We'd definitely be curious to find out if any other developers out there have seen the API call sequence leading up to this state.

So, maybe I should contact Matt Pietrek to investigate this bug for me. :-)