CriticalSection Count-Variables inconsistent? - deadlock

Question

This was a manual dump. Some people claim that there was a deadlock.
1) !locks says that the OwningThread of my critical section is 19a0, but that thread doesnt even exist? (look at ~ output)
2) EntryCount is 0, so the only thread that ever called EnterCriticalSection was 19a0. ContentionCount is cd(205), which would mean mean that other threads did try to EnterCriticalSection? Are these 2 things not contradictory?
3) RecursionCount is 1, meaning that the thread 19a0 called EnterCriticalSection once initialy, leading to LockCount:0 and RecursionCount:1. How did LockCount reach 8, if RecursionCount is still 1? It would have to be 8 and 9, since i know that EntryCount is 0, which means that only the thread 19a0 called EnterCriticalSection those 8 times?
4) 8 different threads show in their kb output:
02 00007ff8`500af83f : 00000146`**ed3502a0** 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlpWaitOnAddress+0xb2.
So how can EntryCount be 0 here? Does WaitOnAdress matter? Or only EnterCriticalSection/EnterCriticalSectionContended?
5) A general explanation of what might have happened in this critical section would be helpful.
0:021> !locks
CritSec +ed3502a0 at 00000146ed3502a0
WaiterWoken No
LockCount 8
RecursionCount 1
OwningThread 19a0
EntryCount 0
ContentionCount cd
*** Locked
0:021> ~
# 0 Id: 10f40.ca10 Suspend: 0 Teb: 00000031`d9312000 Unfrozen
1 Id: 10f40.bcc4 Suspend: 0 Teb: 00000031`d931a000 Unfrozen
2 Id: 10f40.4de4 Suspend: 0 Teb: 00000031`d931c000 Unfrozen
3 Id: 10f40.4b9c Suspend: 0 Teb: 00000031`d931e000 Unfrozen
4 Id: 10f40.b34 Suspend: 0 Teb: 00000031`d9320000 Unfrozen
5 Id: 10f40.12680 Suspend: 0 Teb: 00000031`d9328000 Unfrozen
6 Id: 10f40.f420 Suspend: 0 Teb: 00000031`d932a000 Unfrozen
7 Id: 10f40.7d5c Suspend: 0 Teb: 00000031`d932c000 Unfrozen
8 Id: 10f40.f544 Suspend: 0 Teb: 00000031`d932e000 Unfrozen
9 Id: 10f40.7774 Suspend: 0 Teb: 00000031`d9330000 Unfrozen
10 Id: 10f40.101a0 Suspend: 0 Teb: 00000031`d9332000 Unfrozen
11 Id: 10f40.104e8 Suspend: 0 Teb: 00000031`d9336000 Unfrozen
12 Id: 10f40.135e8 Suspend: 0 Teb: 00000031`d9338000 Unfrozen
13 Id: 10f40.7ad0 Suspend: 0 Teb: 00000031`d9342000 Unfrozen
14 Id: 10f40.113ec Suspend: 0 Teb: 00000031`d9344000 Unfrozen
15 Id: 10f40.7a7c Suspend: 0 Teb: 00000031`d9346000 Unfrozen
16 Id: 10f40.6b18 Suspend: 0 Teb: 00000031`d9354000 Unfrozen
17 Id: 10f40.a414 Suspend: 0 Teb: 00000031`d9356000 Unfrozen
18 Id: 10f40.133b4 Suspend: 0 Teb: 00000031`d935a000 Unfrozen
19 Id: 10f40.11794 Suspend: 0 Teb: 00000031`d935c000 Unfrozen
20 Id: 10f40.4e40 Suspend: 0 Teb: 00000031`d935e000 Unfrozen
. 21 Id: 10f40.8b5c Suspend: 0 Teb: 00000031`d9360000 Unfrozen
22 Id: 10f40.115b4 Suspend: 0 Teb: 00000031`d9362000 Unfrozen
23 Id: 10f40.1f38 Suspend: 0 Teb: 00000031`d9364000 Unfrozen
24 Id: 10f40.e560 Suspend: 0 Teb: 00000031`d9368000 Unfrozen
25 Id: 10f40.1047c Suspend: 0 Teb: 00000031`d92c2000 Unfrozen
26 Id: 10f40.ad40 Suspend: 0 Teb: 00000031`d9214000 Unfrozen
27 Id: 10f40.8e00 Suspend: 0 Teb: 00000031`d9208000 Unfrozen
28 Id: 10f40.af38 Suspend: 0 Teb: 00000031`d9220000 Unfrozen
29 Id: 10f40.c6a4 Suspend: 0 Teb: 00000031`d9222000 Unfrozen
30 Id: 10f40.14114 Suspend: 0 Teb: 00000031`d9224000 Unfrozen

Answer 1

For 1): that thread may have been terminated by an exception or finished normally and someone forgot to implement LeaveCriticalSection.
For 2):
EntryCount is incremented when other threads call EnterCriticalSection()
EntryCount and ContentionCount are never decremented
as documented.
For 3):
The field LockCount is not a true lock count any more, as explained in
this answer. Relevant part:
In Microsoft Windows Server 2003 Service Pack 1 and later versions of Windows, the LockCount field is parsed as follows:
The lowest bit shows the lock status. If this bit is 0, the critical section is locked; if it is 1, the critical section is not locked.
The next bit shows whether a thread has been woken for this lock. If this bit is 0, then a thread has been woken for this lock; if it is 1, no thread has been woken.
The remaining bits are the ones-complement of the number of threads waiting for the lock.
For 4): RtlpWaitOnAddress IMHO is not so useful. There should be some RtlpEnterCriticalSection on the call stack as well. The argument there can be used for the !cs command.
For 5): One of my demos is the following code. It uses an event instead of a critical section, but the result is the same:
#include "stdafx.h"
#include <Windows.h>
#include <process.h>
#include <stdio.h>
#include <iostream>
HANDLE threadA;
HANDLE threadB;
HANDLE eventB;
class WorkItem
{
public:
virtual void Initialize()
{
}
};
unsigned int __stdcall initializeWorkitems(void* param)
{
try
{
// Initialize workitems
WorkItem **items = new WorkItem*[2];
items[0] = new WorkItem();
items[1] = NULL;
for (int i = 0; i<2; i++)
{
items[i]->Initialize();
}
// Signal event for second thread to work on work items
SetEvent(eventB);
}
catch(...)
{
// Don't do this
}
return 0;
}
unsigned int __stdcall processWorkitems(void* param)
{
// Wait for work item initialization to complete
WaitForSingleObject(eventB, INFINITE);
// Work on workitems
Sleep(100);
return 0;
}
int _tmain(int argc, _TCHAR* argv[])
{
eventB = CreateEvent(0, 0, 0, 0);
threadA = (HANDLE)_beginthreadex(0, 0, &initializeWorkitems, (void*)0, 0, 0);
threadB = (HANDLE)_beginthreadex(0, 0, &processWorkitems, (void*)0, 0, 0);
WaitForSingleObject(threadA, INFINITE);
WaitForSingleObject(threadB, INFINITE);
CloseHandle(threadA);
CloseHandle(threadB);
CloseHandle(eventB);
return 0;
}