wenmo8 发布的文章

我想我不需要强调在调试时拥有有效的PDB文件有多重要。通常，PDB文件是由调试器静默加载的，并且您很高兴在modules窗口中看到解析的所有符号。不幸的是，您还可能遇到调试器找不到匹配符号的情况。其原因可能与断开的互联网连接或更复杂的签名不匹配一样微不足道。在本文中，我将向您展示如何在调试之前检查符号文件，以及如何从中提取源文件信息。由于有不同的方法（和工具）来操作符号文件，我将介绍我所知道的那些。

下载给定PE文件的PDB文件

由于PDB文件格式是微软的秘密，所以我介绍的所有工具都只是API的包装器。要处理PDB文件，我们首先需要获取它们。让我们列出能帮助我们的工具。

symchk.exe

符号检查器（Symchk.exe）是一个应用程序，它将可执行文件与符号文件进行比较，以验证匹配的符号是否可用。Symchk也可以用于填充符号缓存。它可以从PE文件（exe，dll）、转储文件和进程中读取符号信息。它还支持递归目录搜索和批处理文件。

我们将从加载kernel32.dll库的符号开始：


c:\Windows\System32>echo %_NT_SYMBOL_PATH%

Visual Studio是一个很大的工具。很容易遗漏一些有用的特性。希望XSLT调试器不会错过。在下面，您可以看到调试器正在运行，因为xslt转换正在应用于某些XML。（请原谅我在示例中使用的毫无意义的XSLT。我有很长一段时间没有机会使用XSLT了。）

 

XSLT调试对我来说很有趣，因为它大部分是托管调试器。XSLT编译为msil，托管调试器用于提供断点和单步执行等功能。打开“模块”窗口可以看到这一点。在最后一列中，您将看到该进程是一个名为Microsoft.XSLDebugProxy.exe的托管进程，并且将有一些模块加载名称，如System.Xml.Xsl.CompiledQuery.1。所有调试器窗口都按预期工作：callstack、locals、immediate、threads、modules。您可以在下面的调用堆栈中看到我的无意义示例：

 

 然而！转到callstack窗口并右键单击以获取上下文菜单。将有一个名为Show External Code的项。选择这个选项，您可以在之前隐藏的callstack窗口中看到很多内容。灰色的帧是因为该程序集没有调试信息（pdb文件），这就是为什么这些帧以前被标记为“外部代码”的原因。已编译的查询帧被隐藏，因为XSLT编译器在它们上放置了一个属性，告诉调试器它们不感兴趣。使用扩展视图，您现在可以看到已编译的查询和调度它的代码。

 

然而，尽管这很有趣，但它不太可能帮助您了解XSLT中的错误。但是，“局部”窗口似乎是更有用的窗口之一，它可以帮助您查看应用变换时发生的情况。

