Windebug and Adplus for debugging process hang

1. Set the symbol, especillay windows symbols
.......26_Merged\UNCRelease;\\blrm2fsp\SCSD-Common\Sym\WinSym2K3SP1

2. Set the souce and image

3. Load the extension dll ( for !locks command ) if not already loaded

.load C:\Program Files\Debugging Tools for Windows\winxp\kdexts.dll

4. Use the !ntsdexts.locks ( or !locks) command to see a list of critical section

:004> !ntsdexts.locks

CritSec ntdll!LdrpLoaderLock+0 at 7C889D94
LockCount -6902
RecursionCount 1
OwningThread 2b3c
EntryCount 0
ContentionCount 28f3
*** Locked

CritSec +12f9b4 at 0012F9B4
LockCount 0
RecursionCount 0
OwningThread 0
*** Locked

CritSec +12f70c at 0012F70C
LockCount 0
RecursionCount 0
OwningThread 0
*** Locked

CritSec +128202c at 0128202C
LockCount -2
RecursionCount 1
OwningThread 3d9c
EntryCount 0
ContentionCount 0
*** Locked
-----------

A 'LockCount' other than 0 means that many threads are waitiing on this and it is the suspect

6. Do a ~* kb ( print stack trace for all threads)

and search for the critsection address (7C889D94) got from step 5, in the stack print.

Usually you will find many thread waiting for the same ( in this case thread id 163)

163 Id: 4d8.3c78 Suspend: 0 Teb: 7fe8e000 Unfrozen
ChildEBP RetAddr Args to Child
225dfbc8 7c822124 7c83970f 000001e4 00000000 ntdll!KiFastSystemCallRet
225dfbcc 7c83970f 000001e4 00000000 00000000 ntdll!NtWaitForSingleObject+0xc
225dfc08 7c839620 00000000 00000004 00000000 ntdll!RtlpWaitOnCriticalSection+0x19c
225dfc28 7c81a86c 7c889d94 00000000 7ffde000 ntdll!RtlEnterCriticalSection+0xa8
225dfcb8 7c81b22d 225dfd28 225dfd28 00000000 ntdll!LdrpInitializeThread+0x68
225dfd14 7c82ec2d 225dfd28 7c800000 00000000 ntdll!_LdrpInitialize+0x16f
00000000 00000000 00000000 00000000 00000000 ntdll!KiUserApcDispatcher+0x25

( the third parameter has the critical section address)


5. !critsec 7c889d94

CritSec ntdll!LdrpLoaderLock+0 at 7C889D94
LockCount -6902
RecursionCount 1
OwningThread 2b3c
EntryCount 0
ContentionCount 28f3
*** Locked

6.. Use ~ to get thread list; Check if you can find the thread in the dump.

If not ,then you have two things to do - Google about this locked critsection assuming it is a windows one,which gives you a hint about the suspect code parts. ( in this case TerminateThread calls from somewhere in your process)

Also you can attach Adplus ( part of windows debug package) to see if there was any exception that had occurred.
The Adplus gives you a dump of the process at the time when the exception is thrown .

Analysing each first and second chance exception is
important as this can also lead to memory corruption, which can manifest later on in many ways

7. Adplus setting F:\\Tools\ADPlus>adplus -pn proceesname.exe -crash -FullonFirst -quiet .

This will dump when ever an exception happens ( even if you are 'handling' it in the code using cach(…) )

Do a !analyze -v command on the dumps ( after setting the symbols correct) and this will give you the stack trace of the crashing code.

Correct these in source and run with adplus again.

Sooner or later you will find the problem area. And of course the solution.

Comments

Popular posts from this blog

OpenLayers Advanced Clustering and Setting dynamic images for OpenLayer Styles via Ajax

Long running Java process resource consumption monitoring , leak detection and GC tuning

Compiling OpenCV with CUDA (GPU) using CMake (GUI)