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

Question

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

Answer 1

I have tried that by using !process 0 0 app.exe and then doing .process /i pid or .process /P id as well, both fail to display the user stack. I think it's because I'm already in that process, even thought it is inside the kernel driver, the running process is the application.exe. So when I either look in the call stack window or type in k I only see the kernel stack.

The "Visual studio way" of "switching" to different processes does not seem to work, the only thing I can do is walk around the different stack frames (within only the kernel stack - same as shown in the call stack window).

I'll try doing it in WinDbg see if it's any different.

EDIT:

I did something different now, after switching the context I did !threads and then .thread to the one thread that showed up and it is now working within a sleep call. Somehow in my IOCTL it does not work. But I tried it now using WinDbg and it works wonderfully!

Many Thanks!

Answer 2

Yes, you need to switch to the desired process first and then you have access to it's stack(s). See .process:

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.

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. 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. 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.

I 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.