简介

DBG_PRINTEXCEPTION_C，代码0x40010006；DBG_PRINTEXCEPTION_WIDE_C，代码0x4001000A；在调试器的控制台窗口打印异常信息/调试信息。它定义在 ntstatus.h头文件里，如下：

//
// MessageId: DBG_PRINTEXCEPTION_C
//
// MessageText:
//
// Debugger printed exception on control C.
//
#define DBG_PRINTEXCEPTION_C             ((NTSTATUS)0x40010006L)    // winnt

//
// MessageId: DBG_PRINTEXCEPTION_WIDE_C
//
// MessageText:
//
// Debugger printed exception on control C.
//
#define DBG_PRINTEXCEPTION_WIDE_C        ((NTSTATUS)0x4001000AL)    // winnt

它们唯一的差别是，DBG_PRINTEXCEPTION_C是多字节版本的，DBG_PRINTEXCEPTION_WIDE_C是Unicode版本的。

触发条件

OutputDebugString和其他类似的函数能有效地导致引发Windows异常（DBG_PRINTEXCEPTION_C或DBG_PRINTEXCEPTION_WIDE_C）。附加调试器后，Windows将接收异常并通知调试器。如果没有附加调试器，则将异常传递给程序（作为可继续的错误）。如果程序没有处理异常的处理程序，则继续生活。如果程序执行了，则调用该异常处理程序。，因为通常没有理由当OutputDebugString没有要打印到的调试器时，程序处理该事件。

异常结构填充

ExceptionAddress: 0xXXXXXXXX
ExceptionCode: 40010006/4001000A//错误代码
ExceptionFlags: 00000001
NumberParameters: 2//附加参数个数，一般为2个
Parameter[0]: //信息字符串长度
Parameter[1]://字符串指针

我最近花了一些时间分析OutputDebugString方法。在我的另一个实验中，我需要一个仅依赖于本机API的OutputDebugString版本。在实现它的过程中，我发现了一些关于OutputDebugString的有趣的事实，也许您也会感兴趣。

OutputDebugString的工作原理

简而言之，OutputDebugString尝试将消息发送到附加到给定进程的调试器，如果没有调试器侦听，则尝试将全局节映射到进程内存中并将调试消息保存在其中。我使用本机API实现OutputDebugStringA（ANSI版本）的示例如下：

voidNTAPI RtlOutputDebugStringA(_In_opt_ LPCSTR OutputString) {if(OutputString) {

        EXCEPTION_RECORD exceptionRecord{0};

 

        exceptionRecord.ExceptionCode=DBG_PRINTEXCEPTION_C;

        exceptionRecord.NumberParameters= 2;

        exceptionRecord.ExceptionInformation[0] = strlen(OutputString) + 1;

        exceptionRecord.ExceptionInformation[1] = reinterpret_cast<ULONG_PTR>(OutputString);

 

        __try {

            RtlRaiseException(&exceptionRecord);

        } __except (EXCEPTION_EXECUTE_HANDLER) {

            NotifyGlobalDebugOutputMonitor(OutputString);

        }

    }

}

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

下载给定PE文件的PDB文件

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

symchk.exe

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

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

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的任何一个窗口中完成这项工作。