![手动引发的崩溃(错误检查 0xDEADDEAD)是否会触发磁盘检查?](https://linux22.com/image/1342707/%E6%89%8B%E5%8A%A8%E5%BC%95%E5%8F%91%E7%9A%84%E5%B4%A9%E6%BA%83%EF%BC%88%E9%94%99%E8%AF%AF%E6%A3%80%E6%9F%A5%200xDEADDEAD%EF%BC%89%E6%98%AF%E5%90%A6%E4%BC%9A%E8%A7%A6%E5%8F%91%E7%A3%81%E7%9B%98%E6%A3%80%E6%9F%A5%EF%BC%9F.png)
Windows 内置了一项高级功能,可让用户手动启动 BSOD。它是一种调试工具,用于在出现挂起或冻结(但不一定限于此)时停止系统。
使用时,它会导致出现 BSOD,并显示字符串MANUALLY_INITIATED_CRASH1
和奇怪的代码0xDEADDEAD
。
这次崩溃的重点在于它是用户故意造成的,所以它不是(或者至少不应该)是由硬件错误或坏驱动程序引起的不可预测事件(至少不是一定糟糕的司机)。
那么问题是,执行手动崩溃是否能正确刷新磁盘缓存等,以便驱动器在重新启动时处于有效状态,从而无需运行chkdsk
。
答案1
由于无法访问 Windows 源代码,我无法给出明确的技术答案,但是我可以报告我的测试结果。
在不同情况下(至少是我所能创造的最不同的情况下)执行手动崩溃几次后,我发现手动 BSOD 的行为似乎与常规 BSOD 非常相似。也就是说,它通常会导致chkdsk
在下次启动时运行(虽然可能并不奇怪,我还没有看到在扫描期间发现任何实际错误),但偶尔,它不会运行(就像一些真正的 BSOD 有时不会导致chkdsk
运行一样)。
看起来,是否chkdsk
运行取决于崩溃前的磁盘使用情况,而不管 BSOD 的原因是什么,并且手动运行在任何方面都没有什么特殊之处。
(这很奇怪,因为它很容易被设计成至少先尝试快速冲洗;最糟糕的情况是它失败了。当然,这可能是由于底层架构的性质以及功能的执行方式造成的。)
答案2
我想是的。NTFS 是一个日志文件系统,如果系统因 BSOD 突然停止,则需要将待处理的日志条目上传到主文件系统中。磁盘写入期间的(手动)BSOD 也可能对文件系统的结构产生影响,因此检查它似乎是明智的。