当我在别人的机器上调试问题时，我做的第一件事就是查看modules窗口。按版本排序并看到一个不属于的dll可以帮助立即诊断配置问题，并节省许多调试痛苦。

 

 下面介绍下各列的意思：

  • Name:
    模块名称。
  • Path:
    PE在文件系统上的位置。当您希望找到正确的PE以开始使用命令行工具进行查询时，这非常有用。
  • Optimized:这是针对托管代码的。它告诉您，当从MSIL转到目标平台本机指令集时，JIT编译器是否使用了优化。
  • User Code:在调试器选项中，它也被称为“只是我的代码”。如果您刚刚打开了我的代码，并且dll已优化或没有符号，我们将把它视为“非用户”代码。这意味着调用堆栈窗口中的所有帧都将折叠到一个[非用户代码]帧之后。默认情况下，这个特性是关闭的C++，以及VB和C用户配置文件。您可以在Tools/options/Debugging/Enable-Just-My-Code下切换它。“JMC”的全部分支比简单地隐藏调用堆栈帧要大得多。它包括遍历非用户代码，一直到代码开始运行的地方（并且执行得很快）。Mike Stall在博客中提到了其中一些。
  • Symbol Status:这将告诉您是否加载了符号。它还可以告诉您它们是否被剥离（实际上只是一个本地dll问题），或者devenv是否只是加载了导出。如果您正在执行崩溃转储调试，它还可以判断是否已找到二进制文件。右键单击上下文菜单，您可以加载符号，跳转到“符号设置…”对话框，还可以查看我们搜索符号的位置。
  • Symbol File:pdb文件所在的位置。上下文菜单项“符号加载信息…”可以告诉您调试器查找符号的位置。
  • Order:加载顺序
  • Version: dll的版本信息。这对于将相关组件组合在一起非常有用，并且通常会在有人的版本不好时向您显示。查看我们在visual studio版本字符串中保留的信息量。
  • Timestamp: 这是真正的交易-链接器（或.Net编译器）生成并将PE发送到世界上时的内部时间戳。
    看看这个：
    C:\Program Files\Internet Explorer>dir iexplore.exe
     Volume in drive C has no label.
     Volume Serial Number is 2CAB-3E87

     Directory of C:\Program Files\Internet Explorer

    08/04/2004  05:00 AM            93,184 IEXPLORE.EXE
    文件系统的时间戳是什么。如果你想知道它什么时候落在你的硬盘上就好了。对于确定它比过程中的所有相关组件都晚2天构建来说，没有那么有用。
    C:\Program Files\Internet Explorer>dumpbin /headers IEXPLORE.EXE | findstr time
            41107B81 time date stamp Tue Aug 03 23:00:33 2004
    这是你真正想要的。好...这是我真正想要的。这就是你在这个专栏里看到的。在VS之前的版本中，托管代码的时间戳是不太有用的文件系统时间戳。

  • Address:
    进程内存中PE的加载地址范围。最左边是一列没有标题的图标。如果图标看起来像一个小页面，则此地址是首选加载地址。如果它有一个带有红色感叹号的页面，那么这个PE在加载时被重新定位。如果你拥有这个PE，找到一个它自己的地方，它可能加载得更快。
  • Process:
    进程名：其中之一（本机或托管）。注意：如果您正在进行混合模式调试，那么许多dll实际上会在“模块”窗口中有行。一个用于“本机”dll加载。。。在某种程度上，一切都是土生土长的。一个用于托管dll加载。您可以知道它们是同一个dll，因为地址范围将匹配。基名可能不匹配，因为有时NGen的dll显示时，名称中添加了“ni”扩展名。（例如Microsoft.Build.utilities.ni.dll。）

通过单击并拖动列，可以更改“模块”窗口中列的顺序。还可以通过拖动边框来调整列的大小。另一个巧妙的技巧是通过标题栏上的上下文菜单将窗口设置为选项卡式文档。你可以在devenv的任何一个窗口中完成这项工作。

0×01 介绍

一些文章已经介绍过通过检测异常来对抗调试器的技术。这个思想很简单：根据设计本意，调试器会处理特定的异常。如果一个异常包裹在try块中，只有当没有附加调试器的时候，异常处理程序才会执行。因此，可以得出结论，只要异常块没有执行，那么程序就正在被一个调试器调试。

0×02 一个字节的Interrupt 3中断（0xCC）

在所有会被调试器处理的异常中，interrupt 3中断算是一个，它会生成一个单字节的断点。

BOOL IsDebuggerPresent_Int3()

{

      __try

      {

            __asm int 3

      }

      __except(1)

      {

            return FALSE;

      }

 

      return TRUE;

}

0×03 两个字节的Interrupt 3中断（0xCD 0×03）

使用Visual C++内联汇编器的_emit伪指令可以生成一个两字节的interrupt 3指令。在测试的所有调试器中，只有OnllyDbg调试器识别这个异常。

 

 

BOOL IsDebuggerPresent_Int3_2Byte()

{

      __try

      {

            __asm

            {

                  __emit 0xCD

                  __emit 0x03

            }

      }

      __except(1)

      {

            return FALSE;

      }

 

      return TRUE;

}

 

