wenmo8 发布的文章

如果您调试了一段时间的崩溃转储，那么您可能遇到了这样的情况：调试器提供的初始转储上下文对应于在处理初始异常时发生的第二个异常，该异常可能更接近您正在调查的问题中的原始基础问题。
这可能很烦人，因为“.ecxr”命令将指向次要故障异常的位置，而不是原始异常上下文本身。然而，在大多数情况下，原始的、主要的异常上下文仍然在堆栈上；人们只需要知道如何找到它。

有两种方法可以解决这个问题：

  • 对于硬件生成的异常（如访问冲突），可以查找堆栈上的ntdll!KiUserExceptionDispatcher，它以PCONTEXT和PEXCEPTION_RECORD作为参数。
  • 对于软件生成的异常（如C++异常），情况会变得更糟。你可以找在堆栈上调用ntdll!RtlDispatchException，然后从那里获取PCONTEXT参数

如果堆栈展开失败，或者您正在处理其中一个转储，其中多个线程同时出现异常，这可能会有点乏味，这通常是由于崩溃转储写入失控。如果调试器能稍微自动化一下这个过程就好了。幸运的是，用一点蛮力的方法来做到这一点其实并不难。具体地说，只是一个普通的老“哑”内存扫描，以查找大多数上下文记录所共有的内容。这并不完全是一种巧妙的方法，但通常比手动在堆栈中查找要快得多，尤其是在涉及多个线程或多个嵌套异常的情况下。虽然可能会有误报，但通常很明显的一点是，涉及到一个活动异常有什么意义。然而，有时，快速而肮脏的暴力类型解决方案最终真的做到了这一点。
但是，为了基于内存搜索查找上下文记录，我们需要一些公共数据点，这些数据点通常对于所有上下文结构都是相同的，并且最好是连续的（为了便于使用“s”命令，调试器的内存搜索支持）。幸运的是，它以上下文结构的段寄存器的形式存在：

0:000> dt ntdll!_CONTEXT
+0x000 ContextFlags : Uint4B
[…]

+0x08c SegGs : Uint4B
+0x090 SegFs : Uint4B
+0x094 SegEs : Uint4B
+0x098 SegDs : Uint4B

[…]

现在，事实证明，对于给定进程中的所有线程，几乎总是具有相同的段选择器值，不包括异常的和非常不寻常的情况，如VDM进程。（x64上的段选择器值也是如此。）四个非零的32位值（实际上，零填充到32位的16位值）足以在不被误报的情况下合理地完成搜索。下面介绍如何使用臭名昭著的WinDbg调试器脚本（也适用于其他启用DbgEng的程序，如kd）：

.foreach ( CxrPtr { s -[w1]d 0 l?ffffffff @gs @fs @es @ds } ) { .cxr CxrPtr – 8c }

这是一个有点冗长的命令，所以让我们把它分解成各个组件。首先，我们有一个“.foreach”构造，根据调试器文档，它遵循以下约定：

.foreach [Options] ( Variable { InCommands } ) { OutCommands }

.foreach命令（实际上是多个版本调试器脚本命令之一，一旦人们习惯使用它）基本上接受由输入命令（in commands）生成的一系列输入字符串，并调用一个命令来处理该输出（OutCommands），输入命令的结果作为变量参数。它很难看，并且基于文本解析进行操作（除其他外，还支持跳过每个X输入；请参阅调试器文档），但它完成了任务。

当你调试一个程序时，你最不想处理的是调试器不能正常工作。当你试图集中精力跟踪一个bug时，总是会因为次要的问题而被忽略，尤其是当调试器的问题导致你失去一个重新编程或者浪费了大量的时间等待调试器完成它，而调试器知道这需要永远做些什么的时候。

我发现自己在工作中和工作之外不时支持的一件事是使用程序的发布版本（无论如何，对于Windows应用程序）进行调试的价值。乍一看，这可能与某些人的想法相矛盾，因为人们往往认为调试构建实际上更适合调试（毕竟它被命名为“调试构建”）。

