【minidump】干货：如何一分钟解决Windows 10崩溃问题

你们遇到过小编这样的事吗？

真的没有留恋啊。但是为了避免这种情况再次发生，小编今天将向大家展示如何安装你们的系统。出现问题的时候，你可以尽快找到大多数故障的原因。(大卫亚设)。

蓝屏

在Windows 10中，蓝屏看起来与Windows 8一个模样。蓝屏中显示的仍然是皱眉的图形表情以及显示消息“Your PC ran into a problem . . .”不过，此屏幕看起来比原始的蓝屏更友好一些。但是，一个真正友好的屏幕显示会告诉你问题的原因以及如何修复它。蓝屏问题其实不会很难，因为大多数蓝屏死机引起的原因经常是由于第三方驱动程序的错误行为所导致的，而这些行为很容易被MS Windows调试器所识别。

对于早期版本的操作系统，请参阅以下内容：

Windows 8：文章《如何尽快解决Windows 8崩溃问题》和幻灯片《如何解决Windows 8崩溃问题》；

Windows 7：《几分钟解决Windows 7崩溃问题》；

Windows XP/2000：文章《如何尽快解决Windows崩溃问题》。

必须明确的是，本文论及的是系统崩溃问题，而不是应用程序崩溃或系统挂起。在系统完全崩溃时，操作系统会总结性提示某种对象出现了错误(如内存损坏)，继续操作可能会导致严重的或灾难性的结果。因此，操作系统试图关闭，并尽可能做到干净地结束——在该过程中保存系统状态信息——然后以一种刷新环境和带有待分析的调试信息重新启动(如果设置成这样做的话)。

为什么Windows 10会崩溃

可以肯定的是，自1985年问世以来，Windows特征及规模不断发展壮大并越来越稳定。然而，尽管操作系统中内置了保护机制，崩溃现象仍然不断发生。

Windows历来都是以“层保护模式”著称，而Windows 10操作系统也不例外。Windows 10运行于两个层模式下：一个是用户模式(Ring 3层)；另一个是内核模式(Ring 0层)。这个设计思想是很容易理解的：在内核模式下运行核心操作系统和设备驱动程序代码，而在用户模式下运行软件应用程序和用户模式驱动程序。因此，应用程序想要访问操作系统服务和硬件的话，它们必须要调用充当代理服务的Windows服务。因此，通过阻止用户模式代码直接访问到内核模式，操作系统操作就会普遍得到保障。

问题是：内核模式代码出错了!在大多数情况下，由于在内核模式下活动的第三方驱动程序发生了错误的调用，例如对并不存在的内存的访问或者改写操作系统代码，导致系统故障。当然，Windows本身是很少出现故障的。

Windows 10崩溃时，从哪里寻求帮助

当出现BSOD问题时，你可以通过很多地方进行求助。下面列出其中的几个帮助去处。例如，ConfigSafe网站能够告诉你是什么驱动程序发生了变化，而AutorunCheck网站会告诉你哪些Windows自动运行设置已被更改。这两处帮助资源都能够有效地帮助你探测出导致系统失败的罪魁祸首。此外，每个人都应该拥有一本《Windows Internals》；它简直是每个网络管理员和首席信息官应该参考的“圣经”，尤其是本书第二部分的第14章“崩溃转储分析”(Crash Dump Analysis)更值得你认真阅读。

当我问Mark Russinovic(《Windows Internals》作者之一)：为什么网络管理员或首席信息官(而不是程序员)应该阅读这本书?他说，“如果是由你管理Windows系统，但你却不知道进程和线程的区别，不知道Windows如何管理虚拟内存和物理内存，不知道内核模式驱动程序可导致系统崩溃，那么你正在妨碍你自己。因此，理解这些概念对于充分理解故障转储及能够发现相关线索是至关重要的。

所以，WinDbg工具能够提供系统出错时有关系统状态的数据，而《Windows Internals》则更能够把那些神秘的数据变成可操作的信息，从而进一步帮助你解决问题。

帮助你发现BSOD的部分参考网站

何谓内存转储?

所谓“内存转储”，是指在系统崩溃时系统内存中内容的拷贝或快照。转储文件非常重要，因为它们可以显示：在系统出问题时谁正在做什么。转储文件因其内容的特别性而很难解析，除非你知道要寻找什么。

