看看Windows 10为什么会崩溃
假设一切顺利，只要打开转储文件，WinDbg就可以识别操作系统和二进制文件，找到正确的符号表文件，下载所需文件并运行基本分析。如果这是WinDbg第一次在此系统上运行，或者如果您正在查看来自另一个系统的转储文件，您以前没有加载文件，这可能需要一些时间。在随后的会话中，分析可能会更快，因为所需的大部分或所有符号都已在硬盘上。
提供的信息包括WinDbg的版本、打开的转储文件的位置和名称、正在使用的符号搜索路径，甚至下面所示的简要分析。
行“可能由：myfault.sys引起”在本例中是正确的，因为它是NotMyFault的驱动程序名。
通常，在诊断Windows崩溃的原因时，需要更多的信息。例如，您可能认识这个驱动程序，但您可能不确定它是否是最新的版本;你可能认不出司机，也不知道是谁开的车;或者在其他情况下，驱动程序可能实际上来自微软，并与操作系统内核相关，这使得它不太可能被怀疑。要了解更多信息，您通常需要两个命令:
分析-v和LMVM
注意:第一个命令发音为“bang analyze dash vee”
命令
| WinDbg命令 | 描述 | 细节 |
|---|---|---|
| !分析-v | 以详细模式分析崩溃事件 | 描述系统崩溃时的状态、遇到的错误并确定可能的罪魁祸首 |
| Lmvm(模块名称) | 以详细模式加载模块数据 | 显示以命令命名的模块的元数据 |
多年来，微软一直在不断地发展和完善WinDbg。例如，虽然上面列出的两个命令通常会在WinDbg屏幕底部的命令窗口中输入，但会显示“kd>”提示符(代表内核调试器)，现在可以通过在WinDbg接口中选择热链接来启动这两个命令。
!分析-v选择的输出！analyze-v提供了有关系统崩溃事件的更多详细信息。在这种情况下，分析准确地描述了测试驱动程序（myfault.sys）的操作，测试程序指示该驱动程序以过高的中断级别访问地址。
输出来自！分析-vDRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
试图在中断请求级别(IRQL)上访问一个过高的可分页(或完全无效)地址。这通常是由于驱动程序使用不正确的地址造成的。
|
重要的一点是，WinDbg命名的可疑模块是myfault，因为我们知道这是第三方驱动程序，他很可能有罪。
为了更好地了解操作系统崩溃时发生了什么，看看堆栈。
走堆栈查看调试器显示的堆栈输出总是很重要的，因为它显示了谁处于活动状态以及导致崩溃的原因。查看堆栈时，总是查看堆栈的最右边端，以了解任何第三方驱动程序，并且始终记住堆栈是按逆时针顺序显示的。因此，事件顺序从下到上；当系统执行每个新任务时，它会显示在顶部，向下推动以前的操作。在这个堆栈中，您可以看到NotMyFault/myfault他很活跃。在驱动程序的最后一个活动之后，Windows 10声明PageFault然后一个错误检查使系统停止(蓝屏)。
我在技术会议中经常使用的一个比喻是，将堆栈行走与走进刚刚发生谋杀的房间，发现地板上有一具尸体，有人站在尸体旁边，手里拿着一把冒烟的枪;这并不意味着他是有罪，但这肯定会让他怀疑第一．
|
假设我们需要关于可疑模块的更多信息，运行lmvm。
lmvm(模块名称)现在我们有一个可疑的模块要考虑，重要的是要了解更多。这样做的两个关键原因只是为了确保它确实是第三方模块，并确定它是否是过时的模块。lmvm告诉这两个和更多，如展览所示。例如，我们可以看到模块的制造者是SysInternals，它的时间戳是2012年4月。
当然，我们知道SysInternals已经被微软吸收了。然而，该模块几乎不是一个内核操作系统驱动程序，因此它满足我们的演示目的，扮演第三方驱动程序的角色。此外，一个4岁的司机不太可能了解最新情况。如果这是一个真实的情况，并且这个驱动程序的名字是，例如，一个视频驱动程序，那么几乎肯定会有一个包含修复程序的更新的驱动程序。从lmvm中，您将知道该向哪个供应商寻求有关驱动程序的更新信息，并且很可能知道要安装的更新版本。
虽然大多数BSODs原因很容易归因于第三方驱动程序，但有些原因并不清楚。在这些情况下，原因可能是从故障机箱风扇导致的系统过热到故障内存模块。
没有明确或一致原因的反复发生的崩溃通常来自内存问题。检查内存的两个好方法是Windows 10内存诊断和Memtest86．
