找到蓝屏代码0x000000D1的所有原因和解决方法。
0x 000000d 1 river _ IRQL _ not _ less _ or _ equal◆错误分析:通常是驱动程序有故障导致的(比如罗技MouseWare 9.10和罗技鼠标9.24驱动程序都会导致此故障)。同时，有缺陷的内存、损坏的虚拟内存文件和一些软件(如多媒体软件、防病毒软件、备份软件和DVD播放器软件)也可能导致此错误。◇解决方法:检查新安装或升级的驱动程序(如果蓝屏出现类似“acpi.sys”的文件名，肯定是驱动程序问题)和软件；测试内存是否有问题；进入“恢复控制台”，到虚拟内存页面文件Pagefile.sys所在的分区，执行“del pagefile.sys”命令删除页面文件；然后在页面文件所在的分区执行“chkdsk /r”命令；进入Windows后重置虚拟内存。如果你在上网的时候遇到这个蓝屏，而且你只是在下载和上传很多数据(比如网游和BT下载)，应该是网卡驱动有问题，需要升级它的驱动。
以下情况会导致系统蓝屏崩溃:1、内核模式下运行的设备驱动程序或操作系统函数引发未处理的异常，如内存访问违规(因试图写入只读页或试图读取当前未映射的内存地址(即无效地址)而导致)。2.调用内核支持例程会导致重新调度，例如当中断请求级别(IRQL)为DPC/Dispatch级别或更高级别时，等待被标记为等待的调度对象。3.在DPC/Dispatch级别或更高的IRQL级别，由于数据存在于页面文件或内存映射文件中，所以会出现页面错误。这将要求内存管理器等待I/O操作发生。但是，如前所述，您不能在DPC/调度级别或更高的IRQL级别等待，因为那需要重新安排。4.当检测到内部状态表明数据已经被破坏或者在保证数据不被破坏的情况下系统无法继续执行时，设备驱动或者操作系统函数明确请求系统崩溃(通过调用系统函数KeBugCheckEx)。5.出现硬件错误，例如处理器的机器检查功能报告异常或NMI。了解了以上三点，相信你会欣赏Windows的大无畏牺牲精神，原谅它的“蓝脸”。事实上，在大多数情况下，第三方设备驱动程序导致了Windows的崩溃。对于Windows XP用户提交到微软OCA(微软在线崩溃分析)网站的内存转储文件，微软对崩溃原因做了统计分类，如下图所示:(数据生成于2004年4月)。既然Windows给了我们一张无奈的“蓝脸”，我们就应该刨根问底，尽快将造成系统崩溃的罪魁祸首绳之以法，让我们的系统尽快恢复。让我们来看看Windows想通过这张“蓝脸”告诉我们什么。如上图所示，这是一个显示所有参数的蓝屏图像。当然，我们遇到的蓝屏图像可能和它不一样，比如漏了一些信息，但大致都是一样的，所以我们就以它为例充分阐述一下。首先，让我们看一下图中用数字1标记的区域，这里列出了传递给KeBugCheckEx函数的stop代码和四个参数。本图中的stop码为0x000000D1，四个参数为四段16的十六进制数字，用括号中的逗号隔开；接下来我们来看看图中用数字2标注的区域，显示的是stop代码0x000000D1的英文解释；最后，我们来看看图中用数字3标注的区域。只有当且仅当停止代码的四个参数之一包含操作系统或设备驱动程序代码的地址时，才会显示该区域。显示的内容是，地址所在模块的基址，日期戳。在本例中，设备驱动程序的文件名是“myfault.sys”。这些信息如何帮助我们进行调试？如果出现上图中的3区，那就是最好的结果，因为你直接看到了罪魁祸首——“my fault . sys”文件。但是3区往往不会出现，所以我们需要在微软的在线帮助和支持中查找stop代码等信息或者使用我们的利器——WindBG进行手动分析。我推荐后者，因为同一个stop代码可能是各种驱动错误造成的，得到stop代码并不代表得到了问题文件的名称。另外，并不是所有的错误都能在微软的在线帮助和支持中搜索到，但WinDbg恰恰克服了这两个弱点，可以直接抓住罪魁祸首文件，让你斩首。WinDbg是免费软件，其微软官方下载地址指的是延伸阅读。具体项目是为Windows 32/64位版本安装调试工具。使用WinDbg分析崩溃时的内存转储文件的前提是你希望系统在崩溃时自动生成一个内存转储文件，如下:1，点击开始，然后点击运行。2.键入控件sysdm.cpl的副本代码，然后单击确定。您将打开系统属性，请切换到高级选项卡。结果如下图所示:3。在高级选项卡上，单击启动和恢复部分中的设置。这将打开启动和故障恢复对话框，如下图所示:4 .在调试信息列表中选择“小内存转储(64 KB)”或“核心内存转储”，这样系统崩溃时会自动生成相应的内存转储文件。如果您不希望蓝屏只是闪烁，而是希望在手动重新启动计算机之前清楚地看到它，请清除“系统故障”部分中自动重新启动(R)项目前的复选框。然后单击确定。5.在启动和恢复对话框中，单击确定。6.单击确定关闭系统属性对话框。7.在系统设置更改对话框中，如果要立即重新启动计算机，请单击是；如果希望以后重新启动计算机，请单击“否”。注意:Vista用户也应该这样做。对于原操作系统，以上设置为默认(禁止自动重启除外)。对于第4点写的调试信息列表的内容，给出如下解释:(以上三个转储文件大小依次增大，它们之间的比较不在本文讨论范围内。作者只建议设置为“小内存转储”或“核心内存转储”，一般错误“小内存转储”就够了。如果无法完全分析，请选择“核心内存转储”。对于数据的丰富性，也可以直接选择“核心内存转储”，但我强烈推荐完全内存转储。值得注意的是，为了确保在崩溃时自动生成内存转储文件，您可能还需要启用虚拟内存分页文件。特别是，当您选择记录核心内存转储时，您必须启用虚拟内存分页文件，并且因为核心内存转储文件的大小取决于操作系统和该机器上所有活动驱动程序已经分配的内核模式内存量，所以没有好的方法来预测核心内存转储的大小。下表只给出了这种情况下的参考虚拟内存大小设置值:除了页面文件占用的磁盘空间，内存转储文件(*。DMP)应该有足够的空闲空间来提取这个转储文件，否则它将“未生成”(实际上丢失)。设置好这些设置后，一旦你的系统出现蓝屏死机，系统会在上述设置中选择的对应内存转储文件类型下的对应目录下生成一个转储文件。你要做的就是马上拿出利器——启动WinDbg进行分析。笔者在这里用一个例子来详细说明，这个例子包含了WinDbg调试蓝屏时使用的一些命令。这些命令不再另行安排，阅读时请注意记忆。首先，您需要配置WinDbg将使用的调试符号文件的位置。什么是调试符号文件？符号文件是随着DLL文件或EXE文件的建立而生成的，这些文件为可执行文件和动态链接库(DLL)中包含的函数提供了空间。此外，符号文件还可以表示到故障点的函数调用路线图。当我们使用各种微软工具调试应用程序时，必须要有符号信息，这样才能正确分析问题的根源。那么我们如何设置调试符号文件的位置呢？我们可以从微软官方网站(都在WinDbg下载页面)下载完整的符号文件包，也可以使用微软符号服务器。我推荐后者，因为分析中使用的符号文件有限。使用后者可以使程序自动下载，既节省了时间，又保证了符号文件是最新的、正确的。点击WinDbg中的“文件”菜单，选择“符号文件路径……”，在打开对话框中输入复制代码，点击“确定”按钮。当然，另一个步骤是再次点击“文件”菜单，选择“保存工作区”来保存当前的设置。设置符号文件后，您可以分析内存转储文件。点击“文件”菜单，这次选择“打开崩溃转储…”，然后通过文件打开对话框打开生成的内存转储文件进行分析。在本例中，设置了核心内存转储类型，因此您应该导航到“%SystemRoot%”(即系统盘的Windows文件夹下)并打开内存。DMP档案。但是我已经转移到“E:\内存转储\内存。DMP”，所以在下面的图片中，你会看到这个地址。这时WinDbg会滚动显示一些信息，感觉有点悬，直到从微软符号文件服务器下载完分析这个崩溃文件所需的所有符号文件。在上图中，我们看到的是调试器命令窗口(符号文件已经加载并准备就绪)。我们先来看看底部的6区。这个小矩形条就是WinDbg的命令入口，分为两个区域，左边显示“0: KD >”。是提示区，右边空白区是命令输入区。当这个窗口刚刚打开，符号文件还没有下载/加载时，提示区什么都不会显示，命令输入区会显示“Debuggee not connected”。在符号加载之前，窗口中显示的最后一行“Followup: MachineOwner”将变为空闲。空闲时会出现类似上图的情况。为什么说类似？因为这个idle standby提示根据调试类型和电脑处理器的硬件配置不同，比如在这种情况下进行内核调试，所以显示“KD >”。(内核调试)，系统是多核处理器，所以在“KD >”之前还显示了一个“0:”表示当前位于编号为0的处理器中。执行一个命令后，如果该命令需要处理更多的任务(如"！Analyze -v”)，提示区在繁忙状态下会显示为“*BUSY*”。一旦在这种状态下显示，无论你输入什么命令，都不会立即执行，而是在空闲时延迟执行。如上图所示，打开的内存转储文件的物理路径会显示在图中的1区域；区域2显示了当前加载的符号文件的位置，在这种情况下表示它是从微软服务器下载的；区域3***有三行，显示系统信息。第一行表示系统是Windows XP，内核版本是2600(SP3)，有两个多处理器(32位)。第二行表示系统类型为NT系统和客户端系统，第三行表示系统的详细版本标识。4***区有两条线路。第一行表示内存转储文件生成的时间，即系统崩溃的具体时间。在本例中(这是去年65438+2月获得的一个崩溃转储文件，现在用作本例的说明)，是周六(星期六)，65438+2月27日(十二月)，22: 56: 3655。区域5是一个关键错误信息，它的第一行仅在加载符号文件时显示。在这种情况下，它告诉我们“对于BaseTDI。SYS文件，该模块已加载，但无法为其加载符号文件。如果之前配置了正确的符号文件路径，它会告诉我们BaseTDI。SYS不是微软的文件，而是第三方的驱动文件，这很可能是错误的原因，值得注意，但需要进一步分析。5区的第二行是WinDbg自动分析的结果，告诉我们崩溃的原因(很可能是由:)很可能是HookUrl.sys文件。一般情况下，这是错误的罪魁祸首，但也有很多例外。最典型的就是在这里显示一个微软自己的文件。你要注意了。为了避免滥杀无辜，最好能进一步分析，看看坠机最后时刻涉及到哪些模块，这样才能保证审判正确！用于进一步分析的命令可以从“！分析-v”开始。我们可以在命令输入区手动输入命令！Analyze -v复制代码，或者点击上图7区所示位置的蓝色命令。之后提示区会显示为“*BUSY*”，WinDbg会分析一段时间，直到显示结果，再次转为空闲状态。让我们来解释一下“的实现！“analyze -v”后显示的各种结果:自动分析后，WinDbg可能会在上图1区域显示的第一行显示Bug检查解释，第二行给出详细解释。从图中的信息可以看出，这个错误的例子是由“在队列工作项完成之前卸载了驱动程序”引起的。这个“driver _ unloaded _ without _ canceling _ pending _ operations”应该是蓝屏上面显示的错误描述，下面的参数1~4是蓝屏显示时stop代码后面的四个参数。图中2区显示的BUGCHECK_STR是WinDbg中的分类BUGCHECK之一，这里是0xCE，也是stop代码的分类缩写。我们可以在命令输入区复制代码命令，得到停止代码及其参数，与1区和上图蓝屏的信息一致。在这个例子中，可以获得以下结果:0:KD & gt；。bug check Bugcheck code 000000 ce arguments bacb0a4e 000000008 BAC B0 a 4 e 00000000我们可以通过在bug check code值前加“0x”得到蓝屏上的信息“* * * stop:0x 0000000 ce(BAC B0 a 4 e，0000008，BAC B0 a 4 e，000000”。当然，如果你想知道更多关于这个错误的信息，你可以在微软在线帮助和支持网站上搜索字符串“0x000000CE ”,然后你可以使用上图中区域2中的BUGCHECK_STR值“0xCE”来执行hh bug check 0xCE copy code命令，并点击打开的窗口左栏右下角的“Display”按钮。如果你想在WinDbg中显示一个停止代码或者错误检查类的详细描述(以这个错误为例)，输入命令！分析-显示0x000000CE复制代码或！分析-显示000000CE复制代码，也可以！分析-显示0xCE复制代码。3区显示的是二审判决的重要信息——线程栈信息。请特别注意红框中的部分，第一行是“警告:帧IP不在任何已知模块中。以下帧可能是错误的。表示“警告:堆栈帧IP(InstructionPtr，仅限x86处理器，用于确定帧堆栈回撤的指令指针)在任何已知模块中都不存在，后续帧可能有错误”。对这一含义的解释超出了本文的范围。作者只告诉你这一行下面一行右边的模块是系统蓝屏崩溃时最后使用的模块(除了Windows内核最后调用KeBugCheckEx牺牲自己，也就是警告文字上面的三行)，经常导致崩溃！让我们仔细看看。如果你知道堆栈的数据结构或者Windows的内存分配机制，你应该知道当Windows为线程分配额外的内存时，它是从高地指向低地址的。也就是说我们要从下往上看蓝色区域3的堆栈信息，就是系统崩溃前一刻内核态函数的调用和转移。例如，在这种情况下，系统内核执行器(nt！也就是Ntoskrnl.exe)通过函数IopfCallDriver调用BaseTDI，然后BaseTDI调用Hooke rurl . sys(unloaded _这个词的意思是卸载)，然后屏幕就蓝屏了。然后在这最后的时刻，涉及到了两个非Windows内核模块——base TDI和HookUrl.sys。之所以这样“二审判决”是为了避免一种情况——万一HookUrl.sys和BaseTDI是两家公司或者两个软件的模块，最后加载的HookUrl.sys是没有问题的。该错误是因为BaseTDI向HookUrl.sys传递了错误的格式或损坏或非法的参数信息，而HookUrl.sys接受了这些无效数据，导致了崩溃。如果不看线程栈，我们就按照前面的“可能原因by: hook URL”来判断。sys”，而我们很可能会滥杀无辜，让凶手逍遥法外。只有通过线程栈才能发现另一个驱动BaseTDI也参与其中。(在应用崩溃而不导致系统崩溃的调试分析中，“可能原因:”在WinDbg的自动分析结果中几乎总是错误的，因为它处于用户模式。在这种情况下，使用！Thread命令不能显示任何信息，因为这个命令只对内核崩溃调试有效。但是，kb命令不能显示任何有用的信息。只有用“~*kb”详细显示所有线程栈，才能找到问题的根源，有时还需要配合其他命令，本文不讨论。当然，如果你精通的话，你觉得没必要用”！Analyze -v”命令可以直接使用！线程复制代码或kb复制代码命令显示核心线程堆栈信息，用于二审判断。现在，嫌疑人的目标是BaseTDI和HookUrl.sys，现在，我们来看看他们是什么，是哪个公司，是哪个程序模块。(从他们之前不能从微软服务器自动为他们加载符号文件就可以知道，肯定都是第三方驱动。)使用命令lm kv m BaseTDI*复制代码(使用lm (list module)命令、内核k选项、详细v选项和参数m，配合包含通配符*的字符串Basetdi，列出当时内核模式下加载的包含字符Basetdi的所有驱动文件详细信息。使用通配符代替完整的文件名后缀可以避免信息的限制，这样我们可能会找到多个相关的模块来提供更多的诊断线索。)我们得到以下结果:从图中的蓝框可以看到，只有一个名为BaseTDI的文件。SYS，这个文件的路径位于System32\Drivers下。它属于一个名为“瑞星PFW(产品名:瑞星PFW =个人防火墙)”的程序组件，软件公司的注册商标为“LegalTrademarks: RISING”。如果不知道文档的英文描述信息，可以百度一下。当然，作者没有突出显示的信息(如文件时间戳、版本、校验和等。)也很有用。例如，如果您查看文件版本，您可能会发现软件已经提供了一个更新的文件来解决这个问题。同样，我们使用lm kv m hookurl*来复制代码，以在当时的内核模式下显示包含hookurl的文件及其详细信息。结果如下:图是一个不理想的结果，因为如高亮部分所示，这个模块没有加载，所以没有记录任何信息。但是我们有百度，不用担心，你看看百度就知道了。搜了一下HookUrl.sys，发现这也是瑞星个人防火墙的一个文件。这个案例其实就是著名的“瑞星个人防火墙升级到2009版时触发蓝屏”。可以通过关键词“瑞星防火墙2009升级导致蓝屏”搜索百度。截至目前，瑞星官方并未对此事件给出任何官方回复。虽然不是每个用户都有这个问题，但是很多用户都反映过，瑞。