Windows 10可以产生五种类型的内存转储文件，下面针对每一种作有关描述。

1.自动内存转储

位置：%SystemRoot%Memory.dmp ;

大小：操作系统内核大小。

自动内存转储是你安装Windows 10时的默认选择选项。它是为了支持“系统托管”页面文件配置而创建的。这种“系统托管”页面文件配置已被更新，以便减少在磁盘上的页面文件大小(主要针对小型SSD)，但也有益于使用大容量RAM的服务器。自动内存转储选项将生成一个内核内存转储;不同的是，当你选择“自动”(Automatic)方式时它允许SMS进程减少页面文件大小——小于RAM的大小。

如果你想检查或编辑你的系统分页文件大小，请切换到以下位置(并请参考下面图形示意)：

“Windows10按钮—控制面 板—系统与安全—系统—高级系统设置—性能—设置——高级——修改”。

2.活动内存转储

位置：%SystemRoot%Memory.dmp

大小：三倍于内核大小或者自动转储文件的大小。

活动内存转储是微软最近研制出的新模式。尽管比完全内存转储尺寸小得多，但其尺寸大约也是内核转储大小的三倍。这是因为它包括内核空间和用户空间两个部分。在我的测试系统上，我使用了4GB RAM+英特尔酷睿i7 64位处理器配置运行Windows 10，活动内存转储大约占了1.5GB。因为有时需要传送转储文件，所以我对其进行了压缩，减小到大约500MB。

3.完整内存转储

位置：%SystemRoot%Memory.dmp

大小：已安装的RAM尺寸+1MB。

完整(或全部)内存转储使用最大的转储文件，因为它包含了所有的Windows操作系统使用的物理内存。你可以假定该文件约等于已安装的RAM的大小。随着许多系统都各自占用多个GB的存储空间，这会迅速导致出现存储问题，尤其是当你面对比偶尔系统崩溃更多的场合时。一般来说，请尽量使用自动转储文件方案。

4.内核内存转储

位置：%SystemRoot%Memory.dmp

大小：约等于被核心模式组件所占用的物理内存大小。

内核转储所用文件大小约等于Windows 10内核所占用RAM的大小，在我的测试系统上大约占700MB。进一步压缩的话，将减小近80%，约为150MB。内核转储文件的优点之一是，它包含分析所需要的二进制文件。默认情况下，内核转储设置会创建一个核心转储文件，只保存最新的内容并为每个事件创建一个小型转储。

5.小内存转储(又称小型转储)

位置：%SystemRoot%Minidump

大小：在x86平台上至少占64K，在x64平台上至少占128KB(在我的Windows10测试PC上使用约279K)。

小型转储能够提供特定的内存页面，其中的数据包含出故障时寄存器指向的位置，同时还包含出错线程的堆栈信息。导致它们这么小的原因是，它们并不包含任何失败时仍处在内存中的二进制或可执行文件。但是，这些文件对于调试器的后续分析是极其重要的。

【提示】有关Windows 10其它类似的参考文章有：《如何探测Windows10中携带了错误的设备驱动程序》和《导致Windows 10蓝屏的原因是什么?》。

只要你在创建了转储文件的计算机上进行调试，WinDbg程序就可以在系统根目录文件夹(除非在转储文件创建后系统更新改变了二进制文件)中找到上述内容。另外，调试器应该能够通过SymServ(微软的符号文件在线存储)自动找到它们。除非用户作了更改，通常Windows 10会被设置为最新事件创建自动转储文件，并针对每一个崩溃的事件创建小型转储，为系统生命周期内所有系统崩溃事件提供历史记录。

配置Windows 10生成合适内存转储

打开“控制面板”程序并切换到“启动与恢复”窗口：

“Windows10按钮—控制面板—系统与安全—系统—高级系统设置—启动与恢复—设置——自动内存转储”。

在最后的窗口“启动与恢复”中，请选择“自动内存转储”选项(如下图所示)，并勾选“自动重新启动”(通常这两个选项都是Windows 10下的默认设置)。

安装WinDbg

系统要求：为了进行基于WinDbg的崩溃分析而安装一台PC，你将需要以下内容：

32位或64位Windows 10：这取决于运行调试器的处理器，你可以使用32位或64位调试工具。请注意，转储文件是基于x86平台还是基于x64平台上生成的并不重要。

