0 is not a valid thread ID, according to MSDN and Raymond Chen.
But, when I analyzed a dump, one of the two dead-locked critical sections, is locked, but with OwningThread as 0.
Can somebody help to explain?
> !locks
CritSec ModuleA!lockerA+4 at 58cf4b24
WaiterWoken No
LockCount 230
RecursionCount 0
OwningThread 0
EntryCount 0
ContentionCount e6
*** Locked
CritSec ModuleA!$S2+8 at 58cf4b44
WaiterWoken No
LockCount 0
RecursionCount 1
OwningThread 2154
EntryCount 0
ContentionCount 0
*** Locked
Scanned nnnn critical sections
> !cs 58cf4b24
-----------------------------------------
Critical section = 0x58cf4b24 (ModuleA!lockerA+0x4)
DebugInfo = 0x1cd3d8d0
LOCKED
LockCount = 0xE6
WaiterWoken = No
OwningThread = 0x00000000
RecursionCount = 0x0
LockSemaphore = 0xCDC
SpinCount = 0x00000000
> !cs 58cf4b44
-----------------------------------------
Critical section = 0x58cf4b44 (ModuleA!$S2+0x8)
DebugInfo = 0x1b1f1840
LOCKED
LockCount = 0x0
WaiterWoken = No
OwningThread = 0x00002154
RecursionCount = 0x1
LockSemaphore = 0x0
SpinCount = 0x00000000
I think there are at least two possibilities here.
The first is the old favourite, a memory corruption issue. If, for some reason, a thread has blown past the end of a buffer, it's possible it might have landed on the data structure holding the thread ID. In my opinion, this is the less likely of the two, though certainly possible.
Another possibility is that your locking thread has "disappeared" without exiting the critical section. That seems more likely to me given the high contention count, since it appears that there are a large number of threads waiting to enter that critical section.
User contributions licensed under CC BY-SA 3.0