CODEWITHSUNDEEP
windbg
Jimm Chen
Jimm Chen

Reputation: 3777

How to examine user thread call stack from windbg kernel debugger?

My exe-once test program calls CancelIo and it blocks, I'd like to investigate in which function it is blocking, so, when it blocks, I use windbg to break into the machine, remotely, and try to find it out.

As marked as yellow in the image, my EXE has two threads, fffffa8013958b60 and fffffa8013aa1060. I already know that fffffa8013aa1060 is the one calling CancelIo.

Then, how do I show current call stack of the thread fffffa8013aa1060?

enter image description here

1: kd> !process fffffa8014c25170 2
PROCESS fffffa8014c25170
    SessionId: 1  Cid: 0ad4    Peb: 7fffffdf000  ParentCid: 07b8
    DirBase: 2b451000  ObjectTable: fffff8a002e61620  HandleCount:  12.
    Image: exe-once.exe

        THREAD fffffa8013958b60  Cid 0ad4.0724  Teb: 000007fffffdd000 Win32Thread: 0000000000000000 WAIT: (UserRequest) UserMode Non-Alertable
            fffffa8013aa1060  Thread

        THREAD fffffa8013aa1060  Cid 0ad4.01e8  Teb: 000007fffffdb000 Win32Thread: 0000000000000000 WAIT: (DelayExecution) KernelMode Non-Alertable
            fffffa8013aa1420  Semaphore Limit 0x1

Upvotes: 2

Views: 2007

Answers (1)

pykd_team
pykd_team

Reputation: 131

try this command sequence

.process /i fffffa8014c25170 
g
.thread fffffa8013aa1060
.reload /user
k

Excerpt from WinDbg documentation:

/i [...] Specifies that Process is to be debugged invasively. This kind of debugging means that the operating system of the target computer actually makes the specified process active. [...] If you use /i, you must use the g (Go) command to execute the target. After several seconds, the target breaks back in to the debugger, and the specified Process is active and used for the process context.

Upvotes: 5

Related Questions