Menu
I am debugging a program which I suspect there could be deadlock or other mutli-thread related bug, I follow people's suggestions to use WinDBG to open the crash dump file and used !locks to get the following output:
CritSec MSVCR100D!lclcritsects+48 at 73541e40
WaiterWoken No
LockCount 6
RecursionCount 1
OwningThread 164c
EntryCount 0
ContentionCount 9
*** Locked
*** ERROR: Symbol file could not be found. Defaulted to export symbols for qsqlited4.dll -
CritSec qsqlited4!qt_plugin_instance+a1b21 at 70fc301c
WaiterWoken No
LockCount 0
RecursionCount 1
OwningThread 2344
EntryCount 0
ContentionCount 0
*** Locked
CritSec +73c2380 at 073c2380
WaiterWoken No
LockCount 0
RecursionCount 4
OwningThread 2344
EntryCount 0
ContentionCount 0
*** Locked
CritSec +73bf9e8 at 073bf9e8
WaiterWoken No
LockCount 0
RecursionCount 1
OwningThread 2344
EntryCount 0
ContentionCount 0
*** Locked
Scanned 817 critical sections
I am confused by the output, could anyone help to explain it?
862
WinDBG - The Basics for Debugging Crash Dumps in Windows 10. Information. WinDBG (Windows DeBuGger) is an analytic tool used for analysing and debugging Windows crash dumps, also known as BSODs (Blue Screens of Death).
Launch Notepad and attach WinDbg Navigate to your installation directory, and open WinDbg.exe. The debugger documentation is also available on line here. On the File menu, choose Open Executable. Near the bottom of the WinDbg window, in the command line, enter this command: .sympath srv*.
At some point in the past there were nine threads trying to acquire the lock. Probably what you want to do is switch to the owning thread and see what it's doing, why it's still holding the lock, etc. You can look for the thread in the windbg Processes and Threads number or do it from the command window:
To install and configure WinDBG follow WinDBG - Install Configure - Windows 10 Forums for full instructions. Dump files are saved with the .dmp file extension and are identified by the icon below. Small memory dump files (most commonly used for analysing BSODs) are saved locally to %SystemRoot%\Minidump.
!locks can be confusing. If you really want to debug a deadlock situation, do a ~*kvn (or kb whichever you like) find threads waiting on critical sections which will end in a **WaitForSingleForSingleObject and before that a RtlEnterCriticalSection call. Find the Critical section most of the threads are wating on. Dump the critical section. If you are debugging x64 based dumps and narrow down to the frame which is carrying RtlCrticalSection using .frame /c post you are in thread context ~[threadnum]s, rbx will contain your critical section.
Dump the critical section find the owner. If the owner is waiting find out what's owner waiting on and so on till we reach end of chain or a reason why things are blocked. !cs -l -o can be confusing if we don't put it in context.
Hope this helps.
198
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
