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