I can't make source code show in windbg when I pipe ntsd -d
on the target through windbg -k
, but it works when I debug locally.
I want to debug the very first code execution of Winlogon.exe and LSASS.exe. But to make it easy to reproduce the problem, I made up this setup:
- I use the CrashMe sample application, with source and symbols pre-built, copied to C:\CrashMe on both the target and host
- I use Windows Debugging tools for Windows (DTW) version 6.12.0002.633 everywhere.
- The target is running Windows XP SP3, the host Windows 7 ultimate.
- Every path and settings is the same on both machine : path to DTW and path to crashme.
- I always use fully qualified path (like c:\dtw\ntsd.exe).
- I run a XP in a VM, booted with
/noexecute=optin /fastdetect /debug /debugport=com1 /baudrate=115200
I am able to debug locally with this command, launched from C:\CrashMe:
windbg -g -G -srcpath C:\CrashMe -y C:\CrashMe debug\CrashMe.exe
I can launch the Windows XP virtual machine and connect to it with this command:
windbg -n -k com:pipe,port=\\.\pipe\com_1,reconnect -srcpath SRV*;C:\CrashMe -y
c:\windows\system32;c:\windows\symbols;C:\CrashMe\debug
But I need to debug a remote machine. On the target, I have these choices:
- Debug through
-server
and-remote
- Breaking in a running process
- Use Image File Execution Options (IFEO).
In each of these options I can see the symbols (x crashme!*
works).
I cannot use #1 (-server
) or #2 (breakin.exe <pid>
), because I want to debug the startup code of an authentication provider, so I need LSASS.exe
start under ntsd -d
. I can't let it run and attach later on.
My understanding is that I need to use IFEO. Using gflags.exe instead of modifying the registry manually, I set executable options to
c:\dtw\ntsd -d -G -lines -x -y c:\symcache;c:\windows\system32 -n -srcpath C:\CrashMe\
- I can breakin the application, but breakpoints I set are never hit.
- I can
.open
any file, but I can't use the file to set breakpoint. - I can x (examine) any symbol
- I can not see the source code.
How can I see my DLL source code of a process running under ntsd -d
through windbg -k
?
TL;DR: Use -server <TRANSPORT> -ddefer and connect through a second windbg session that has .lsrcpath set to get what you want.
The rest: Source mode requires access from the system running the debugger to the source files. In the case of debugging user mode code over the kernel mode connection, this becomes tricky. Since the test is executing in the context of ntsd on the target machine, and that machine is broken into the debugger, loading source files generally doesn't work. I believe if you put a full source tree on the target machine or pointed the source path to a share, it might, but I haven't verified that.
What I did verify is that you can use this method to get source files loaded in your host machine.
This works by doing the following: