How to get a list of all threads whose call stack contains my driver

WINDBG
1

Hi,

I am relatively new to WinDbg and I don’t know how I can do something
that should be doable, but is a bit advanced. I am sure this must have
been discussed somewhere, but I was not successful in my attempt to
locate a related topic in the WinDbg help file. I also tried searching
the WinDbg mailing list archive but it seems that my queries were not
good enough. So here I am. I plan to take the next WinDbg OSR seminar in
January but I need an answer before then :slight_smile:

So here’s my situation:
I have a system that is doing lots of stuff for some hours but suddently
freezes on the UI level. I connect with WinDbg and the system is alive.
The system is running the debug version of our drivers (there are a
couple of them). The drivers are quite verbose when anything goes wrong,
but there are no error messages being generated if I press F5 to let the
system continue with what it was doing.

So I am trying to understand what is going on, what my drivers are doing
at the moment. I could start spreading breakpoints around, but instead
of that random search I think the following is a more reasonable
approach:

“Break. Get a list of all threads whose call stack contains my driver”.

I figure that this way I can then see each thread’s call stack to find
out what each thread is doing and get some hint what to look for next.

Can anybody tell me how to do this? I expect it should be doable
somehow.

This week I also received the SysInternals videos but only had the
chance to checkout the first one (tour of the tools). There I found out
that with LiveKd you can take a dump from a live system so you can
examine it with WinDbg. That’s cool, but in that case as well the first
thing I would like to know is “What were my drivers doing at the moment
the dump was generated?”. So the same question arises again.

Thanks in advance!

–
The fact that the program works is irrelevant.

2

Have Windbg create a log file. Run ‘!process 0 7’ and look at all user
processes and their threads. You can then search for threads with your
driver in their call stack. That will get you all you need including system
threads under the system process.

“Dimitris Staikos” wrote in message
news:xxxxx@windbg…
Hi,

I am relatively new to WinDbg and I don’t know how I can do something
that should be doable, but is a bit advanced. I am sure this must have
been discussed somewhere, but I was not successful in my attempt to
locate a related topic in the WinDbg help file. I also tried searching
the WinDbg mailing list archive but it seems that my queries were not
good enough. So here I am. I plan to take the next WinDbg OSR seminar in
January but I need an answer before then :slight_smile:

So here’s my situation:
I have a system that is doing lots of stuff for some hours but suddently
freezes on the UI level. I connect with WinDbg and the system is alive.
The system is running the debug version of our drivers (there are a
couple of them). The drivers are quite verbose when anything goes wrong,
but there are no error messages being generated if I press F5 to let the
system continue with what it was doing.

So I am trying to understand what is going on, what my drivers are doing
at the moment. I could start spreading breakpoints around, but instead
of that random search I think the following is a more reasonable
approach:

“Break. Get a list of all threads whose call stack contains my driver”.

I figure that this way I can then see each thread’s call stack to find
out what each thread is doing and get some hint what to look for next.

Can anybody tell me how to do this? I expect it should be doable
somehow.

This week I also received the SysInternals videos but only had the
chance to checkout the first one (tour of the tools). There I found out
that with LiveKd you can take a dump from a live system so you can
examine it with WinDbg. That’s cool, but in that case as well the first
thing I would like to know is “What were my drivers doing at the moment
the dump was generated?”. So the same question arises again.

Thanks in advance!

–
The fact that the program works is irrelevant.

3

Looks like deadlock condition, you will have to look at.

Something to start with (until January :-)):

  • Make sure you have right symbols (.PDB) for WinDbg session. In this
    list archives you will find a lot of topics related to “how to configure
    symbols for windbg”.
  • Enable Verifier (its “WXP and latter” standard OS tools), to check
    your drivers.
  • If your driver is from File System “namespace” drivers, then WinDbg
    “!locks” will dump threads that are waiting and owning ERESOURCEs.
    ERESOURCEs are mostly used in File System (filter) drivers for
    synchronization. ERESOURCE keep list of waiters and owner (KEVENT does
    not), so its *easy* to find deadlock on ERESOURCE.
  • As last resource, you always have “!process 0 7” which will dump all
    threads and their call stack (if WinDbg symbols are configured OK). You
    can redirect WinDbg output to text file, where you can analyze its well
    formatted content (search, sort, …).
  • From “!process 0 7”, you can get a list of threads waiting for KEVENT
    (parameter to KeWaitFor…()), but unfortunately you can’t get owner of
    KVENT.
  • Good luck :-).

