1

I am trying to debug a multi-threaded application deadlock using windbg.
It just shows one thread as output when I run !ntsdexts.locks command in windbg.
How can I find other thread which is blocking it?

I am not getting any hint like on which section to debug!

0:027> !ntsdexts.locks

CritSec +6ec98b00 at 000001cc6ec98b00
WaiterWoken        No
LockCount          2
RecursionCount     1
OwningThread       277c
EntryCount         0
ContentionCount    18
*** Locked

Scanned 13 critical sections
Chirag Acharya
  • 126
  • 1
  • 12
  • analyze the captured dmp with [Debug Diag Analyzer](https://learn.microsoft.com/en-us/biztalk/core/how-to-use-debug-diagnostics-to-analyze-a-memory-dump) – magicandre1981 May 02 '19 at 15:24

1 Answers1

1

The command is giving you the critical section and the owning thread, which is 277c.

You now need to find out what that thread is doing. Start by ~~[277c]s and look at the call stack. It may just be in an endless loop, but it may also be in a WaitForSingleObject() or WaitForMultipleObjects() call.

Get the parameters passed as arguments to either of the Wait...() functions and see what that thread is waiting for. Might be another critical section, but might be some different synchronization object. Try to find out who is the owner of that thing.

Go on like this until you are back at thread 277c and you have confirmed the deadlock chain.

This manual approach can be really tedious. You might want to try some automated analysis:

  • !analyze -hang can give helpful insights
  • !sosex.dlk can analyze deadlocks between critical sections only, but fully (you get all the infos needed)
  • use Debug Diag Hang Analysis
Thomas Weller
  • 55,411
  • 20
  • 125
  • 222
  • call stack says `[0x0] ntdll!NtWriteFile + 0x14` `[0x1] KERNELBASE!WriteFile + 0x7a` Which is because I am using **anonymous pipe** for communication between threads which is calling this write call to file. This means that the thread gets stuck when it tries to perform `writefile` call! Right? – Chirag Acharya May 03 '19 at 09:00
  • For synchronous writes: yes, they can be blocked and contribute towards a deadlock. Find out which thread is written to and analyze that one. – Thomas Weller May 03 '19 at 12:31
  • Thanks @Thomas understood that. – Chirag Acharya May 03 '19 at 13:47
  • 1
    Today I came across weird reason of why Write call was causing application to stuck. It is necessary that pipe is opened by read handler first and then by write handler. If it misses out this sequence then Write call in pipe blocks application. So those searching on google and coming to this post can look into this scenario. – Chirag Acharya May 07 '19 at 04:58