Windows蓝屏死机和内核转储分析完整指南

信息技术数字 » 资源 » Windows蓝屏死机和内核转储分析完整指南

当Windows电脑出现蓝屏死机时，这不仅仅令人恼火：内存转储文件中通常隐藏着一些有价值的信息，可以告诉我们内核究竟发生了什么。与其责怪内存、BIOS或立即重装系统，不如学习如何读取这些数据。

稍加练习，像 WinDbg 这样的工具以及!analyze -v、.bugcheck 等函数，再加上正确使用符号，就能让我们从“遇到蓝屏错误”到“知道是哪个驱动程序、资源或设备导致了蓝屏死机”。本文将一步一步、详细地讲解如何使用内核转储文件分析蓝屏死机，包括有哪些类型的转储文件、如何准备所有文件，以及如何使用命令来最大程度地利用分析结果。

什么是蓝屏死机（BSOD）？它包含哪些信息？

当 Windows 遇到危及系统完整性且无法安全恢复的情况时，它会调用一个名为KeBugCheckEx 的内部内核函数。正是这个调用触发了臭名昭著的蓝屏死机 (BSOD)。

KeBugCheckEx 始终接收五个参数：一个停止代码（错误检查代码）和四个提供错误技术上下文的附加参数。我们可以参考这些数据。

• 在蓝屏上 如果系统未配置为自动重启，则会出现经典情况。
• 在 Windows 事件日志中在事件查看器（系统日志）中。
• 在内存转储文件中 使用 WinDbg 和类似命令（小型转储、内核转储或完整转储） !analyze -v o .bugcheck.

每个错误检查代码都有一个符号名称和一个关联的十六进制值。例如，错误检查DRIVER_POWER_STATE_FAILURE 的代码为0x9F，而RESOURCE_NOT_OWNED对应的代码为0xE3。这些代码及其参数都记录在 Microsoft 错误检查代码参考文档中，建议您始终将其放在手边。

除了错误代码外，蓝屏可能还会显示一个疑似相关的 .sys 驱动程序名称。如果是第三方驱动程序（例如杀毒软件、网卡、显卡等），我们通常就能明确找到问题所在。如果显示的是通用系统组件（例如 ntoskrnl.exe、win32k.sys 等），或者根本没有显示任何内容，则需要执行内存转储并使用 WinDbg 进行进一步调查。

Windows 中的内存转储类型

要深入分析蓝屏死机 (BSOD)，我们需要 Windows 在故障发生时生成内存转储文件 (DMP)。该文件记录了错误发生时的系统状态，并且可以是不同类型的文件。

在“启动和故障恢复”选项中（右键单击“此电脑/我的电脑”→属性→高级系统设置→“高级”选项卡→“启动和故障恢复”下的“设置”按钮），您可以选择几种类型的转储文件。每种文件都有其优点和缺点。

小型内存转储（Minimp）

minidump格式的文件最小（约 64 KB），但对于高级调试而言也最为有限。不过，它在许多蓝屏死机 (BSOD) 场景下仍然有助于快速诊断问题。

小型转储文件存储的数据包括：

• 停止消息、错误检查代码及其参数.
• 处理器上下文 导致故障的处理器的 (PRCB)。
• 内核进程信息 （EPROSS）崩溃时活动进程的
• 内核中的线程信息 导致崩溃的线程的 (ETHREAD)。
• 内核模式调用栈 该线程（最多 16 KB）。
• 已加载驱动程序列表 在判决作出之时。
• 已加载和已下载的模块列表.
• 调试数据块 包含基本系统信息。

这种类型的转储文件通常保存在%SystemRoot%\Minidump 目录中（例如，C:\Windows\Minidump）。对于许多基本支持或诊断情况，使用!analyze -v命令对小型转储文件进行彻底分析可能就足够了。

内核内存转储

内核内存转储包含崩溃时内核内存的内容，但不包括用户进程内存空间。它在文件大小和详细信息之间取得了很好的平衡，通常是诊断大多数蓝屏死机 (BSOD) 的推荐选项。

此转储文件以MEMORY.DMP的名称保存在%SystemRoot% 目录下（默认情况下为C:\Windows\MEMORY.DMP）。其大小取决于内核使用的内存，但通常比小型转储文件大得多，也比完整转储文件更容易管理。

完整的内存转储

完整的内存转储会保存错误发生时 RAM 中的几乎所有内容：内核、用户进程等。它是最详细的，但也是占用空间最大、配置要求最高的。

