WinDBG 执行 .excr 时为何报错 HRESULT 0x8000FFFF？

2026-11-04排障赵师傅

结论

你在 WinDbg 中直接运行 EXE，做的是实时用户态调试。先让程序停在除零异常处，再用 r 查看寄存器，用 kv 查看调用栈。

.excr 与 .ecxr 是同义命令，功能完全相同。微软文档列出的适用目标是用户态崩溃转储（minidump）。遇到这个报错，首先要确认当前是在实时调试，还是在分析转储。把 .excr 换成 .ecxr 不会改变命令的适用条件。微软文档：.excr

0x8000FFFF 对应 E_UNEXPECTED，是通用的失败 HRESULT。仅凭这个错误码，无法判断是否缺少 PDB、SDK 是否损坏，或 Windows 11 是否存在兼容性问题。微软文档：COM 错误代码

为什么 `!analyze -v` 成功，`.excr` 却失败？

这两个命令用到的数据需要分清：

EXCEPTION_RECORD 描述异常，包括异常代码、发生地址和异常参数。
CONTEXT 保存线程的机器状态，包括寄存器等信息。

.exr -1 显示最近的异常记录。.excr 则查找与当前异常关联的上下文记录，显示其中的重要寄存器，并将该记录设为后续寄存器和栈分析使用的上下文。因此，“将上下文设置为异常记录”这个说法不够准确：异常记录和上下文记录是不同的结构。微软文档：异常分派

实时调试时，调试器可以直接读取已暂停线程的寄存器。即使 !analyze -v 能输出异常、寄存器和源码信息，当前目标也未必具备 .excr 所需的转储异常上下文。

执行 .dump /ma 只会生成转储文件，当前会话仍在调试运行中的进程。打开生成的 .dmp 文件后，才会进入该转储的分析会话。微软文档：.dump

实时调试：在除零处停下，直接查看寄存器

重新启动程序进行调试，在执行到除法之前输入以下命令，让调试器遇到整数除零异常时立即中断：

sxe 0xc0000094
g

0xC0000094 是整数除零异常代码。这里的 sxe 会让调试器在 first-chance 通知时中断，无须等到异常成为未处理异常。微软文档：设置异常处理行为

切换到程序的控制台，按 Enter，让程序执行：

int z = y / x;

WinDbg 因除零而停下后，执行：

.lastevent
.exr -1
~#s
r
kv

各命令的作用如下：

.lastevent：确认最近发生的调试事件。
.exr -1：查看最近的异常记录，确认异常代码是 0xC0000094。
~#s：切换到触发当前异常或调试事件的线程。
r：显示当前线程上下文中的寄存器。
kv：查看带附加信息的调用栈。

其中，~# 表示引发当前异常或调试事件的线程，r 可以直接用于实时调试。微软文档：线程语法、寄存器命令 r

检查完成前，先不要执行 g 继续运行。如果 .lastevent 显示 0x80000003，应确认程序是否停在启动断点或手动中断处。手动 Break 也会产生断点异常，此时显示的寄存器未必属于除零现场。微软文档：.lastevent

转储分析：保存异常现场，再打开 dump

要练习教程中的 .excr，可以在上述除零中断处保存转储：

.dump /ma "C:\Dumps\divide-by-zero.dmp"

先创建 C:\Dumps 目录，保存时指定完整文件名。然后在另一个 WinDbg 会话中打开这个 .dmp 文件，执行：

.exr -1
.ecxr
r
kv
!analyze -v

这里的 .ecxr 可以换成 .excr。如果转储包含可用的异常上下文，该命令就会切换到异常发生时的寄存器上下文。微软文档：.excr

如果打开 dump 后命令仍然失败，按以下顺序排查：

确认打开的是刚生成的转储，而且保存时程序确实停在除零异常处。
检查 .exr -1 能否读出预期的异常。/ma 会增加转储内容，但无法把任意时刻的进程快照变成此前除零现场的记录。
如果 !analyze -v 给出了有效的 CONTEXT 地址，并明确提示使用 .cxr，就按提示执行 .cxr <地址>，再运行 r 和 kv。不要把 ExceptionAddress 当作 CONTEXT 地址。
确认目标和异常数据都正确后，记录 version、.lastevent、.exr -1 及完整报错，继续检查调试器或转储读取问题。

.cxr 可以从指定地址读取 CONTEXT 并设置寄存器上下文，前提是该地址指向有效且可读取的结构。微软文档：.cxr

PDB 和符号服务器需要怎样配置？

PDB 主要帮助 WinDbg 将机器地址对应到函数、变量和源码行。读取线程寄存器不依赖你自己的 PDB。既然已经能定位到除法所在的源码行，就不必仅凭 .excr 的报错重新检查整个构建环境。

微软公共符号服务器提供微软组件的符号。自己编译的程序仍需使用同一次构建产生的 PDB，例如：

.symfix C:\symbols
.sympath+ C:\Work\Demo\x64\Debug
.reload /f

将第二行中的目录替换为程序 PDB 的实际存放目录。.symfix 不带 + 时会替换现有符号路径，因此要在执行后追加自己的目录。微软当前文档中的公共符号服务器地址使用 HTTPS。微软文档：符号路径、.symfix

源代码和 `FindPlugins` 提示是否有关？

这段代码中的整数除零在 C++ 中属于未定义行为，不同编译器和优化选项下的调试结果未必完全相同。当前构建既然已经触发除零并定位到对应行，就可以继续用它练习。学习时保留 Debug 配置，并确认关闭优化，会更便于对照源码。微软文档：乘除和取余运算符

对于这条提示：

ERROR: FindPlugins 8007007b

仅凭这一行，无法判断它是否只是“缺少某个插件的无害警告”，也无法确定它是否导致了 .excr 失败。先核对当前是在实时调试还是分析转储，并按对应步骤检查。如果 r 能读取除零现场的寄存器，打开正确的 dump 后 .ecxr 也能工作，就没有必要把这条提示当作当前问题的根因。若分析功能仍有异常，再保留完整日志单独调查。