WinDbg：这是Windows 10提供的Windows SDK的Windows调试工具部分，你可以从微软网站免费下载。

硬盘空间：大约250MB的硬盘空间(不包括用于转储文件或符号文件的存储空间)。

互联网：在线互联网连接

下载WinDbg：从微软网站下载(约1.2MB)。注意，此下载将直接启动安装程序，你将从中选择要安装的组件。你可以转到微软网站的硬件开发人员中心页面，然后向下滚动到“Get debugging tools”，然后选择“Debugging Tools for Windows 10 (WinDbg)”(下面的“A”项)，也可以启动立即下载(下面的“B”项)。

A)微软硬件开发中心(https://msdn.micro/en-us/windows/hardware/hh852365);

B)自动下载(http://go.micro/fwlink/p/?LinkId=536682)。

空间需求：你可以忽略“Estimated disk space required”选项，直到你取消选择不需要的工具。请确保取消选择所有除了“Debugging Tools for Windows”以外的选项，其中包括内核和用户模式调试器，以及帮助和使用工具提示信息等。除非你想进行编程，否则你并不需要安装其他模块;这样，你将节省大量的磁盘空间。在这台测试机中安装所占用的磁盘空间最大从2.5GB到最小大约250MB。

运行：在系统中安装软件开发工具包(SDK)，你将使用它来分析内存转储文件。请记住，它可以是一台运行另一个版本的Windows系统(并不需要一定运行Windows 10)的32位或64位计算机。关键步骤如下：

1.启动。

2.指定安装位置：默认安装位置是C:Program Files (x86)Windows Kits10。你可以选择默认，还可以选择另一个位置来定义你想安装的软件路径。

3.接受或者拒绝Windows隐私问题。

4.接受许可协议。

5.取消选择除了选项“Debugging Tools for Windows”外的所有内容。

“符号”到底有多重要?

安装完WinDbg后，但在调用转储文件之前，你需要符号表文件。符号文件相对于软件很像高速公路上的出口标记;它们会告诉你所在地是哪里——如果你停下车来的话。其实，它们只不过是把源代码编译成可执行文件(从高级语言变成机器代码)过程中的一种副产品而已。在此过程中，编译器使用一组标识符、标识符在程序中的位置以及属性信息创建符号文件。

然而，程序不需要此信息来执行，所以符号通常存储在一个单独的文件中。这将减少可执行文件的大小，从而导致占用较少的磁盘空间和更快的加载与运行速度。此外，这些符号文件通常不是与操作系统或应用程序一起发行的。那么，问题在于：当一个程序导致系统出现故障问题时，操作系统只知道问题在其中出现的十六进制地址，但不知道那里是谁以及他在做什么。幸运的是，微软提供了对SymServ的访问，这一举措最终解决了问题。

当打开某一内存转储时，WinDbg会查看可执行文件(如.exe，.dll等)并提取有关版本信息。然后，它创建一个到微软网站上的SymServ的请求，其中包括版本信息和描述信息的精确的符号表位置信息。正如前面提到的，它不会针对你正在进行故障排除的特定操作系统下载所有的符号;它将只下载它所需要的内容。

在我们的示例情况下，即是针对Windows 10 PC系统，符号文件对应的文件夹总共有22MB大小。在运行众多的崩溃测试后，该文件夹大约占35MB。在另一个系统上，我运行了来自于多台不同个人电脑的若干测试结果发现：上述文件夹大小仍然不足100MB。因此，只需记住，如果你打开来自于其他机器(可能使用Windows操作系统的其他变种)上的文件，你的文件夹可能会继续增长。

或者，你可以选择下载和存储来自微软网站的完整的符号文件。在这样做之前，请注意：针对每一个符号包，你应该保留至少1GB的可用磁盘空间。这是因为，除了存储文件所需的空间外，你也需要空间来存储临时文件。即使在今天硬盘成本很低的情况下，使用的空间仍然值得注意。

每一个x86符号包可能需要750MB或者更多的硬盘空间。

每一个x64符号包可能需要640MB或者更多的硬盘空间。

符号程序包都是非累积性的，除非另行说明;否则，如果你使用的是Windows 10的SP2版本，那么，在你为SP2安装符号程序之前，你需要针对原始的RTM版本和SP1版本也都安装对应的符号包程序。

【提示】如果你想下载符号文件并想把它们保存到本地，那么请务必读一下网址处提供的资料。

SymServ(又名：SymSrv/符号表服务器)，是一个极为重要的服务，由微软免费提供，用于确保准确的内存转储分析。要想使用这个服务，你只需配置一下WinDbg来定位这个服务，则SymServ就会自动检索特定于提供转储内容的确切版本Windows的符号。而且，在分析完一台机器中的转储文件后，如果你从另一台机器上调用一个转储文件，那么WinDbg和SymServ都将自动检索相应于该版本的操作系统的符号。

配置WinDbg

从上面的Windows 10界面上，选择Windows 10按钮，然后选择“WinDbg |更多| 以管理员运行”。

然后，你会看到一个有几个菜单项和一个空白主窗口区域的窗口。打开转储文件之前，你必须告诉WinDbg在哪里可以找到符号文件。

配置WinDbg：把Windows转储文件与适当的符号文件关联起来不仅是知道正运行的操作系统的版本号的问题。操作系统存在无数种变体，这并不是一个显而易见的事实。唯一可以肯定哪个文件是正确的方式是让SymServ帮你找到它。

设置符号文件路径：Windows存在大量的符号表文件，因为每一个版本、每一次更新、每一个补丁程序和无数的一次性变体都会各自产生一个新文件。而使用错误的符号来评价一个转储文件将像使用波士顿地图来导航旧金山一样糟糕。

进入如下路径：

srv*c:cache*

在上面命令的*c:cache*位置处，请确保替换成你想要存储符号的位置。

在本例中，我们使用“c:symbols”。然后选择【OK】。

【注意】请确保你的防火墙允许访问m，而不仅仅是网址www.micro。

如果你没有可查看的内存转储，怎么办呢?请不要担心。你可以自己生成一个!是的：你可以导致你的系统崩溃，并且安全地这样做。有好几种不同的方式可以实现这一目的，但最好的方法是使用一种称为NotMyFault的由Russinovich研发的工具。

你可以从网址处下载NotMyFault，你也可以从图书《Windows Internals》宣传网站的链接处http://technet.micro/en-us/sysinternals/bb963901.aspx下载。该工具中包括了一个选项允许加载行为错误的驱动程序(这需要系统管理特权)。下载之后，你可以在桌面上创建一个相应的快捷方式来简化访问。

【提示】图书《Windows Internals》第二部分的第14章完全涵盖了NotMyFault工具的使用说明，还有更重要的崩溃转储分析。

【警告】使用NotMyFault将创建一个系统崩溃，但是我在使用该工具时从未出现过问题。不过，在实际应用中也不敢做任何保证，特别是在计算机领域。所以，请准备好你的系统，让任何需要访问它的人注销几分钟。把任何包含你可能失去信息的文件都保存一下，然后关闭所有应用程序。适当准备后，然后关闭这台机器，重新启动，你会注意到一个小型转储和一个内核(或你选择的任何大小)转储都应该已经创建成功。

打开转储文件

定位转储文件：在Windows系统中转储文件位于两个地方，具体取决于你打开的类型︰

所有转储文件(除了小型转储外)都位于c:WindowsMEMORY.DMP;

小型转储类型对应的转储文件位置：c:WindowsMinidump[实际的Minidump文件名]

请注意，不像其他命名为MEMORY.DMP的其他类型的转储文件一样，小型转储会被自动单独命名;因此，不会覆盖以前的文件。这是一个不错的特性，因为它们的体积都很小。

打开转储文件：要打开你选择的文件，请选择命令“File | Open Crash Dump”。

如果你看到如下提示，请立即停止：

*** WARNING: Unable to verify timestamp for n *** ERROR: Module load completed but symbols could not be loaded for n

这是很重要的。当你在WinDbg输出的开始附近看到这两行消息时，这意味着你不会得到你需要的分析结果。当“Bugcheck Analysis”自动运行并显示下面的消息后，刚才的说法将被进一步证实。

当你看到下面的消息：

“*** ERROR: Symbol file could not be found. Defaulted to export symbol for n. . .”

这意味着，WinDbg找不到文件的n(Windows OS内核本身)正确的符号位置，也就无法进行正确的分析。

***** Kernel symbols are WRONG. Please fix symbols to do analysis

导致上述错误的原因可能存在如下几种：

没有提供路径或者路径错误：没有提供指向符号文件的路径或者路径不正确(可以检查一下误输入空格等笔误)。请检查“Symbol Path”(参考上图中的“Setting symbol file path”)部分。

连接失败：请检查你的互联网连接，以确保它可以正确工作。

访问被阻止：防火墙阻止访问符号文件或文件在检索过程中损坏。请确保没有防火墙阻止访问m(它可能只会允许www.micro访问)。

请注意，如果防火墙最初阻挡WinDbg下载一个符号表，那么这可能导致一个损坏的文件。如果取消防火墙阻止并尝试再次下载符号文件后仍不能工作，则说明该文件仍然是损坏的。最快的解决方法是：关闭WinDbg，删除符号文件夹(你最有可能设置在c:symbols这个位置)，并取消防火墙阻止。然后，重新打开WinDbg和转储文件。调试器将重新创建此文件夹并重新下载符号。切记：不要马上进行分析，直到确保更正此问题。

如果你看到以下错误，那么请不用担心：

*** WARNING: Unable to verify timestamp for my *** ERROR: Module load completed but symbols could not be loaded for my

这意味着，调试器寻找在文件my上的信息。然而，由于它是一个第三方的驱动程序，所以它内部根本就没有符号，因为微软不会存储所有的第三方驱动程序(【说明】my是由属于微软旗下的SysInternals网站提供的，但它肯定不是一个常规的微软产品。在我们的示例应用中，它用于代表第三方驱动程序)。关键是，你可以忽略此错误消息。典型情况下，软件供应商不会与驱动程序一起提供相应的符号文件，而且他们也没有必要针对你的目的而提供;而在没有这些符号文件情况下，你仍然可以找出存在问题的驱动程序。

观察为什么Windows 10会崩溃

假设一切都很顺利，那么你只需要打开WinDbg产生的转储文件来确定操作系统和二进制文件，找到正确的符号表文件、下载所需的文件并进行基本的分析即可。如果这是WinDbg首次运行在此系统上，或你正在查看一个来自于另外一个系统(你从未在其上为转储文件加载过文件)的转储文件，那么，这可能需要花费一点时间。在接下来的问题分析中，进度可能会加快，因为大部分或所有需要的符号都已经存在于硬盘上了。

接下来，我们所分析的信息范围包括：WinDbg的版本，打开的转储文件的位置和名称，正在使用的符号搜索路径，以及一点总结性分析。

在我们的示例中，我们知道“Probably caused by : my”这一行提示是正确的，因为它正好是NotMyFault驱动程序的名称。

通常情况下，在诊断Windows崩溃的原因时还需要更多的信息。例如，你可能已经认出某某驱动程序，但你可能不确信它是最新的版本;你也有可能还没有识别出驱动程序或知道谁开发的此程序;或者在其他情况下，某某驱动程序实际上可能正好来自微软自己并关联到操作系统内核，这使得它不太可能成为嫌疑程序。要了解更多信息，你通常需要的都是两个如下命令。

!analyze –v与lmvm

命令比较

多年来，微软公司一直继续改进和完善WinDbg。例如，在上面列出的两个命令可以同时被输入到WinDbg屏幕底部“kd >”提示符命令窗口中。现在，这两个命令都可以通过在WinDbg界面中选择一个热链接而启动

使用!analyze –v

使用命令!analyze –v的输出将提供有关系统崩溃事件的更详细的说明信息。在我们的示例程序中，分析结果已经准确地描述了测试驱动程序(my)的行为。在此，测试程序指示此测试驱动程序在访问一个很高级别的中断地址。

命令!Analyze –v的输出结果DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)

