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:
/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:
-server
and -remote
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\
.open
any file, but I can't use the file to set breakpoint.How can I see my DLL source code of a process running under ntsd -d
through windbg -k
?
If you include the string srv* in your symbol path, the debugger uses a symbol server to get symbols from the default symbol store. For example, the following command tells the debugger to use a symbol server to get symbols from the default symbol store. These symbols are not cached on the local computer.
The Debugger Command window is split into two panes. You type commands in the smaller pane (the command entry pane) at the bottom of the window and view the output in the larger pane at the top of the window. In the command entry pane, use the UP ARROW and DOWN ARROW keys to scroll through the command history.
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:
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With