要使完整的转储文件有效，必须满足以下几个条件：

• El 分页文件 必须在 Windows 安装在同一个分区。.
• 必须有 磁盘空间至少等于物理内存的大小 机器的
• 如果想要避免转储文件损坏，请不要将页面文件移动到另一个物理磁盘。

在内存很大的生产环境中，完整转储可能不太实际，但对于非常复杂或间歇性的问题，它可以对定位问题起到至关重要的作用。

配置 Windows 以捕获和记录蓝屏死机 (BSOD)

在使用 WinDbg 之前，必须确保系统能够正确生成转储文件并记录蓝屏事件。

在“启动和恢复”窗口中，我们可以找到几个相关选项：

• 将事件写入系统日志必须启用此功能才能将错误检查记录到事件查看器中。
• 写入调试信息在这里，我们可以选择小型内存转储、内核内存转储或完整内存转储。
• 转储文件路径： 默认 %SystemRoot%\MEMORY.DMP 内核/完整版。
• 自动重启如果想要的话，建议取消勾选。 冷静地观看蓝屏 并记下出现的内容。

对于某些制造商或支持部门，例如某些网络适配器，会要求用户提交转储文件。该文件通常位于C:\Windows\memory.dmp，建议按日期/时间查找，以确定与上次故障对应的文件。

如果我们想要即使在系统冻结（键盘或鼠标无响应）的情况下也能强制生成转储文件，那么对于 PS/2 键盘（而非 USB/蓝牙键盘）来说，还有一个非常有用的技巧，那就是配置注册表，通过组合键触发转储文件。

如果电脑死机，请使用键盘强制导出文件。

即使屏幕完全冻结，您也可以使用PS/2 键盘上的CrashOnCtrlScroll选项来生成内存转储。此方法不适用于 USB 或蓝牙键盘。

在注册表中，我们必须创建或修改以下键：

HKEY_LOCAL_MACHINE
  System
    CurrentControlSet
      Services
        i8042prt
          Parameters

Nombre: CrashOnCtrlScroll
Tipo:   REG_DWORD
Valor:  1

重启后，您可以随时（即使屏幕冻结）触发受控崩溃，方法是先按右Ctrl键，再按两次 Scroll Lock 键，让系统生成内存转储文件。这对于调查那些不会自动显示蓝屏死机 (BSOD) 的严重崩溃问题非常有用。

WinDbg内核转储分析简介

WinDbg 是微软用于内核调试和内存转储分析的顶级工具。它是免费的（目前也可以在 Microsoft Store 中以 WinDbg Preview 的形式下载），虽然乍一看可能令人生畏，但对于初步的蓝屏死机 (BSOD) 分析，您只需要了解几个基本选项即可。

我们可以将 WinDbg 安装在故障机器本身或其他任何计算机上；.dmp 文件可以通过网络、USB 甚至压缩成 CAB 文件进行复制。我们分析转储文件的处理器和 Windows 版本不一定需要与崩溃机器的处理器和 Windows 版本相同。

从命令行启动 WinDbg 并生成转储文件

在 WinDbg 中打开内存转储文件的经典方法是使用带有`-z`参数的命令行，指定转储文件的路径。这可以与其他参数结合使用，例如符号或二进制文件的路径。

windbg -y <RutaSimbolos> -i <RutaBinarios> -z <RutaDump>

-v参数会启用详细模式，这对于查看更多上下文信息非常有用。除了 WinDbg 之外，还有kd.exe，这是一个基于控制台的调试器，它几乎可以实现相同的功能，但没有图形界面。

kd.exe -z "Ruta\al\volcado.dmp" -y "Ruta\simbolos" -i "Ruta\busqueda\binarios"

从图形界面打开转储文件

如果 WinDbg 已在被动模式下打开，您可以使用“文件”→“打开崩溃转储”菜单或快捷键Ctrl+D加载崩溃转储文件。选择 .dmp 文件（甚至是包含该文件的 .cab 文件），WinDbg 将加载崩溃信息。

另一种方法是启动 WinDbg，进入后运行.opendump命令，指定转储文件的路径，然后运行​​g（执行）命令来启动转储调试会话：

.opendump C:\Windows\Memory.dmp
g

WinDbg 甚至允许 一次性清理多个垃圾场添加多个参数 -z 在命令行中或通过重复操作 .opendump 使用不同的路线并管理多目的地会话。