在这里，程序试图以过高的中断请求级别(IRQL)访问一个可分页(或完全无效)地址。这通常是由于驱动程序使用了不正确的地址所导致的。

注意，BUCKET_ID_FUNC_OFFSET是到可疑模块的基地址的距离，而问题代码正驻留于此地址处。

最重要的部分是，被WinDbg命名的可疑模块是myfault;既然我们知道这是一个第三方驱动程序，那么它很有可能就是“罪犯”。

为了获得一幅更好的图片来观察当操作系统出现问题时究竟发生了什么事情，我们不妨来观察一下堆栈中的信息。

观察调试器显示的堆栈输出一直是很重要的，因为它能够显示出哪个程序处于活动状态，是否是它正在做的操作导致了系统的崩溃。当观察堆栈时，总是要观察堆栈最右端存在的任何第三方驱动程序，并且要永远记住堆栈是以逆时间顺序显示的。因此，事件发生的顺序是从底部到顶部;随着每个新的任务由系统执行，它会显示在顶部，把以前的动作压入堆栈中。在下图展示的堆栈中，你可以看到NotMyFault/myfault正处于活动状态。紧接着驱动程序的最后一项活动，Windows 10声明了一个PageFault，然后是一个BugCheck，从而停止了系统的执行(蓝屏)。

