Kernel mode debug, how to switch to user mode

[Monique]

I am investigating a BSOD full dump. When load it in Windbg, it defaults to
kernel mode.

How can I switch kernel mode to user mode and get user mode call stack etc?

[Pavel A.]

"Monique" <Mon...@discussions.microsoft.com> wrote in message
news:A94BA89C-EB43-4640...@microsoft.com...

It should just work. Be sure to load correct usermode symbols ( .symfix ,
.reload etc).
Also, you may need to increase number of displayed stack frames
( click on the "more" button in the calls window )

--pa

[Monique]

Pavel,

Would you please share the steps/commands you use to switch from kernel mode
to user mode.

Thank you very much!

[xyz]

Theoretically, there are many options you can transit to user mode
from Kernel mode.

a) Determine exactly what do you need [Are you specific about some
process, then dump all the process running on the system !process 0 0]
b) Use this commands to reload all symbols [.reload /f]
c) To dump full stack use the commands like these [kn 100]

Again, Exactly depends what you want to look.

[Pavel A.]

Hi Monique,

I don't switch from kernel mode to user mode.
What I wrote is that windbg usually can display the usermode stack from
kernel mode,
without any special steps. Just be sure to load the correct symbols.

Regards,
--pa

"Monique" <Mon...@discussions.microsoft.com> wrote in message

news:CE0CC5DC-8C0B-492D...@microsoft.com...

[Scott Noone]

If you elaborate on what you're trying to do and what you're seeing I'm sure
someone here can help you out.

-scott

--
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

"Monique" <Mon...@discussions.microsoft.com> wrote in message

news:CE0CC5DC-8C0B-492D...@microsoft.com...

[Monique]

Pavel and Scott,

In kernel mode, debug the full memory dump we have, kb lists partial call
stack. more/less doesn't expand it.

Here is what we found. After getting call stack in kernel mode, in memory
window, start from the topmost functions's EBP address which contains the
return address of the previous call, trace all the way back, we got back to
the user mode.

You may find this article fun.
http://www.wd-3.com/archive/favcommands.htm

Thank you all!
Monique

[Scott Noone]

> In kernel mode, debug the full memory dump we have, kb lists partial call
> stack. more/less doesn't expand it.

You have one of two problems:

1) Your stack frame depth is too short, try .kframes 1000

2) When you switch to a thread in a different process, you also need to
switch the debugger process context. Otherwise you're using the current
address space to translate virtual addresses from a different address space.
You can see the difference in this example:

Thread I want to switch to is in a different process that the current
process:
0: kd> !thread -p 8131d990 0
PROCESS 8133a020 SessionId: 0 Cid: 0824 Peb: 7ffda000 ParentCid: 04dc
DirBase: 02200420 ObjectTable: e10442a8 HandleCount: 207.
Image: wuauclt.exe

0: kd> !process -1 0
PROCESS 815f6920 SessionId: 0 Cid: 075c Peb: 7ffde000 ParentCid: 0718
DirBase: 02200260 ObjectTable: e17a12e8 HandleCount: 510.
Image: explorer.exe

If I just switch, stack walk will stop once I hit user mode:
0: kd> .thread 8131d990
Implicit thread is now 8131d990
0: kd> kc
*** Stack trace for last set context - .thread/.cxr resets it
nt!KiSwapContext
nt!KiSwapThread
nt!KeDelayExecutionThread
nt!NtDelayExecution
nt!KiFastCallEntry
ntdll!KiFastSystemCallRet
WARNING: Frame IP not in any known module. Following frames may be wrong.
0x0
0x0

However, do a thread switch and a process switch and you'll get better
results:
0: kd> .thread /r /p 8131d990
Implicit thread is now 8131d990
Implicit process is now 8133a020
Loading User Symbols
..........................................
0: kd> kc
*** Stack trace for last set context - .thread/.cxr resets it
nt!KiSwapContext
nt!KiSwapThread
nt!KeDelayExecutionThread
nt!NtDelayExecution
nt!KiFastCallEntry
ntdll!KiFastSystemCallRet
ntdll!NtDelayExecution
ntdll!RtlpTimerThread
kernel32!BaseThreadStart

(Note that /r /p are documented as live debug only for .thread but seem to
work fine with full memory dumps. Either that's a doc bug or there's going
to be some edge case where that doesn't work. In that case, .process can be
used instead.)

HTH,

-scott

--
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

"Monique" <Mon...@discussions.microsoft.com> wrote in message

news:75D5F7B5-D62C-4D6E...@microsoft.com...

[Monique]

Scott,

I don't have pdb for the crashed exe :(

I tried setting crashed process and thread as current context, still
couldn't get the full call stack. Have saved your suggestion for future
reference.

I appreciate your help!
Regards,
Monique

"Scott Noone" wrote:

> ...........................................