在 WinDbg 中配置符号路径

如果没有符号文件，WinDbg 几乎无法正常工作。符号文件（.pdb）包含有关函数、内部结构、变量、偏移量等的调试信息，对于可靠的分析至关重要，尤其是在处理内核时。

要使用 Microsoft 的公共符号而无需手动下载，最佳实践是配置一个指向 Microsoft 官方服务器和本地缓存目录的符号服务器。例如，我们可以先创建一个名为C:\symbols 的文件夹，然后在 WinDbg 中按如下方式配置符号路径：

SRV*c:\symbols*https://msdl.microsoft.com/download/symbols

这可以通过“文件”→“符号文件路径”菜单完成，或者在 WinDbg Preview 中，通过“文件”→“设置”→“调试设置”调整“默认符号路径”。首次分析特定系统的转储文件时，调试器会自动从互联网下载必要的符号，这可能需要几分钟时间，具体取决于您的网络连接。

需要注意的是，微软的公共符号有时并不包含所有内部类型信息，因此您可能会看到类似“调试器未使用正确的符号”或引用无法解析类型的警告。对于基本的蓝屏死机 (BSOD) 分析，公共符号通常足够使用，但如果您需要更详细的信息，则会受到限制。

初步分析：基本命令和错误检查

加载转储文件并配置符号后，WinDbg 通常会显示一个包含系统信息的标题栏以及类似“使用 !analyze -v 获取详细调试信息”的警告。这是我们进行初步分析的第一步。

!analyze -v命令会对转储文件进行自动分析，通常会提供以下信息：

• 错误检查代码 （例如，0xE3、0xD1、0x9F、0x44……）。
• 参数 Arg1、Arg2、Arg3 和 Arg4 来自错误检查。
• 最有可能的模块或驱动程序 故障原因（Probably caused by).
• 相关过程 那一刻（例如，Teams.exe）。
• 调用堆栈（堆栈跟踪） 引发崩溃的线程。
• 存储桶信息 以及失败哈希值，可用于关联重复错误。

例如，在实际的错误检查案例中，如果出现 RESOURCE_NOT_OWNED (0xE3) 错误，分析结果可能表明某个线程试图释放它不拥有的资源，该线程的进程显示为Teams.exe ，并且指向win32kbase.sys文件，例如在DrvEnumDisplaySettings之类的函数中。这表明出错的线程正在通过 Windows 图形层从用户空间查询或操作显示设置。

为了更深入地了解停止代码及其参数的细节，我们还有以下命令。 .bugcheck它会再次显示错误检查和四个参数，如果我们想重复该信息而不重新运行所有内容，这将非常有用。 !analyze -v.

实际案例：驱动因素和典型冲突

蓝屏死机 (BSOD) 分析通常围绕识别故障或异常的驱动程序、驱动程序冲突、不正确的内存访问、错误处理 I/O 请求包 (IRP) 等问题展开。让我们来看一些实际案例，以便更好地理解这个过程。

与 Teams 和 win32kbase.sys 相关的 RESOURCE_NOT_OWNED (0xE3)

在 Windows 10 系统中，如果运行数天后出现蓝屏死机 (BSOD)，错误代码为0xE3 (RESOURCE_NOT_OWNED)，则微型内核转储文件会显示类似以下内容：

RESOURCE_NOT_OWNED (e3)
A thread tried to release a resource it did not own.
Arguments:
Arg1: <dirección recurso>
Arg2: <dirección thread>
Arg3: 0
Arg4: 0

PROCESS_NAME: Teams.exe

STACK_TEXT:
...
win32kbase!DrvEnumDisplaySettings+0x356
win32kbase!NtUserEnumDisplaySettings+0x59
win32k!NtUserEnumDisplaySettings+0x15
nt!KiSystemServiceCopyEnd+0x28
...

这里，调试器显示错误检查是由与Teams.exe关联的线程触发的，但关键时刻堆栈上的实际代码属于win32kbase.sys，具体来说是DrvEnumDisplaySettings函数。这并不一定意味着 Teams 是直接的罪魁祸首，而是Teams 调用了一个用户 API，导致图形子系统中出现同步或资源释放错误。

这类诊断的结论通常是：问题出在 Windows 图形堆栈、特定的显卡驱动程序，或是应用程序与驱动程序之间的交互上。实际的解决方案可能包括更新 GPU 驱动程序、更新 Teams，甚至应用特定的 Windows 补丁，而不是仅仅等待问题自行修复。

