如何通过ntsd -d在windbg中显示源代码？ [英] How do I show source code in windbg through ntsd -d?

问题描述

当我通过 windbg -k 管道 c> ntsd -d 时，我无法在windbg中显示源代码c>，但是当我在本地调试时它工作。

我想调试Winlogon.exe和LSASS.exe的第一个代码执行。但是为了方便重现这个问题，我做了这个设置：

• 我使用 CrashMe示例应用程序，源和符号预先构建，复制到目标和主机上的C：\CrashMe
• 
  
• 我使用Windows调试工具（DTW）6.12.0002.633到处。


• 目标是运行Windows XP SP3，主机Windows 7终极。


• 每个路径和设置在两台机器上是相同的：DTW的路径和通往crashme的路径。


• 我总是使用完全限定的路径（如c：\dtw\\\
  tsd.exe）。


• 我在VM中运行XP，由$ code> / noexecute = optin / fastdetect / debug / debugport = com1 / baudrate = 115200

我可以使用这个命令调试本地，从C：\CrashMe启动：

  windbg -g  - G -srcpath C：\CrashMe -y C：\CrashMe debug\CrashMe.exe 
  

我可以启动Windows XP虚拟机，并使用以下命令连接到它：

  windbg -n -k com：pipe，port = \\.\pipe\com_1，重新连接-srcpath SRV *; C：\CrashMe -y 
c：\windows\system32; c：\windows\symbols; C：\\ \\ CrashMe\debug 
  

但我需要调试远程机器。在目标上，我有以下选择：

1. 通过 -server 和 -remote


2. 打破正在运行的过程


3. 使用图像文件执行选项（IFEO）。

在每个这些选项中，我可以看到符号（ x crashme！* 作品）

我不能使用＃1（ -server ）或＃2（ breakin.exe< pid> ），因为我想调试验证提供程序的启动代码，所以我需要 LSASS.exe start在 ntsd -d 下。我不能让它运行，稍后再加上。

我的理解是我需要使用IFEO。使用gflags.exe而不是手动修改注册表，我将可执行选项设置为

  c：\dtw\\\
tsd -d -G -lines -x -yc：\symcache; c：\windows\system32 -n -srcpath C：\CrashMe\ 
  

• 我可以打破应用程序，但我设置的断点永远不会被打。


• 我可以 .open 任何文件，但我无法使用该文件设置断点。


• 我可以x（检查）任何符号


• 我看不到源代码。

如何查看我的DLL源代码， code> ntsd -d 通过 windbg -k ？

解决方案

TL; DR：使用-server< TRANSPORT> -ddefer并连接通过一个第二个windbg会话，其中设置了.lsrcpath来获取你想要的。

其余的：
源模式需要从系统运行的访问调试器到源文件。在通过内核模式连接调试用户模式代码的情况下，这变得棘手。由于测试正在目标机器上的ntsd上下文中执行，并且该机器被分解到调试器中，因此加载源文件通常不起作用。我相信如果您将完整的源代码树放在目标机器上或将源路径指向一个共享，那么可能，但是我还没有验证过。

验证是您可以使用此方法来获取在主机中加载的源文件。

通过执行以下操作：

1. 启动您的主机内核调试器


2. 在目标机器上启动ntsd（例如）`ntsd -server tcp：port = 50000 -ddefer test.exe`


3. 开始连接到调试服务器（例如在WinDbg中我使用ctrl + r`tcp：port = 50000，server = tawnos-target`）


4. 连接将挂起。切换到内核调试器（应该位于Input>）并运行`.sleep 5000`以允许连接完成


5. 此时，您的远程连接应该完成。您现在可以根据需要重新加载符号，并使用.lsrcpath设置windbg将使用的srcpath来查看源代码

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?

解决方案

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

这篇关于如何通过ntsd -d在windbg中显示源代码？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！