在技术会议上，我常用的一个比方是：堆栈遍历好比是你踏入一个房间，而此房间中刚刚发生了一宗谋杀案，你发现地板上躺着死者尸体，而有人正站在他的旁边，手中还握着正冒烟的手枪。这并不意味着他就一定是凶手，但他肯定是头号嫌疑犯。

NotMyFault/myfault模块处于活动状态

假设我们需要关于可疑模块的更多的信息，那么我们可以运行命令lmvm。请参考下图。

使用lmvm [模块名]

现在，既然我们已经有了一个可疑的模块，那么再更多地了解有关它的信息就很重要了。这里有两个关键点：第一，确保它确实是一个第三方模块;第二，确定它是否是一个过时的模块。lmvm命令能够告诉我们这两种信息以及更多的内容(请见上图)。例如，我们可以看到：模块的制造商是SysInternals，它有一个时间戳是2012年4月。

当然，我们知道SysInternals已经被微软并入。然而，该模块几乎就不是一个内核操作系统驱动程序，所以它正好可以作为我们的演示目的来担当第三方驱动程序这一角色。而且，也不太可能出现一个只有四年寿命的驱动程序就需要更新。如果这是真实的情况，例如，驱动程序是一个视频驱动程序，那么几乎可以肯定一定会存在一个带有补丁的更新的驱动程序。从lmvm工具中，你会知道应该同哪一个供应商联系以更新有关驱动程序和信息;当然，有可能是要安装一个更新的版本。