DRIVER_IRQL_NOT_LESS_OR_EQUAL (0xD1) with NotMyFault

Sysinternals 的NotMyFault工具是一个教育工具，它允许您以可控的方式生成内核错误，从而学习如何分析屏幕截图。例如，如果您从 NotMyFault 启动“高 IRQL 故障（内核模式）”选项并单击“执行错误”，则会强制出现DRIVER_IRQL_NOT_LESS_OR_EQUAL (0xD1) 错误。

在蓝屏上，我们会看到类似DRIVER_IRQL_NOT_LESS_OR_EQUAL 的信息，以及可能存在的候选驱动程序（例如，MyFault.sys，即该工具使用的驱动程序）。生成转储文件并使用 WinDbg 打开后，初始输出可能如下所示：

Use !analyze -v to get detailed debugging information.
BugCheck D1, {e1071800, 1c, 0, f7cda403}
*** ERROR: Module load completed but symbols could not be loaded for myfault.sys
Probably caused by : memory_corruption
Followup: memory_corruption

虽然调试器指向内存损坏，但我们知道真正的原因与 NotMyFault 及其驱动程序有关。为了确认这一点，我们可以继续使用类似`!thread` 的命令进行跟踪，以查看线程在故障发生时发出的调用，并使用 ` !irp` 命令分析涉及的 IRP（如果错误检查与 I/O 操作相关）。

例如，使用`!thread <dir_thread>` 命令，我们可以查看线程的堆栈跟踪，并找到出现`myfault+0x403` 的指令，从而确定测试驱动程序出错的位置。从那里，我们可以检查 IRP、内存状态等等，就像处理真实 bug 一样。

多个 IRP 完成请求 (0x44) 和 USB 冲突

另一个非常典型的例子是错误检查。 多个 IRP 完成请求 (0x44)当出现此错误时， IRP（I/O 请求包）会被多次完成通常是因为两个不同的司机都认为自己拥有同一个IRP，并且都打电话询问。 IoCompleteRequest().

使用!analyze -v进行分析可能会产生类似如下的描述：

MULTIPLE_IRP_COMPLETE_REQUESTS (44)
A driver has requested that an IRP be completed (IoCompleteRequest()), but
the packet has already been completed.
...
Arguments:
Arg1: <IRP_ADDRESS>
Arg2: 00000d75
Arg3: 00000000
Arg4: 00000000

Probably caused by : usbehci.sys

最初，嫌疑对象似乎是usbehci.sys，一个用于 USB EHCI 控制器的 Microsoft 驱动程序。然而，由 Windows 原生驱动程序引起且不涉及任何第三方交互的 bug 相对罕见。为了找到问题所在，我们使用 bugcheck 提供的 IRP 地址（Arg1）并运行!irp <IRP_ADDRESS>：

!irp 87e5a490
Irp is active with 3 stacks 3 is current (= 0x87e5a548)
...
> [ f, 0] 0 c0 8a055618 00000000 b69de300-00000000 Success Error
  \Driver\usbehci ax88172
Args: b70989c0 00000000 00220003 00000000

在最后一行，我们可以清楚地看到字符串“\Driver\usbehci ax88172”，这表明 IRP 已经遍历了usbehci.sys和一个名为ax88172.sys的驱动程序，后者与特定的 USB 网络芯片组 (AX88172) 相关联。因此，我们可以得出结论，冲突源于这个第三方 USB 网卡驱动程序，而不是微软的通用 EHCI 驱动程序。

在这种情况下，解决方案包括更新 USB 适配器驱动程序、更换设备，或者必要时将其移除。这种 IRP 分析对于与 USB、存储设备、网卡以及任何使用密集型 I/O 的组件相关的蓝屏死机 (BSOD) 问题尤其有用。

内核模式下有用的 WinDbg 命令

除了!analyze -v和.bugcheck之外，还有几个 WinDbg 扩展和命令在我们需要更深入地了解内核转储时非常有用。

一些最常见的例子包括：

