Windbg kernel mode driver threads debugging
Robert Luursema
How do I get access to a sleeping/hanging thread of my Kernel mode driver?
I have this filter/class driver that has several threads that uses
KeWaitForSingleObject() for synchonization. In my case, one is waiting on a
KEVENT synchronization event, that is signalled by one of my threads when
the responses from the lowerlevel (serial) port driver are completed.
I now try to debug a case where a thread is stopped forever, probably at a
KeWaitForSingleObject(), but I can't get WinDbg to display any state info
about it.
How do I get WinDbg to show me the registers and values of a not responding
thread, or from any system thread?
I know that setting a breakpoint will get me to that thread, but when that
isn't possible what to do next? Is there a command that lists the process
& thread addresses of some driver, so the !process and !thread commands can
be used?
The WinDebug kernel debugger only knows of 1 process or thread (for each
CPU). System threads appear foreign to it.
When I break in with ^C it stops from the system Idle thread. Dumping the
contents of my device context, which I made accessible using a global(!)
pointer, results in a error after dumping a few entries ("CXX000 Error:
Unknown error"). The data dumped is in non-pageable memory!
--
Robert Luursema, Incaa Datacom.
To email reply, please remove the nospam- from the reply address.
Simon Graham
There are debugger extensions to show processes and threads:
!kdextx86.process 0 0
(assuming you are running on an X86 machine ;-) will give you a list of all
processes. Use "!process 0 7 to get list of processes and all threads
including stacks. Use "!process proch 7" to get threads for a specici
process (using the process handle output by "!process 0 0").
!kdextx86.thread thrdh
Will dump info about a specific thread if you know the thread handle.
If you are using the latest windbag (from the Jan 98 Platform SDK), once you
use the !thread command to look at a thread, you can use the
calls/locals/etc windows to navigate the call stack of the specific thread
(although be warned - I've seen some instant blue screens when doing this on
a live system as opposed to a dump).
Oh - one other gotcha; if you use !thread to look at the current thread, you
will NOT see a sensible stack (I presume because !thread uses the last saved
info); of course the k command will show you that stack!
Another useful command is !pcr - this shows info on the running thread.
Simon Graham
Mango
Robert Luursema wrote in message <01bd5f17$a1b78f50$1c010180@robert>...
Robert Luursema
Simon Graham <gra...@mango.com> wrote in article
<6g33t2$tji$1...@strato.ultra.net>...
Simon.
This is great info.
Where do you get it from? The online help and the MSDN Library, and the DDK
info viewer help
(Win NT DDK programmers guide ch. 4.4.1 - build in Kernel Debugging
Extensions)
list the !process and !thread command only with an optional address, but
appear to accept a lot more.
The big question is, what is their (and others) true command syntax, and
the meaning of these extra arguments?
btw. I'm using Windbg.exe from NT SP , from 26 Nov 96, 559888bytes
and KDEXTX86.DLL from 3 Aug 96, 176912 bytes. This appears quite dated to
me.
I tried to install that Jan 98 Platform SDK, but it apparently did not find
the need to write a new or different WinDbg.exe or a new kdextx86.dll to my
disk.
Probably in its 'searching for installed components' phase, it sees these
components as being uptodate.
Simon Graham
Robert Luursema wrote in message <01bd615c$bad293d0$1c010180@robert>...
>Where do you get it from? The online help and the MSDN Library, and the DDK
>info viewer help
> (Win NT DDK programmers guide ch. 4.4.1 - build in Kernel Debugging
>Extensions)
>list the !process and !thread command only with an optional address, but
>appear to accept a lot more.
>
>The big question is, what is their (and others) true command syntax, and
>the meaning of these extra arguments?
>
Guesswork mostly; a lot of the standard ! commands seem to accept a
handle/address value and an optional flags parameter. Specifying 0 for the
address/handle often seems to dump info on ALL instances of the thing being
dumped, and the flags word seems usually to be a bitmask, so I try values
with all ones and see what happens... it's a bit hit and miss really; I wish
the official documentation was better ;-(
So, for !process, it seems to be:
!process <prochandle> <flags>
If <prochandle> is zero, info on all processes is output. <flags> values I
know about:
0 - just one line per process
1 - detailed info on the process
2 - list of theads in process (one line per thread)
4 - detailed info on threads
>btw. I'm using Windbg.exe from NT SP , from 26 Nov 96, 559888bytes
>and KDEXTX86.DLL from 3 Aug 96, 176912 bytes. This appears quite dated to
>me.
>I tried to install that Jan 98 Platform SDK, but it apparently did not find
>the need to write a new or different WinDbg.exe or a new kdextx86.dll to my
>disk.
The only way I've been able to get windbag installed from the Jan98 Platform
SDK disk is via the new, unsupported, browser based installation procedure;
when the autorun html page comes up for the disk, there is an option to run
this near the place where you can select the traditional installation... all
a bit hokey really. However, the Jan98 windbag does seem to be a LOT better
than any of the previous versions I have seen...
Simon
Robert Luursema
Simon Graham <gra...@mango.com> wrote in article
<6gb6u9$gpb$1...@ligarius.ultra.net>...
> The only way I've been able to get windbag installed from the Jan98
Platform
> SDK disk is via the new, unsupported, browser based installation
procedure;
> when the autorun html page comes up for the disk, there is an option to
run
> this near the place where you can select the traditional installation...
all
> a bit hokey really. However, the Jan98 windbag does seem to be a LOT
better
> than any of the previous versions I have seen...
I've tried it, but failed. I'm using IE v3.02, and it gives a lot of
VB-script errors, and the HTML page setup is incomplete. The "Install
Components" doesn't work. The setup buttons do not function either. I'm not
going to install the IE v 4.x, because i've done that before and resulted
in a nightmare. I've also tried to install the swindbg.inf or windbg4/5.inf
from the cab directory, but that doesn't work either.
Does anyone else have a good source of the new WinDbg (and possibly
good/better documentation)?
Robert.