How do I show source code in windbg through ntsd -d?

Question

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:

1. Debug through -server and -remote
2. Breaking in a running process
3. 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?

Roseliaroselin

I still haven't found the answer, but it might have something to do with ntsd not being a graphical debugger ? – Roseliaroselin

On a related note, on the exact same setup, I can debug a kernel driver with full source code in windbg. – Roseliaroselin

If you can debug a driver you already have a connection that can as well be used to debug user mode code (i.e. your application). – Forsberg

You are right, and I do use it. But I can't get source to show ! – Roseliaroselin

not even for the driver? In this case you haven't properly configured a.) a source server, b.) the driver was not compiled on the machine running the debugger (and thus paths differ) or c.) your WinDbg is not configured properly (start WinDbg then Ctrl+P to configure the source paths or -srcpath <path> at command line). – Forsberg

No problem with the driver. I have Windbg on the host hooked to the driver, with source and everygthing. I have problem seeing the source with a custom Gina (on XP) and with an authentication package (on Windows 7). – Roseliaroselin

Is the path to the PDB available, is that path embedded in the binary as expected? This seems to be a very specific problem, but I've never had any problems with this before as long as I followed the documented steps. – Forsberg

I beleive it is, because I can see symbols and parameter information when I do x CrashMe!*. Setting breakpoints with bu also work. Everything works, but Windbg is not showing the source code, acting much like ntsd. – Roseliaroselin

No idea then, I'm afraid. Setting up the source path never failed for me like this before. Only potential reason I can think of is either WOW64 file redirection or the per-user one - for the case where your source is stored in some location that would be affected. Consider that one of the processes may run privileged while still not having full rights everywhere. – Forsberg

Answer 1

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:

1. Start your host kernel debugger
2. Start ntsd on the target machine with (for example) `ntsd -server tcp:port=50000 -ddefer test.exe`
3. Start a connection to your debug server (e.g. in WinDbg I use ctrl+r `tcp:port=50000,server=tawnos-target`)
4. The connection will hang starting. Switch to your kernel debugger (which should be sitting at Input>) and run `.sleep 5000` to allow the connection to complete
5. At this point, your remote connection should complete. You can now reload symbols as needed and use .lsrcpath to set a srcpath that windbg will use in order to view source code

Crabstick

You are rigth, using -server works for regular user mode processes. I mentionned it in my (long) post. But how can I use the -server option to debug lsass or winlogon, which I can't start myself ? – Roseliaroselin

If I'm not mistaken, this will work (I can test this Monday). Combine -server with -ddefer, rather than just using ntsd -d. This will allow you to both get the benefits of breaking in to the initial process startup as well as the remote ability to see your source code. I will verify and report back to you if I don't hear more by Monday. – Crabstick