I am in the process of learning how to use Windbg effectively and would appreciate any help in understanding issues a bit more deeply.
I am currently looking at a user mode dump (full memory via procdump’s -ma option) that has a thread blocked waiting on a semaphore. If I use the !handle extension to look at the semaphore information, I get something useful such as that it is of type semaphore, its access types and so on. But the “Object Specific Information” seems to be empty. Further more if I do a ‘dd’ on the memory pointed by the semaphore I just get a whole bunch of ‘?’. I have read this could be because I cannot drill down into any more detail since Semaphore is a kernel mode object and I am looking at an user mode dump. Is that true?
In other words, it seems obvious the semaphore is in a non-signaled state (because the concerned thread is waiting on it). Is there a way to figure out what the maximum count on the said semaphore is and which threads have acquired it?
FWIW, I tried:
0:000> !handle 00000abc f
and
0:000> dd 00000abc (this just displays what looks like invalid memory)
use windbg .dump /ma /mh to create teh dump and it will normally have
the object specific information in usermode dump
see a comparison of iexplore.exe dump captured via procdump and .dump
from windbg
E:\>tasklist /FI “ImageName eq iexplore.exe”
iexplore.exe 3612 Console 1 19,360 K
E:\>procdump -ma 3612 iedumb.dmp
E:\>cdb.exe -z iedumb.dmp
Microsoft (R) Windows Debugger Version 10.0.10586.567 X86
0:000> !handle 0 f Semaphore
Handle 0000010c
Type Semaphore
Attributes 0
GrantedAccess 0x100003:
Synch
QueryState,ModifyState
HandleCount 2
PointerCount 3
Name Object specific information <---------------------- blank
17 handles of type Semaphore
E:>cdb.exe -p 3612 <---------- attaching
0:009> .dump /ma /mh “e:\iedumboo.dmp” <------- creating dump with windbg Creating e:\iedumboo.dmp - mini user dump Dump successfully written 0:009> q quit:
E:>cdb.exe -z iedumboo.dmp
0:009> !handle 10c f Handle 0000010c Type Semaphore Attributes 0 GrantedAccess 0x100003: Synch QueryState,ModifyState HandleCount 2 PointerCount 3 Name Object specific information Semaphore Count 0 <-------------- ob specific info avalable Semaphore Limit 2147483647 0:009>
On 6/8/16, xxxxx@gmail.com wrote: > I am in the process of learning how to use Windbg effectively and would > appreciate any help in understanding issues a bit more deeply. > > I am currently looking at a user mode dump (full memory via procdump’s -ma > option) that has a thread blocked waiting on a semaphore. If I use the > !handle extension to look at the semaphore information, I get something > useful such as that it is of type semaphore, its access types and so on. But > the “Object Specific Information” seems to be empty. Further more if I do a > ‘dd’ on the memory pointed by the semaphore I just get a whole bunch of ‘?’. > I have read this could be because I cannot drill down into any more detail > since Semaphore is a kernel mode object and I am looking at an user mode > dump. Is that true? > > In other words, it seems obvious the semaphore is in a non-signaled state > (because the concerned thread is waiting on it). Is there a way to figure > out what the maximum count on the said semaphore is and which threads have > acquired it? > > FWIW, I tried: > > 0:000> !handle 00000abc f > > and > > 0:000> dd 00000abc (this just displays what looks like invalid memory) > > > — > WINDBG is sponsored by OSR > > OSR is hiring!! Info at http://www.osr.com/careers > > > MONTHLY seminars on crash dump analysis, WDF, Windows internals and software > drivers! > Details at http: > > To unsubscribe, visit the List Server section of OSR Online at > http: ></http:></http:>
Thanks for the information. Its interesting you had to use both /ma and /mh from Windbg/cdb. THe documentation says ‘ma’ is equivalent to ‘mfFhut’, which clearly includes handle information too.
Procdump has similar options. It has something called ‘mp’ which captures thread and handle information but ‘ma’ is supposed to subsume that. I will try with both and see what happens.
So, the bottomline is, there is no reason why (at least) the Name and Object Specific Information cannot be made available from an user mode dump itself?