Correct symbols are also required to do an accurate stack walk on x86
code. That is probably what “the stack for that thread notes that the
stack frame may be invalid.” means.
See http://www.microsoft.com/ddk/debugging on how to get OS symbols.
As Tony pointed out the k* commands can take parameters to use to start
a stack walk. That can be useful to skip sections of the stack that are
corrupted or skip a section with bad symbols.
-----Original Message-----
From: Tony Mason [mailto:xxxxx@osr.com]
Sent: Friday, August 09, 2002 4:15 PM
To: Kernel Debugging Interest List
Subject: [windbg] RE: Searching for the correct stack frame.
You can manually provide the EBP, EIP and ESP to the “kv” command in
WinDBG (funny thing is that I had to show people how to do this last
week in debug class because we had a stack with a driver where they did
not have symbols.)
You can also use the “!kdex2x86.stack” command (on NT 4.0 and W2K) and
it will provide you with every possible stack frame that it can find on
the stack - but realize it may show you garbage as well, since the stack
is re-used. However, it can be an excellent tool for finding a clean
stack frame that you can use to then feed into the “kv” command.
My technique for doing this is to attempt to find a call instruction (so
I know the EIP) because I can identify the return address (on the stack)
and the EBP (IF the function I called starts with push EBP, which is
sometimes the case). This gives me the EBP (the value following the
return address) the ESP (the address where the return address is stored)
and the EIP (the instruction BEFORE the return address, which is going
to be a call).
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@conexant.com [mailto:xxxxx@conexant.com]
Sent: Friday, August 09, 2002 6:06 PM
To: Kernel Debugging Interest List
Subject: [windbg] Searching for the correct stack frame.
Hi All,
I am debugging Kernel-mode drivers. I have a situation where a thread
in a sys file calls another sys file, which calls a function in another
sys
file. The stack actually gets pretty “Deep” at this point, and somehow
the thread is stuck in a “running” state.
Whenever I do a !thread on it, I can see that it is running state
(0x0000500). However, the stack for that thread notes that the stack
frame may be invalid. And, the only 2 things I see on the stack is the
“DbgBreakPoint” and “KeUpdateSystemTime”. I know there must be at
least
10+ function calls on the stack, so I assume hopping from driver to
10+ driver,
may get the debugger confused (?).
Anyway, is there a way to search for the stack manually, or see what the
last instruction that executed in that thread was, so I can see where
the
deadloop is? I tried to look into the “Current” stack location given
by
the !thread command, but it does not seem to be accurate for the thread
(?)
Thanks!
You are currently subscribed to windbg as: xxxxx@osr.com
To unsubscribe send a blank email to %%email.unsub%%
You are currently subscribed to windbg as: xxxxx@microsoft.com To
unsubscribe send a blank email to %%email.unsub%%