.net - How can a critical section is owned by a dead thread? -


i have .net winform application , ui hung.

the ui thread blocked on critsec ntdll!ldrploaderlock+0 @ 774920c0.

0:010> kb childebp retaddr  args child               0fc4e034 773c8df4 000000d4 00000000 00000000 ntdll!ntwaitforsingleobject+0x15 0fc4e098 773c8cd8 00000000 00000000 773bfa84 ntdll!rtlpwaitoncriticalsection+0x13e 0fc4e0c0 773bffd3 774920c0 71e65850 00000001 ntdll!rtlentercriticalsection+0x150 0fc4e230 773bfd2f 00000001 00000001 00000000 ntdll!ldrgetdllhandleex+0x2f7 0fc4e24c 75dd1a43 00000001 00000000 0fc4e2bc ntdll!ldrgetdllhandle+0x18 warning: stack unwind information not available. following frames may wrong. 0fc4e2a0 75dd1c57 0fc4e2bc b7a43509 02baed94 kernelbase!getmodulefilenamew+0x1a9 0fc4e718 75dd1d52 00000001 00000002 02baed94 kernelbase!getmodulefilenamew+0x3bd 0fc4e730 5fc58fc5 02baed94 b108f787 7285ac08 kernelbase!getmodulehandlew+0x29 ... 

and critical section 774920c0 owned thread 1bd4.

0:010> !locks critsec ntdll!ldrploaderlock+0 @ 774920c0 waiterwoken        no lockcount          32 recursioncount     1 owningthread       1bd4 entrycount         0 contentioncount    27a *** locked  critsec +1027c5bc @ 1027c5bc waiterwoken        no lockcount          3 recursioncount     1 owningthread       1a4c entrycount         0 contentioncount    1bb *** locked  critsec +17700138 @ 17700138 waiterwoken        no lockcount          1 recursioncount     1 owningthread       1620 entrycount         0 contentioncount    d *** locked 

the windbg thread sequence id of thread 1bd4 68.

0:010> ~ #  0  id: ccc.124c suspend: 1 teb: 7efdd000 unfrozen    1  id: ccc.88c suspend: 1 teb: 7efda000 unfrozen    ...    67  id: ccc.514 suspend: 1 teb: 7ef36000 unfrozen    68  id: ccc.1bd4 suspend: 1 teb: 7ef30000 unfrozen    69  id: ccc.1a30 suspend: 1 teb: 7ef1b000 unfrozen    ... 

however, 68 doesn't exist in output of !threads, or mean 68 dead thread?

0:010> !threads threadcount:      65 unstartedthread:  13 backgroundthread: 37 pendingthread:    13 deadthread:       5 hosted runtime:   no                                                                          lock          id osid threadobj    state gc mode     gc alloc context  domain   count apt exception    0    1 124c 004db888     26020 preemptive  3e3a01cc:00000000 004cf1b0 0     sta     2    2 14e0 004e7a20     2b220 preemptive  00000000:00000000 004cf1b0 0     mta (finalizer)   ...    8   10 19c4 055691e0   3029220 preemptive  00000000:00000000 004cf1b0 0     mta (threadpool worker)    10   12 1520 0f91cbc8     27220 preemptive  00000000:00000000 004cf1b0 0     sta  ...   66   46 169c 29e344b8   3029220 preemptive  00000000:00000000 004cf1b0 0     mta (threadpool worker)  xxxx   33    0 19ff4a90   8039820 preemptive  00000000:00000000 004cf1b0 0     ukn (threadpool completion port)  xxxx   55    0 29cbe540   8039820 preemptive  00000000:00000000 004cf1b0 0     ukn (threadpool completion port)    69    6 1a30 2a1be4d8   a029220 preemptive  00000000:00000000 004cf1b0 0     mta (threadpool completion port)   ... 

when try walk through call stack of 68 !clrstack, fails. still can use kb check native stack trace.

0:068> !clrstack os thread id: 0x1bd4 (68) unable walk managed stack. current thread not  managed thread. can run !threads list of managed threads in process failed start stack walk: 80070057 0:068> kb childebp retaddr  args child               2c85f580 773c8df4 000019ac 00000000 00000000 ntdll!ntwaitforsingleobject+0x15 2c85f5e4 773c8cd8 00000000 00000000 2bc40458 ntdll!rtlpwaitoncriticalsection+0x13e 2c85f60c 773f5f33 17700138 52a74c34 175f3f40 ntdll!rtlentercriticalsection+0x150 2c85f654 773c740d 00000000 17700000 2bc404b8 ntdll!rtlpfreeuserblock+0x47 2c85f690 773be023 2bc404b8 3b6af630 27620000 ntdll!rtlplowfragheapfree+0x2cc 2c85f6a8 75a814ad 17700000 00000000 2bc404b8 ntdll!rtlfreeheap+0x105 warning: stack unwind information not available. following frames may wrong. 

i can see thread 68 blocked on critical section 17700138, belongs thread 1620. should root cause why ui thread hung.

but question what's truth of thread 68? if it's dead, how can own critical section critsec ntdll!ldrploaderlock+0 @ 774920c0 , has call stack?


Comments

Popular posts from this blog

python - TypeError: start must be a integer -

c# - DevExpress RepositoryItemComboBox BackColor property ignored -

django - Creating multiple model instances in DRF3 -