NickName:Tiago Castro Ask DateTime:2014-12-03T20:10:15

Windows Server debugging: view User Mode Stack in WDM Kernel Mode Driver Breakpoint

I'm debugging a WDM Kernel driver IOCTL using Visual Studio Kernel Mode Debugger via pipe Serial connection to a Hyper-V VM running Windows Server 2012 R2. Once I hit a breakpoint inside the Driver IOControl is it possible to view the user mode call stack?

At the moment I can only see the kernel stack, eg:

    SIoctl!SioctlDeviceControl+0x14b [d:\workspace\ioctl\c++\sys\sioctl.c @ 320]    C/C++/ASM
    nt!IovCallDriver+0x3cd  C/C++/ASM
    nt!IopXxxControlFile+0x8d2  C/C++/ASM
    nt!NtDeviceIoControlFile+0x56   C/C++/ASM
    nt!KiSystemServiceCopyEnd+0x13  C/C++/ASM
    ntdll!NtDeviceIoControlFile+0xa C/C++/ASM
    KERNELBASE!DeviceIoControl+0x73 C/C++/ASM
    KERNEL32!DeviceIoControl+0x80   C/C++/ASM
    0x9c402408  C/C++/ASM
>   0x0000005e`2f5af9c8 C/C++/ASM

Copyright Notice：Content Author:「Tiago Castro」，Reproduced under the CC 4.0 BY-SA copyright license with a link to the original source and this disclaimer.
Link to original article：https://stackoverflow.com/questions/27271462/windows-server-debugging-view-user-mode-stack-in-wdm-kernel-mode-driver-breakpo

Answers

Remus Rusanu 2014-12-03T12:26:15

Yes, you need to switch to the desired process first and then you have access to it's stack(s). See .process:\n\n\n The .process command instructs the kernel debugger to use a specific user-mode process as the process context. This usage has several effects, but the most important is that the debugger has access to the virtual address space of this process. The debugger uses the page tables for this process to interpret all user-mode memory addresses, so you can read and write to this memory.\n \n Note If you are performing live debugging, you should use the /i or the /p parameter. Without one of these parameters, you cannot correctly display user-mode or session memory.\n The /i parameter activates the target process. When you use this option, you must execute the target once for this command to take effect. If you execute again, the process context is lost.\n The /p parameter enables the forcedecodeuser setting. (You do not have to use /p if the forcedecodeuser option is already active.) The process context and the forcedecodeuser state remain only until the target executes again.\n\n\nI am aware you asked about Visual Studio and I answered about WinDbg. I think you should use a tool appropriate for the job. WinDbg is infinitely more flexible and more powerful when it comes to debugging. I think in VS you would use the Process context, but I would recommend, again, use WinDbg.",