!mlocks hung interpretation help needed

Question

i try to investigate a hung with windbg and want to know if my assumptions are right. If I call the command !mlocks i got the following:

0:000> !mlocks
Examining SyncBlocks...
Scanning for ReaderWriterLock instances...
Scanning for holders of ReaderWriterLock locks...
Scanning for ReaderWriterLockSlim instances...
Scanning for holders of ReaderWriterLockSlim locks...
Examining CriticalSections...




ClrThread  DbgThread  OsThread    LockType    Lock              LockLevel 
-------------------------------------------------------------------------- 
0x640064   -1         0xffffffff  RWLock      000000000339a338  Writer  
0x6        7          0x1ea8      thinlock    000000000343ddd8  (recursion:0) 

When executeing rwlocks i got the following:

 0:000> !rwlock 000000000339a338            
WriterThread:           0x640064 (DEAD) WriterLevel:            115 WaitingWriterCount:     0 
WriterEvent:            0 
WaitingWriterThreadIds: None 
ReaderCount:            116 
CurrentReaderThreadIds:  
WaitingReaderCount:     576 
ReaderEvent:            80400002 
WaitingReaderThreadIds:  
*This lock has 116 orphaned reader locks. 

0:007> !rwlock

Address            ReaderCount   WaitingReaderCount     WriterThread   WaitingWriterCount 
... 
000000000339a338           116                  576            0x640064                 0 
... 
00000000053f0688           568                  499            --                       6 
...

i got this. When I call

    0:000> !dlk Examining SyncBlocks... Scanning for ReaderWriterLock instances... Scanning for holders of ReaderWriterLock locks... Scanning for ReaderWriterLockSlim instances... 
Scanning for holders of ReaderWriterLockSlim locks... 
Examining CriticalSections... 
Scanning for threads waiting on SyncBlocks... 
Scanning for threads waiting on ReaderWriterLock locks... 
Scanning for threads waiting on ReaderWriterLocksSlim locks... 
Scanning for threads waiting on CriticalSections... 
No deadlocks detected. 

then no deadlock will be detected. I found this on Tess's blog My question is if this threads have to do with my hunging application, and what the scenario could be. What does it mean that the thread is DEAD. Can a lock happen on a dead thread? Or do I have to find somewhere else root cause of my hunging application? Please help me to interpret this output.

Regards, Bernhard

Here is some addional info:

0:000> dc 000000000339a338
00000000`0339a338  f2073268 000007fe 00000000 80000000  h2..............
00000000`0339a348  f2066960 000007fe 00000010 00650047  `i..........G.e.
00000000`0339a358  00480074 0073006f 00410074 00640064  t.H.o.s.t.A.d.d.
00000000`0339a368  00650072 00730073 00730065 00000000  r.e.s.s.e.s.....
00000000`0339a378  00000000 00000000 00000000 00000000  ................
00000000`0339a388  f2066960 000007fe 0000001c 00650066  `i..........f.e.
00000000`0339a398  00300038 003a003a 00380034 00310038  8.0.:.:.4.8.8.1.
00000000`0339a3a8  0034003a 00660039 003a0063 00300039  :.4.9.f.c.:.9.0.
0:000> db 000000000339a338
00000000`0339a338  68 32 07 f2 fe 07 00 00-00 00 00 00 00 00 00 80  h2..............
00000000`0339a348  60 69 06 f2 fe 07 00 00-10 00 00 00 47 00 65 00  `i..........G.e.
00000000`0339a358  74 00 48 00 6f 00 73 00-74 00 41 00 64 00 64 00  t.H.o.s.t.A.d.d.
00000000`0339a368  72 00 65 00 73 00 73 00-65 00 73 00 00 00 00 00  r.e.s.s.e.s.....
00000000`0339a378  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
00000000`0339a388  60 69 06 f2 fe 07 00 00-1c 00 00 00 66 00 65 00  `i..........f.e.
00000000`0339a398  38 00 30 00 3a 00 3a 00-34 00 38 00 38 00 31 00  8.0.:.:.4.8.8.1.
00000000`0339a3a8  3a 00 34 00 39 00 66 00-63 00 3a 00 39 00 30 00  :.4.9.f.c.:.9.0.

0:000> !mdt 000000000339a338  
Can't get name for module 000007ff0068c3c0. Error = 0x80070057.
Can't get name for module 000007ff00791908. Error = 0x80070057.
Can't get name for module 000007ff0068c3c0. Error = 0x80070057.
Can't get name for module 000007ff00791908. Error = 0x80070057.
000000000339a338 (System.Threading.ReaderWriterLock)
    _hWriterEvent:8000000000000000 (System.IntPtr)
    _hReaderEvent:000007fef2066960 (System.IntPtr)
    _hObjectHandle:0065004700000010 (System.IntPtr)
    _dwState:0x480074 (System.Int32)
    _dwULockID:0x73006f (System.Int32)
    _dwLLockID:0x410074 (System.Int32)
    _dwWriterID:0x640064 (System.Int32)
    _dwWriterSeqNum:0x650072 (System.Int32)
    _wWriterLevel:0x0073 (System.Int16)

0:000> !mdt 000000000343ddd8  
Can't get name for module 000007ff0068c3c0. Error = 0x80070057.
Can't get name for module 000007ff00791908. Error = 0x80070057.
000000000343ddd8 (System.Collections.Generic.LinkedList`1[[TAU.GuiAccess.PopupHandler.ClientInfo, TAU.GuiAccess.PopupHandler]])
    head:000000000823e148 (System.Collections.Generic.LinkedListNode`1[[TAU.GuiAccess.PopupHandler.ClientInfo, TAU.GuiAccess.PopupHandler]])
    count:0x1 (System.Int32)
    version:0x3b (System.Int32)
    _syncRoot:NULL (System.Object)
    siInfo:NULL (System.Runtime.Serialization.SerializationInfo)

0:000> !do 000000000343ddd8 
Name:        System.Collections.Generic.LinkedList`1[[TAU.GuiAccess.PopupHandler.ClientInfo, TAU.GuiAccess.PopupHandler]]
MethodTable: 000007ff009ce218
EEClass:     000007ff009dda20
Size:        48(0x30) bytes
File:        C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System\v4.0_4.0.0.0__b77a5c561934e089\System.dll
Fields:
              MT    Field   Offset                 Type VT     Attr            Value Name
000007ff009ced28  4000586        8 ...ss.PopupHandler]]  0 instance 000000000823e148 head
000007fef206c848  4000587       20         System.Int32  1 instance                1 count
000007fef206c848  4000588       24         System.Int32  1 instance               59 version
000007fef2065ab8  4000589       10        System.Object  0 instance 0000000000000000 _syncRoot
000007fef208a1b8  400058a       18 ...SerializationInfo  0 instance 0000000000000000 siInfo
ThinLock owner 6 (0000000000000000), Recursive 0

Answer 1

The "DEAD" indication means that there is no corresponding OS thread. When a managed thread is created, a managed thread object is created and assigned a thread ID. On Windows, there is currently always a 1:1 mapping between managed and native threads, so there is also an OS thread ID assigned. When a thread terminates, the association between the managed thread object and the native thread is obviously broken. However, it takes a period of time before the managed thread object gets cleaned up. A thread in this state is listed by sosex as "DEAD" and is listed as XXXX in the !sos.threads output.

In this case, the CLR thread ID (00640064) looks suspicious. It looks curiously like Unicode text 'dd'. There may be corruption around the managed lock address. Look around with the debugger's 'dc' or 'db' commands to see if some text has overwritten the thread ID field.