Windows 蓝屏代码 0x139 KERNEL_SECURITY_CHECK_FAILURE 参数

下表描述了参数 1 的可能值。

原因

使用参数 1 表和转储文件，可以缩小许多此类错误检查的原因。

LIST_ENTRY 损坏可能难以追踪，此错误检查表明已将不一致性引入双向链接列表（在将单个列表条目元素添加到列表或者从列表中删除时检测到）。
不幸的是，在损坏发生时不一定检测到不一致，因此可能需要一些侦探工作来确定根本原因。

列表条目损坏的常见原因包括：

• 驱动程序损坏了内核同步对象，例如 KEVENT（例如，在线程仍在等待同一个 KEVENT 时对 KEVENT 进行双重初始化，或者当另一个线程正在使用该 KEVENT 时允许基于堆栈的 KEVENT 超出范围）。这种类型的错误检查通常发生在 nt!Ke* 或者 nt!Ki* 代码中。当线程完成对同步对象的等待或者代码尝试将同步对象置于信号状态时，就会发生这种情况。通常，发出信号的同步对象是已损坏的对象。有时，具有特殊池的驱动程序验证程序可以帮助追踪罪魁祸首（如果损坏的同步对象位于已被释放的池块中）。
• 驱动程序损坏了定期 KTIMER。这种类型的错误检查通常发生在 nt!Ke* 或者 nt!Ki* 代码中，涉及发送计时器信号，或者从计时器表中插入或者删除计时器。被操纵的计时器可能是损坏的计时器，但可能需要使用 !timer 检查计时器表（或者手动遍历计时器列表链接）以确定哪个计时器已损坏。

有时，具有特殊池的驱动程序验证程序可以帮助追踪罪魁祸首（如果损坏的 KTIMER 位于已被释放的池块中）。

• 驱动程序对内部 LIST_ENTRY 样式的链表管理不善。一个典型的例子是在同一个列表条目上调用 RemoveEntryList 两次，而不在两次 RemoveEntryList 调用之间重新插入列表条目。其他变体也是可能的，例如将条目双重插入到同一列表中。
• 驱动程序释放了一个包含 LIST_ENTRY 的数据结构，但没有从其对应的列表中删除数据结构，导致在重用旧池块后检查列表时会检测到损坏。
• 驱动程序在没有适当同步的情况下以并发方式使用了 LIST_ENTRY 样式的列表，从而导致对列表的更新撕裂。

在大多数情况下，我们可以通过向前和向后遍历链表（dl 和 dlb 命令用于此目的）并比较结果来识别损坏的数据结构。

向前和向后行走之间的列表不一致的地方通常是损坏的位置。
由于链表更新操作可以修改相邻元素的列表链接，因此我们应该仔细查看损坏的列表条目的邻居，因为它们可能是潜在的罪魁祸首。

由于许多系统组件在内部使用 LIST_ENTRY 列表，驱动程序使用系统 API 的各种类型的资源管理不当可能会导致系统管理的链表中的链表损坏。

解决方法

确定此问题的原因通常需要使用调试器来收集其他信息。
应检查多个转储文件以查看此停止代码是否具有相似的特征，例如停止代码出现时正在运行的代码。

有关详细信息，请参阅使用 Windows 调试器 (WinDbg) 进行崩溃转储分析、使用 !analyze 扩展和 !analyze ：
在windows 中使用WinDBG 调试dmp文件

使用事件日志查看是否存在导致此停止代码的更高级别的事件。

这些一般故障排除提示可能会有所帮助。

• 如果我们最近向系统添加了硬件，请尝试移除或者更换它。或者与制造商联系以查看是否有可用的补丁。
• 如果最近添加了新的设备驱动程序或者系统服务，请尝试删除或者更新它们。尝试确定系统中导致新错误检查代码出现的更改。
• 检查事件查看器中的系统日志以获取可能有助于查明导致错误的设备或者驱动程序的其他错误消息。有关更多信息，请参阅打开事件查看器。

在系统日志中查找与蓝屏在同一时间窗口中发生的严重错误。

• 在设备管理器中查看是否有任何设备标有感叹号 (!)。查看驱动程序属性中显示的任何故障驱动程序的事件日志。尝试更新相关驱动程序。
• 运行病毒检测程序。病毒可以感染为 Windows 格式化的所有类型的硬盘，由此导致的磁盘损坏会生成系统错误检查代码。确保病毒检测程序检查主引导记录是否存在感染。
• 有关其他常规故障排除信息，请参阅蓝屏数据。

KERNEL_SECURITY_CHECK_FAILURE 错误检查的值为 0x00000139.
此错误检查表明内核已检测到关键数据结构的损坏。