在崩溃转储中查找所有可能的上下文记录

如果您调试了一段时间的崩溃转储，那么您可能遇到了这样的情况：调试器提供的初始转储上下文对应于在处理初始异常时发生的第二个异常，该异常可能更接近您正在调查的问题中的原始基础问题。
这可能很烦人，因为“.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 }

标签: none