web-dev-qa-db-ja.com

このBSODのソースを見つける方法は？それを修正する方法は？

私は時々（常に最も都合の悪い瞬間に...）Windows7デスクトップPCでこの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はOSの一部であり、これらの「ドライバー」をアップグレードするために私ができることは何もないようです。

この同じ正確なシステムがUbuntu 8およびUbuntu 10（トリプルブート構成）で完全に機能するため、ハードウェアが完全であることを知っています（RAM BIOSの電圧などを含む）。問題は間違いなくシステムソフトウェアにありますが、どうすればそれが何であるかを知ることができますか？

windows-764-bitbsodminidumps
8
Eternal Learner
  1. Debugging Tools for Windows をインストールします。
  2. インストール後、スタートメニューからWinDbgを開きます。
  3. [ファイル]> [シンボルファイルパス]をクリックして、_SRVC:\SymbolCachehttp://msdl.Microsoft.com/download/symbols_と入力します（C：\ SymbolCacheを任意のパスに置き換えます）
  4. [ファイル]> [クラッシュダンプを開く]をクリックし、％SystemRoot％（通常はC：\ WINDOWSまたはC：\ WINNT）のmemory.dmpファイルを開きますOR％SystemRoot％\ Minidumpの最新ファイルフルダンプを無効にします。
  5. 問題のあるドライバーは以下のように表示されます。これはProbably caused by : usbhub.sys ( usbhub!UsbhTrapFatalTimeout_x9f+28 )と似ていますが、_!analyze -v_リンクをクリックして詳細なスタックトレースを取得できます。
4
kinokijuf

はるかに簡単な方法は、 BlueScreenView を使用することです。 「スタック内のアドレス」列を調べると、問題のある呼び出しが最初にどこから来たかがわかります。これは、この列にエントリがある最後の行です。

ドライバーファイル名を取得すると、それが属するベンダー/アプリケーション/デバイスを逆追跡できるため、高い確率で原因を特定できます。

2
Robert