Deadlocks are difficult to analyze. The last I was dealing with was
because a use of System worker thread item (OS limited resource) was
requested from thread that owned some resource, that all(!) other System
worker threads were waiting for.

WBR Primoz

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dimitris Staikos
Sent: 2. oktober 2006 8:27
To: Kernel Debugging Interest List
Subject: [windbg] How to get a list of all threads whose call stack
contains my driver

Hi,

I am relatively new to WinDbg and I don’t know how I can do something
that should be doable, but is a bit advanced. I am sure this must have
been discussed somewhere, but I was not successful in my attempt to
locate a related topic in the WinDbg help file. I also tried searching
the WinDbg mailing list archive but it seems that my queries were not
good enough. So here I am. I plan to take the next WinDbg OSR seminar in
January but I need an answer before then :slight_smile:

So here’s my situation:
I have a system that is doing lots of stuff for some hours but suddently
freezes on the UI level. I connect with WinDbg and the system is alive.
The system is running the debug version of our drivers (there are a
couple of them). The drivers are quite verbose when anything goes wrong,
but there are no error messages being generated if I press F5 to let the
system continue with what it was doing.

So I am trying to understand what is going on, what my drivers are doing
at the moment. I could start spreading breakpoints around, but instead
of that random search I think the following is a more reasonable
approach:

“Break. Get a list of all threads whose call stack contains my driver”.

I figure that this way I can then see each thread’s call stack to find
out what each thread is doing and get some hint what to look for next.

Can anybody tell me how to do this? I expect it should be doable
somehow.

This week I also received the SysInternals videos but only had the
chance to checkout the first one (tour of the tools). There I found out
that with LiveKd you can take a dump from a live system so you can
examine it with WinDbg. That’s cool, but in that case as well the first
thing I would like to know is “What were my drivers doing at the moment
the dump was generated?”. So the same question arises again.

Thanks in advance!

–
The fact that the program works is irrelevant.

You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

4

!stacks 2 yourdriver

“Dimitris Staikos” wrote in message
news:xxxxx@windbg…
Hi,

I am relatively new to WinDbg and I don’t know how I can do something
that should be doable, but is a bit advanced. I am sure this must have
been discussed somewhere, but I was not successful in my attempt to
locate a related topic in the WinDbg help file. I also tried searching
the WinDbg mailing list archive but it seems that my queries were not
good enough. So here I am. I plan to take the next WinDbg OSR seminar in
January but I need an answer before then :slight_smile:

So here’s my situation:
I have a system that is doing lots of stuff for some hours but suddently
freezes on the UI level. I connect with WinDbg and the system is alive.
The system is running the debug version of our drivers (there are a
couple of them). The drivers are quite verbose when anything goes wrong,
but there are no error messages being generated if I press F5 to let the
system continue with what it was doing.

So I am trying to understand what is going on, what my drivers are doing
at the moment. I could start spreading breakpoints around, but instead
of that random search I think the following is a more reasonable
approach:

“Break. Get a list of all threads whose call stack contains my driver”.

I figure that this way I can then see each thread’s call stack to find
out what each thread is doing and get some hint what to look for next.

Can anybody tell me how to do this? I expect it should be doable
somehow.

This week I also received the SysInternals videos but only had the
chance to checkout the first one (tour of the tools). There I found out
that with LiveKd you can take a dump from a live system so you can
examine it with WinDbg. That’s cool, but in that case as well the first
thing I would like to know is “What were my drivers doing at the moment
the dump was generated?”. So the same question arises again.

Thanks in advance!

–
The fact that the program works is irrelevant.