到底是什么没通过安全检查
内核在自己的关键数据结构上保存着校验和与不变量，就像一家每秒对账数次的银行。停止代码 0x139 意味着某次对账出了错：链表指针不再指向它必须指向的地方，或者缓冲区的头部与内容对不上号。Windows 在此刻有意停机，因为带着损坏的内核状态继续跑，可能把垃圾数据写满整个磁盘。
破坏这些结构的元凶很少有什么神秘可言。负载下返回翻转比特的内存——常常是超出内存控制器真实承受能力的 XMP/EXPO 配置——是头号原因。越界写入自己缓冲区的驱动排第二，惯犯是显卡和杀毒驱动。受损的系统文件和读出损坏数据的濒死 SSD 补齐了名单。
- 不稳定的内存 — 超出 CPU 内存控制器真实承受能力的 XMP/EXPO 配置
- 越界写入缓冲区的问题驱动 — 显卡、杀毒和虚拟化驱动是惯犯
- 因更新失败或突然断电而损坏的系统文件
- 濒死的 SSD 在读取时返回损坏数据，SMART 属性中可见
- 激进降压或超频在负载下翻转比特
检测内存并修复文件
先从内存开始：它是最常见的原因，也是排查成本最低的一环。运行 mdsched.exe，按提示重启并跑完标准检测；结论会出现在事件查看器的 Windows 日志 → 系统中，来源为 MemoryDiagnostics-Results。标准检测只能抓到粗大的故障——所以如果结果干净而崩溃依旧，请在 BIOS 中关闭 XMP/EXPO，并在给内存开出清白证明之前逐条单独测试。
接下来是文件，在提权的终端里执行：sfc /scannow 将受保护文件与组件存储比对，然后 DISM /Online /Cleanup-Image /RestoreHealth 在 SFC 无法修复全部时修补组件存储本身，最后 chkdsk C: /f /r 在下次重启时清扫磁盘表面。软件一侧的收尾是显卡驱动的干净重装——下载最新驱动包，在设置 → 应用 → 已安装的应用中移除旧的，重启后全新安装。
把惯犯揪出来
如果做完这一切停止代码还活着，说明崩溃已经具体到可以点名了。C:\Windows\Minidump 里的小型转储带有出错地址和已加载模块列表；WinDbg 的 !analyze -v 命令或 BlueScreenView 这类读取器能把它们变成一个驱动名，而这个名字终结追捕。崩溃开始前几天安装的软件值得最先查看——卸载它既是检测也是治疗。
压箱底的重炮是 Driver Verifier（在管理员命令提示符下运行 verifier /standard /all），它让可疑驱动在自己的 bug 上崩溃，响亮而立即。它故意设计得危险：运行期间请做好蓝屏的心理准备，并记住退路——进入安全模式运行 verifier /reset 将其关闭。按这种方式驾驭，Verifier 能在一两天内把藏起来的驱动逼出来。
常见问题与解答
KERNEL_SECURITY_CHECK_FAILURE 是恶意软件的迹象吗？
很少是。这项检查抓的是损坏而非感染，原因绝大多数在硬件和驱动。搞破坏的 rootkit 有可能，但在名单上排得很靠后。
坏内存会导致 KERNEL_SECURITY_CHECK_FAILURE 吗？
会——它是单项最常见的原因。运行 mdsched.exe，若崩溃持续则关闭 XMP/EXPO 并逐条测试内存。
开机时的 KERNEL SECURITY CHECK FAILURE 怎么止住？
从 WinRE 进入安全模式（启动设置 → 按 4），卸载最近装上的东西，然后从中运行 SFC 和 DISM——崩溃很少会跟进安全模式里来。
继续阅读
联系我们: [email protected]