☰

如何找到此 BSOD 的来源？如何修复它？

tag-icon • tag-icon windows-7 64-bit bsod minidumps
如何找到此 BSOD 的来源？如何修复它？

我偶尔（总是在最不方便的时刻...）在我的 Windows 7 台式电脑上收到此 BSOD：

  Problem signature:
  Problem Event Name:   BlueScreen
  OS Version:   6.1.7601.2.1.0.256.1
  Locale ID:    1033

  Additional information about the problem:
  BCCode:   124
  BCP1: 0000000000000000
  BCP2: FFFFFA8007BBB028
  BCP3: 00000000B2000040
  BCP4: 0000000000000800
  OS Version:   6_1_7601
  Service Pack: 1_0
  Product:  256_1

  Files that help describe the problem:
  C:\Windows\Minidump\010812-16578-01.dmp
  C:\Users\al\AppData\Local\Temp\WER-37500-0.sysdata.xml

尝试查找有关此问题的更多信息似乎是徒劳的，因为该文件C:\Users\al\AppData\Local\Temp\WER-37500-0.sysdata.xml不存在（文件夹存在，但不存在以“WER”开头的任何文件），尝试分析小型转储文件会产生以下结果：

Bug Check Code: 0x00000124
Parameter 1:    00000000`00000000
Parameter 2:    fffffa80`07bbb028
Parameter 3:    00000000`b2000040
Parameter 4:    00000000`00000800
Causing driver: hal.dll
Address:    hal.dll+12a3b
Processor:  x64
Crash address:  ntoskrnl.exe+7cc40
CPU count:  4
Major ver:  15
Minor ver:  7601
Dump size:  283,576

和：

Filename:       ntoskrnl.exe
Addr. in Stack: ntoskrnl.exe+18d513
From addr:      fffff800`02a18000
To addr:        fffff800`03001000
Size:           0x005e9000
Timestamp:      0x4e02aaa3
Time string:    6/22/2011 9:53:23 PM
Product name:   Microsoft® Windows® Operating System
File desc:      NT Kernel & System
File ver:       6.1.7601.17640 (win7sp1_gdr.110622-1506)
Company:        Microsoft Corporation
Full path:      C:\Windows\system32\ntoskrnl.exe

嗯，hal.dll它们ntoskrnl.exe是操作系统的一部分，而且我似乎无法采取任何措施来升级这些“驱动程序”。

我知道硬件是完美的（包括 BIOS 中的 RAM 电压等），因为这个完全相同的系统与Ubuntu 8和Ubuntu 10（三重启动配置）完美配合。问题肯定出在系统软件上，但我如何找出问题所在？

答案1

  1. 安装Windows 调试工具。
  2. 安装后，从开始菜单打开 WinDbg。
  3. 单击文件 > 符号文件路径并输入 （将 C:\SymbolCache 替换为您选择的路径）SRVC:\SymbolCachehttp://msdl.microsoft.com/download/symbols
  4. 单击文件 > 打开 Crashdump，然后打开 %SystemRoot%（通常为 C:\WINDOWS 或 C:\WINNT）中的 memory.dmp 文件，或者，如果您已禁用完整转储，则打开 %SystemRoot%\Minidump 中的最新文件。
  5. 有问题的驱动程序将列在下面，类似于： Probably caused by : usbhub.sys ( usbhub!UsbhTrapFatalTimeout_x9f+28 )，但您可以单击!analyze -v链接以获取详细的堆栈跟踪。

答案2

一个更简单的方法是使用蓝屏视图。如果您查看“堆栈中的地址”列，您可以看到有问题的调用最初来自哪里。这是此列中包含条目的最后一行。

通过获取驱动程序文件名，您可以回溯其所属的供应商/应用程序/设备，从而很有可能找到罪魁祸首。

相关内容