虽然大多数BSOD错误容易归因于第三方驱动程序，但有些并不那么清楚。在这些情况下，原因可能是从因系统过热导致机箱风扇故障到错误的内存模块等任何情况。

我们不妨来回顾一下：那些没有明确或一致原因的系统崩溃通常都是由内存问题引起的。进行内存检查存在两种值得推荐的方法：一种是使用Windows 10内存诊断程序;另一种是使用Memtest86。

Windows有罪吗?

也许没有。多年来，许多人都责怪Windows操作系统的崩溃问题，而事实上，由于Windows自身原因导致崩溃的情况极少。通常情况下，当把Windows中的某代码块命名为culprit时，通常是其他一些驱动程序发出请求要求Windows组件执行一项操作却传递了一个错误的指令，例如告诉它写入一个并不存在的内存地址等。在这种情况下，操作系统通常被视为“持有确凿证据的罪犯”，但其实他只是按照吩咐的去做了；这使得识别请求的初始发起者往往成为一项艰巨的任务。

防病毒、备份和其他实用程序怎么样呢?人们常常看到像那些防病毒和备份工具这样的驱动程序正是使用了类似于“culprit”这样的命名。然而，他们可能不是真正的“坏蛋”。这种实用程序必须处于活动状态，因为它们必须时刻关注文件变化活动；这意味着，无论发生了什么事情，都会经常在堆栈上发现它们的踪迹。

不管你是否使用谷歌搜索引擎找到了一个名字为“culprit”的罪魁祸首，你所遇到的任何问题都有可能已被其他人经历过，而且在互联网上存在无数的地方可能提供相应的帮助信息。

最后，当你发现你将能够很快在没有其他帮助并免费解决大多数BSOD问题时，你阅读本文以及设置WinDbg的时间将会很好地得到赔偿。请记住：仔细研究一下《Windows Internals》将会极大扩展你的新发现技能。

（惊喜在这里）好了，今天的内容就先到这里啦~你有没有get技能呢？为了能更好的帮助各位用户，可在文章下部留言你们最想了解哪一方面的内容，我们会选择留言最多的内容，请这一方面的专家来回答你们的问题~~~动起你们的小手~留下你们的宝贵意见吧~

原文标题：Hardcore Windows: How to solve Windows 10 crashes in less than a minute，作者：Dirk A.D. Smith

【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】