通常，您可能希望在调试器中跟踪的一类问题（除了崩溃）是某个特定函数以某种方式失败。在大多数Win32函数的情况下，通常会得到某种（希望是有意义的）最后的错误代码。有时，您可能需要知道返回错误的原因或错误的来源（在最后一个错误值通过几个函数向上传播的情况下）。
一种可能的方法是使用条件断点，但是SetLastError路径通常会被命中，因此这在性能方面经常是有问题的，即使在本地计算机上的用户模式调试中也是如此。
在Windows Vista上，NTDLL内部有一个未记录的钩子（它现在负责set last error背后的大部分逻辑），允许您配置一个程序，以便在将特定错误代码设置为最后一个错误时进入调试器。这是Vista的新功能，由于没有文档记录（至少在我能看到的任何地方都没有），它可能不会无限期地存在。

不过，现在可以设置ntdll!g_dwLastErrorToBreakOn设置为非零值（通过调试器中的ed命令），以便在NTDLL看到设置了最后一个错误值时要求它执行断点。显然，这不会直接捕获修改TEB中字段的内容，但是使用setlastererror或RtlSetLastWin32Error的任何内容都将根据该值进行检查（在debuggee的上下文中）。
例如，如果要求NTDLL在错误5（错误访问被拒绝）时中断，然后尝试打开您无权访问的文件或目录，您可能会看到类似的情况：

0:002> ed ntdll!g_dwLastErrorToBreakOn 5
0:002>g



[...] Perform an operation to cause ERROR_ACCESS_DENIED



(1864.2774): Break instruction exception- code 80000003(first chance)

ntdll!DbgBreakPoint:00000000`76d6fdf0 cc              int     3
0:004>k

Call Site

ntdll!DbgBreakPoint

ntdll! ?? ::FNODOBFM::`string'+0x377b
kernel32!BaseSetLastNTError+0x16kernel32!CreateFileW+0x325SHELL32!CEnumFiles::InitAndFindFirst+0x7aSHELL32!CEnumFiles::InitAndFindFirstRetry+0x3eSHELL32!CFileSysEnum::_InitFindDataEnum+0x5eSHELL32!CFileSysEnum::Init+0x135SHELL32!CFSFolder::EnumObjects+0xd3SHELL32!_GetEnumerator+0x189SHELL32!CEnumThread::_RunEnum+0x6dSHELL32!CEnumThread::s_EnumThreadProc+0x13SHLWAPI!WrapperThreadProc+0xfckernel32!BaseThreadInitThunk+0xdntdll!RtlUserThreadStart+0x1d

WinDbg的alias命令（as, aS)在script里面很有用，但是WinDbg的script不算是一种设计良好的语言，一般在写WinDbg script总会遇到各种坑，就包括alias命令的求值。

与变量相比，WinDbg的alias更像是C语言的宏。他可以把一个名字定义成指定的字符串，环境变量，给定地址的字符串，甚至表达式的值或者WinDbg命令的输出字符串。C语言的宏仅在定义点到文件结束有效（如果后面没有undef），WinDbg的alias的求值则 下面解释下这个过程。

假设已经有alias (aS foo bar), 在运行命令 .echo foo 或者 .echo ${foo} (使用后者的可以对alias name提供显示的tokenize和参数，比如${/v:foo}，参考WinDbg帮助）。在运行 .echo foo 命令前，WinDbg会对整个命令字符串执行alias替换，替换完成在执行整个命令，运行栈如下：


dbgeng!ReplaceAliases

dbgeng!PreprocessExternalStrBuf

dbgeng!PreprocessExternalString

dbgeng!Execute

dbgeng!DebugClient::ExecuteWide

...
  1. 1
  2. ...
  3. 1386
  4. 1387
  5. 1388
  6. 1389
  7. 1390
  8. 1391
  9. 1392
  10. ...
  11. 1490