0x000000C5 对应的符号名是 DRIVER_CORRUPTED_EXPOOL。这个停止码的含义是：内核在操作可执行内存池时，发现池块的管理信息已经被破坏。这里的 ExPool 并不是普通的用户态堆，而是 Windows 内核为驱动程序、系统线程和内核对象分配内存的核心区域。每次驱动调用 ExAllocatePoolWithTag 申请池块时，系统都会在可用空间前后写入池头、池尾以及对应的标签信息。如果某个驱动越界写入、释放了不属于自己的池块，或者对同一块内存重复调用 ExFreePoolWithTag，这些管理字段就会被改成非预期值。系统并不会立刻报错，而是在下一次分配、释放或者专门的池完整性检查时发现损坏，然后触发 C5。
与很多人熟悉的 IRQL_NOT_LESS_OR_EQUAL 相比，DRIVER_CORRUPTED_EXPOOL 更偏向于内核池内容的实质损坏，而不是单纯的中断请求级别错误。它的出现通常意味着某个内核组件已经把垃圾数据写入了不该触碰的区域。由于可执行池被大量系统结构共享，实际肇事者可能并不是最后触发崩溃的那个驱动，这给定位带来了不小难度。
一、错误码符号与参数含义
DRIVER_CORRUPTED_EXPOOL 的检查码为 0xC5，系统在蓝屏时会附带四个参数，其中前两个最为关键。第一个参数通常表示损坏类型，例如数值 2 代表池块头已经被改写，数值 3 代表池块尾被改写，而其他数值可能指向不同的池管理结构异常。第二个参数则记录了被检测出损坏的池块地址。这个地址对于后续使用 WinDbg 分析内存转储非常重要，因为它可以反向定位哪个调用者曾经分配过这块内存。
为什么池头会被破坏？在 Windows 内核中，每次通过 ExAllocatePoolWithTag 分配一块可执行池时，系统会在实际返回给驱动的内存地址前后额外放置管理结构。驱动拿到的指针其实指向池块的数据区，而数据区前面是池头，后面是池尾。池头中保存了块大小、分配类型、标签以及指向前后池块的链表信息。如果驱动程序在释放后继续使用指针，或者写入长度超过了申请的大小，池头或池尾就会被邻接数据覆盖。系统在之后执行池分配或释放操作时，会校验这些管理字段，一旦校验失败就直接蓝屏。
需要注意的是，这种崩溃具有明显的延迟性。驱动越界写发生的时间和系统实际触发 0xC5 的时间可能相差很久，因为损坏的池块不一定会立即被再次访问。只有当某次池操作恰好遍历到损坏区域，或者系统主动执行池完整性检查时，问题才会暴露。因此，仅凭蓝屏瞬间的调用栈常常无法直接锁定真正的肇事驱动，必须结合内存转储和驱动验证器进行进一步分析。
二、从内存转储中定位问题驱动
发生 0xC5 后，系统通常会在 C:\Windows\Minidump 目录下生成小型转储文件，或者在 C:\Windows 下生成完整的内核转储 MEMORY.DMP。打开 WinDbg 并加载转储文件之后，第一件事就是执行 !analyze -v。这条命令会读取转储中的错误检查信息，并尝试给出可能的出错模块。虽然由于延迟性影响，它报告的模块不一定就是肇事驱动，但至少能提供系统崩溃时的上下文。
更有效的做法是利用 !pool 命令检查蓝屏参数中给出的池块地址。该命令可以显示这个地址所属的池页面、分配状态以及池标签。如果池标签仍然可读，它通常是一个四字节的 ASCII 字符串，对应驱动中调用 ExAllocatePoolWithTag 时传入的标签参数。例如标签为 Ntfx 可能指向某个文件过滤驱动，标签为 RaId 则可能对应某块 RAID 控制器的驱动。下面的示例展示了一个典型的分析过程：
kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* DRIVER_CORRUPTED_EXPOOL (c5) Arguments: Arg1: 0000000000000002, pool block header is corrupted Arg2: ffffe00012ab0c0, address of the corrupted block Arg3: 0000000000000000, not used Arg4: 0000000000000000, not used kd> !pool ffffe00012ab0c0 Pool page ffffe00012ab0c0 region is Nonpaged pool *ffffe00012ab0a0 size: 120 previous size: 30 (Allocated) *File
当静态分析无法确定肇事模块时，就需要启用 Driver Verifier。它会在驱动每次分配、释放和访问池内存时插入额外检查，一旦发现越界写入、重复释放或者使用已释放内存，系统会立即触发蓝屏，并在转储中准确记录违规驱动。启用验证器的命令如下：
:: 启用标准驱动验证器 verifier /standard /all :: 针对指定驱动启用验证 verifier /flags 0x00000001 /driver mydriver.sys :: 查看当前设置 verifier /query :: 关闭并清除验证器设置 verifier /reset
启用 verifier /standard /all 会让系统对所有非微软驱动进行严格检查，但这可能造成明显的性能下降。如果系统中有较多第三方驱动，建议先通过 verifier /query 查看驱动列表，然后优先选择最近安装或更新的内核驱动进行定向验证。注意，在启用 Driver Verifier 后系统可能因为频繁触发检查而变得不稳定，务必预留足够的重启恢复手段，例如在启动菜单中使用安全模式禁用验证器。
三、修复、回滚与系统完整性检查
一旦确定了可疑驱动，最直接的修复手段就是更新或回滚该驱动。对于显卡、网卡、磁盘控制器、虚拟化软件和安全软件等常见的内核驱动来源，可以优先从硬件厂商官网或 Windows 更新获取新版本。如果问题是最近一次驱动更新后才出现的，回退到上一版本往往能迅速恢复稳定。在设备管理器中找到对应设备，进入属性对话框的「驱动程序」选项卡，即可执行回滚或卸载操作。
第三方安全软件和系统优化工具是 0xC5 的高发来源。它们通常会安装文件过滤驱动、网络过滤驱动或进程监控驱动，这些组件运行在内核态，一旦处理池内存时存在微小错误，就会破坏 ExPool。如果无法确定具体是哪个组件，可以临时卸载所有第三方安全软件，只保留 Windows Defender，观察系统是否还会蓝屏。某些虚拟化程序、输入法组件和游戏反作弊模块同样会加载内核驱动，排查时不要遗漏。
除了驱动本身，系统文件损坏也可能间接引发池管理异常。可以使用 DISM 和 SFC 检查并修复 Windows 组件存储和受保护的系统文件。命令如下：
DISM /Online /Cleanup-Image /RestoreHealth sfc /scannow
如果 SFC 无法修复某些文件，可以结合 C:\Windows\Logs\CBS\CBS.log 定位损坏组件。此外，硬件层面的内存错误也可能导致池数据随机变化。Windows 自带的内存诊断工具可以帮助判断是否存在物理内存故障。在出现多次不确定的 0xC5 且驱动验证器未报告明确违规时，建议运行完整的内存测试。
四、手动分析池损坏与预防实践
当自动分析工具给出的信息不足时，可以借助 WinDbg 手动查看池块附近的内存。使用 dd 或 dq 命令读取蓝屏参数中的地址，观察池头是否出现了看似随机的数据。正常池头通常包含相对固定的结构模式，例如块大小、标签和链表指针；如果看到大段全零、全 FF 或者明显不属于内核地址空间的值，通常说明这里已经被覆盖。再结合 !poolfind 命令搜索相同标签的池块，可以判断该驱动是否分配了大量对象，从而辅助确认其行为是否异常。
长期预防 0xC5 需要从驱动质量、系统更新和测试策略几个方面入手。对于开发者，应尽可能使用内核模式驱动框架 WDF 而不是直接调用 WDM 接口，因为 WDF 在内存管理和对象生命周期上提供了更安全的封装。对所有池分配必须使用明确的标签，并严格管理引用计数，避免释放后使用和重复释放。在测试阶段应始终启用 Driver Verifier 和 GFlags 的池跟踪功能，让越界错误在开发阶段暴露。
对于普通用户和管理员，建议保持系统与驱动程序更新节奏，避免长期运行在过期版本上。安装新的硬件或软件驱动前，先创建系统还原点，以便在出现 0xC5 后能快速回退。如果一台机器反复出现 DRIVER_CORRUPTED_EXPOOL，且更换过多个驱动版本仍然无法解决，可以重点检查主板 BIOS 设置中的内存相关选项，关闭不必要的内存超频或 XMP 配置，并确保所有硬件固件均为最新版本。
总的来说，0xC5 的核心始终指向内核池的完整性被破坏，而不是表面上的某一个模块出错。只要沿着池标签、驱动验证器和系统完整性检查这三条线索推进，大多数情况下都能找到真正的肇事组件，并让系统重新恢复稳定。
0x000000C5DRIVER_CORRUPTED_EXPOOL蓝屏修复修改时间：2026-09-25 11:00:08