• ！线：显示有关线程的详细信息，包括其调用堆栈、状态、关联的 IRP 等。它允许您查看系统崩溃时正在运行的线程的“最后操作”。
• !进程 0 0此列表显示崩溃发生时所有正在运行的进程。它有助于识别计算机上是否运行着任何可疑的进程、服务、EDR、杀毒软件等。
• !irp分析特定的 IRP 并显示 它所经过的司机的痕迹I/O 命令、标志等是与以下方面相关的错误的关键： MULTIPLE_IRP_COMPLETE_REQUESTS 以及其他 I/O 错误。
• !cpuinfo：提供有关处理器的信息（制造商、MHz、签名、特性），用于验证硬件环境。
• !peb：显示 PEB（进程环境块）的详细信息，例如计算机名称、Windows 安装路径、处理器数量等。
• !token：提供有关进程或线程的安全令牌、权限和安全上下文的信息。
• .cls：清除命令窗口，就像在普通控制台中一样。

此外，许多特定的文件系统扩展名（例如 PnP、NTFS 等）允许您从转储文件中提取更多信息。在某些情况下，WinDbg 会指示是否存在BLACKBOX*（BLACKBOXBSD、BLACKBOXNTFS、BLACKBOXPNP、BLACKBOXWINLOGON），这些是在错误检查期间捕获的额外数据块，用于帮助诊断特定系统区域的问题。

使用驱动程序验证程序查找问题驱动程序

绝大多数 Windows 蓝屏死机 (BSOD) 错误都是由故障或程序编写不佳的驱动程序引起的。为了主动检测这类问题，系统内置了一个强大的工具：驱动程序验证程序。

驱动程序验证程序实时运行，并对选定的驱动程序进行一系列测试和压力测试：它会检查正确的内存使用情况、内核池使用情况、IRQL、IRP 等。如果检测到驱动程序运行异常，它可以强制执行受控蓝屏死机，以便我们分析更清晰的转储文件，通常很容易从中识别出问题所在。

要启动驱动程序验证程序管理器，只需以管理员权限打开命令提示符并键入：

verifier

接下来，我们可以选择要验证的驱动程序。谨慎行事是明智的：验证程序会增加系统开销并可能降低性能，因此建议仅对少数可疑驱动程序启用验证，而不是不加选择地选择所有驱动程序。

一旦驱动程序验证程序检测到异常行为并触发蓝屏死机 (BSOD)，我们可以使用 WinDbg 分析内核转储文件，并有望清楚地看到哪个驱动程序被捕获以及它犯了什么错误。微软关于驱动程序验证程序的参考文章详细解释了各种选项和使用策略。

为工程师和技术人员提供的实用建议

无论你是驱动程序开发人员、与内核交互的软件开发人员，还是负责处理所有蓝屏死机问题的技术人员，都有一些值得牢记的准则，以避免迷失在蓝屏死机的丛林中。

如果错误与你自己的代码有关，第一步是系统地使用内核调试器来重现和分析问题。通过将调试器连接到目标机器（通过网络、串口等），错误检查会导致系统在调试器内部停止运行，而不是直接显示蓝屏。这样，你就可以检查内存、堆栈、结构体，并修正代码。

在其他情况下，错误检查可能是由于我们无法控制的第三方驱动程序、硬件或软件造成的。在这种情况下，目标从“修复代码”转变为隔离和缓解问题。

• 使用 WinDbg 和转储分析来识别可疑的驱动程序或硬件组件。
• 更新或恢复 驱动程序版本、BIOS、固件或相关应用程序。
• 移除或替换 USB设备、显卡、网络适配器 冲突性的。
• 依靠 事件查看器、Sysinternals、网络监控和分析工具 更多背景信息。

许多看似神秘的问题都可以通过基本的故障排除步骤解决：查阅文档、检查文件版本和日期、重新安装关键组件或禁用冲突模块。分析转储文件可以让我们明确查找问题的方向，并常常节省我们数小时的反复试验时间。

同样重要的是要记住，在类似导致CrowdStrike Falcon事件和其他 EDR 系统故障的环境中，最常见的问题都围绕着蓝屏死机 (BSOD) 的触发原因以及如何快速识别它。正确配置 WinDbg，使其包含符号并具备清晰的转储文件打开和分析流程，可以让你在几分钟内缩小故障范围，否则可能最终只能“格式化并重新安装系统”，而无法真正了解故障原因。

简而言之，结合良好的内存转储配置、WinDbg、Driver Verifier 和 Sysinternals 等工具的规范使用，以及有条不紊地审查日志和堆栈的习惯，可以将不可预测的敌人的蓝屏变成内核故障的非常准确的信息来源，帮助我们做出更明智的技术决策。