尝试使用 WinDbg 分析转储文件：PEB 已分页，不会加载符号

Question

您好，我正在尝试使用 WinDbg 查看 memory.dmp 内核转储文件，目的是诊断崩溃。当我打开崩溃文件并获取符号时，我会收到消息

BugCheck A, {2, ff, 4e, fffff801a42ebff2}

CompressedPageDataReader warning: failed to get _SM_PAGE_KEY symbol.
CompressedPageDataReader warning: failed to get _SM_PAGE_KEY symbol.
Probably caused by : ntkrnlmp.exe ( nt!KxWaitForLockOwnerShipWithIrql+12 )

Followup:     MachineOwner
---------

0: kd> .reload
Loading Kernel Symbols
..................................CompressedPageDataReader warning: failed      to get _SM_PAGE_KEY symbol.

Loading User Symbols
PEB is paged out (Peb.Ldr = 000000e1`114f4018).  Type ".hh dbgerr001" for details

我认为这意味着它无法加载某些符号。当我尝试 !vad 进程来修复 PEB 页面错误时，我得到了

0: kd> !vad 000000e1114f4018 1

VAD @ ffffca0f084164e0
Start VPN              e111400  End VPN          e1115ff  Control Area  0000000000000000
FirstProtoPte 0000000000000000  LastPte f943916c00000002  Commit Charge               21 (0n33)
Secured.Flink                0  Blink                  0  Banked/Extend                0
File Offset              50005  
  ViewUnmap NoChange PrivateMemory READWRITE  

这与互联网告诉我的结果不符。

当我尝试 !process 方法时，我得到了

0: kd> !process 000000e1114f4018 1
Searching for Process with Cid == e1114f4018
Invalid Handle: 0x114f4018
***Could not retrieve process handle from the Cid table.  Searching...

这也是一个不加载符号的错误。怎么了？如果有足够的信息，则在符号加载或崩溃本身中。

注意：我已经尝试了 MSDN 页面中的解决方案，但它们没有按说明工作。部分问题是我不知道我是否在命令中正确使用了 PEB 分页错误消息中给出的 000000e1`114f4018 地址。

注意 2：这里是 WinDBG 的崩溃报告的链接。如果有人能找出原因并解释他们是如何发现的，那就太棒了。

https://www.scribd.com/document/326672131/Crash-Archive

Answer 1

被调出的PEB是正常的。为了使 PEB 存在，转储必须是完整的内存转储，并且相应的页面必须在崩溃时驻留。

这几乎无关紧要，因为 PEB 包含用户模式状态（用户加载的模块、命令行、环境变量等），这通常不会引起内核模式崩溃。

有趣的是 !analyze -v 输出，包括故障线程的内核模式堆栈。根据您提供的信息，我们至少可以看到崩溃代码：

BugCheck A, {2, ff, 4e, fffff801a42ebff2}

Bugcheck A 是一个 IRQL_NOT_LESS_OR_EQUAL，这意味着您在提升的 IRQL (>= DISPATCH_LEVEL) 处有一个无效的指针取消引用。第一个参数是错误地址（“2”），第二个参数是 IRQL（“0xFF” - 这是 WinDbg 的“处理器上禁用中断”）。

总而言之，这意味着有人取消了地址“2”的引用，这显然不是一件好事。它碰巧发生在处理器上禁用中断的情况下，所以你得到一个 IRQL_NOT_LESS_OR_EQUAL。诀窍是查看调用堆栈和错误指令并找出“2”的来源。