0×04 Interrupt 0x2C中断

Interrupt 0x2C引起一个调试断言异常。WinDbg会响应这个异常，但是其它的调试器都不会处理它。这个指令可以使用_int 2c来生成。这个中断只在Vista以及之后的系统上有效。因为这一点，需要动态检查windows的版本，如果版本号小于6就返回false。

 

BOOL IsDebuggerPresent_Int2c()

{

      OSVERSIONINFO osvi;

 

      ZeroMemory(&osvi, sizeof(OSVERSIONINFO));

      osvi.dwOSVersionInfoSize = sizeof(OSVERSIONINFO);

 

      GetVersionEx(&osvi);

 

      if (osvi.dwMajorVersion < 6)

            return FALSE;

 

      __try

      {

            __int2c();

      }

      __except(1)

      {

            return FALSE;

      }

 

      return TRUE;

}

 

0×05 Interrupt 0x2D

如果执行了interrupt 0x2D，Windows将抛出一个断点异常

BOOL IsDebuggerPresent_Int2d()
{
__try
{
__asm int 0x2d
}
__except(1)
{
return FALSE;
}

return TRUE;
}

0×06 ICEBP（0xF1）

ICEBP是一个没有文档化的指令，可以作为一个单字节的interrupt 1中断，产生一个单步异常。

BOOL IsDebuggerPresent_IceBp()
{
__try
{
__asm __emit 0xF1
}
__except(1)
{
return FALSE;
}

return TRUE;
}

0×07 陷阱标志位

EFLAGS寄存器的第八个比特位是陷阱标志位。如果设置了，就会产生一个单步异常。

BOOL IsDebuggerPresent_TrapFlag()
{
__try
{
__asm
{
pushfd
or word ptr[esp], 0x100
popfd
nop
}
}
__except(1)
{
return FALSE;
}

return TRUE;
}

0×08 抛出异常

RaiseException函数产生的若干不同类型的异常可以被调试器捕获。在RaiseException的基础上，OutputDebugString，该函数常被用来检测附加的调试器。有效的异常码如下所示：

STATUS_BREAKPOINT                                   (0x80000003)
STATUS_SINGLE_STEP                                   (0x80000004)    
DBG_PRINTEXCEPTION_C                            (0x40010006)
DBG_RIPEXCEPTION                                       (0x40010007)
DBG_CONTROL_C                                           (0x40010005)
DBG_CONTROL_BREAK                                 (0x40010008)
DBG_COMMAND_EXCEPTION                   (0x40010009)
ASSERTION_FAILURE                                     (0xC0000420)
STATUS_GUARD_PAGE_VIOLATION       (0x80000001)
SEGMENT_NOTIFICATION                           (0x40000005)
EXCEPTION_WX86_SINGLE_STEP             (0x4000001E)
EXCEPTION_WX86_BREAKPOINT              (0x4000001F)
BOOL TestExceptionCode(DWORD dwCode)
{
__try
{
RaiseException(dwCode, 0, 0, 0);
}
__except(1)
{
return FALSE;
}

return TRUE;
}

BOOL IsDebuggerPresent_RipException()
{
return TestExceptionCode(DBG_RIPEXCEPTION);
}

0×09 兼容性表

Windbg调试器的！htrace扩展对于调试泄漏处理非常方便。
该过程基本上可归结为以下简单步骤：

  1. 启用跟踪
  2. 拍张快照
  3. 情景分析
  4. 显示差异

在第四步！htrace将在最后一个快照之后显示所有额外打开的句柄，以及调用堆栈（如果可用）。这大大有助于调试哪些句柄是泄漏的，以及由谁来处理。与其他任何资源泄漏检测工具一样，也会有误报。您需要了解什么是真正的泄漏，什么只是暂时的分配。

  1. 1
  2. ...
  3. 1376
  4. 1377
  5. 1378
  6. 1379
  7. 1380
  8. 1381
  9. 1382
  10. ...
  11. 1491