ブルースクリーンが突然出て何を見ればよいか分からず不安になっている方へ寄り添って優しく案内します。
この記事を読むとイベントビューアとミニダンプの基本的な見方が身につき原因の絞り込みと初期対処まで自信を持って進められるようになります。
| 項目 | 内容 |
|---|---|
| 独自コンテンツ1 | 実体験に基づく手順でイベントログから原因候補を効率よく絞り込めます。 |
| 独自コンテンツ2 | ミニダンプ解析の具体コマンドとよくあるパターンの見分け方を分かりやすく解説します。 |
| 独自コンテンツ3 | ドライバやハード故障の見抜き方と現場で使える応急対処を紹介します。 |
難しそうに見えるログ解析を実際の手順で丁寧に案内するので落ち着いて一緒に進めていきましょう。
Windowsマニア焦らなくて大丈夫です一歩ずつログを確認すれば原因は必ず見つかります困ったときには何度でも読み返してください。
Windowsでイベントビューアを使ってブルースクリーンのログを確認する方法
ブルースクリーンで慌てないでください。イベントビューアは発生した時間と前後のシステムログを確認できるので原因の手がかりにとても役立ちます。初めてでも順を追えば必要な情報が見つかります。
やることはシンプルです。Windowsログのシステムを開きレベルをエラーとクリティカルに絞り該当時刻のエントリを探します。見つけたイベントのGeneralとDetailsからBugCheckコードや関係するドライバ名を抜き出します。
抜き出した情報で検索すると対応策が見えてきます。minidumpがある場合はWinDbgで解析すると確度が上がるので併用すると良いです。
Windowsでイベントビューアから該当エントリを見つける方法
イベントビューアを開いたら左ペインでWindowsログ→システムを選びます。エントリは時系列なので問題発生時刻付近を中心に探すと見つかりやすいです。
フィルターでレベルをエラーとクリティカルに絞るとノイズが減ります。ソースにBugCheckやMicrosoft-Windows-WER-SystemErrorReportingなどがあれば特に注目してください。
スタートメニューでeventvwrを起動してWindowsログのシステムを開く
スタートメニューを開き「eventvwr」と入力してEnterを押します。管理者権限が必要な場合は右クリックで管理者として実行してください。
左のツリーメニューでWindowsログを展開しシステムをクリックします。ここにブルースクリーンに関連する情報が集まっています。
右ペインで日時順に並んでいるので問題発生時刻付近のエントリを探します。近い時間のイベントを順に確認してください。
現在のログをフィルターしてエラーとクリティカルだけに絞る操作
システムログを選んだ状態で右側の操作パネルから現在のログのフィルターをクリックします。
フィルター画面でレベルのチェックボックスからエラーとクリティカルだけにチェックを入れてOKを押します。
発生時刻が分かっている場合は期間指定で範囲を狭めるとさらに見つけやすくなります。
該当イベントのGeneralとDetailsからBugCheckコードやドライバ名を抜き出す手順
見つけたエントリをダブルクリックして詳細ウィンドウを開きます。Generalタブに簡単な説明やエラー名が表示されることがあります。
DetailsタブのXMLビューに切り替えるとキー名やパラメータが正確に見えます。BugCheckCodeやParameterXなどの値をコピーしてください。
ログにImageNameやCausedByDriverのようなドライバ名があれば控えてください。見つからない場合はminidumpをWinDbgで解析するとドライバ名が判明することが多いです。
WindowsでミニダンプをWindbgで解析してブルースクリーンの原因を突き止める方法
ミニダンプをWindbgで解析すると、ブルースクリーンの原因をコードレベルで絞り込めます。まずはダンプを開いてシンボルを正しく読み込み、自動解析の結果をチェックする流れが基本です。
- ダンプをWindbgで開く。
- .symfixでシンボルサーバー設定を行い.reloadで読み直す。
- !analyze -vで自動解析を確認する。
自動解析で出る候補をメモしつつ、スタックやモジュール情報で疑わしいドライバを突き止めます。経験上は自動結果を鵜呑みにせず、スタックを自分の目で追うと原因が見つかりやすいです。
Windowsマニア初めての解析は戸惑うかもしれませんが、落ち着いて結果を一つずつ確認すれば着実に原因に近づけます。じっくり取り組んでいきましょう。
Windbgでダンプを開いて自動解析から原因候補を得る方法
Windbgでダンプを開いたらまず.symfixを実行してマイクロソフトのシンボルサーバーを設定します。続けて.reloadを実行してシンボルを読み込み、自動解析コマンドの!analyze -vを実行してください。
自動解析は手掛かりを素早く得るのに便利ですが、出力の意味を押さえておくことが重要です。特にProbable原因やスタックの上位に出るモジュール名はメモしておくと後で役に立ちます。
Windbgでminidumpを開く手順と.symfix/.reloadでシンボルを整える操作
File→Open Crash Dumpでminidump(.dmp)を開いてください。
コマンドウィンドウで.symfixを打ちシンボルサーバーの設定を追加します。
.reload /fを実行してシンボルを強制再読み込みしてください。
!analyze -vの出力からBUGCHECK情報を読み取り原因候補をメモする方法
- BugCheckCodeとBugCheckStringを控えることでエラー種別が分かります。
- パラメータ(Arguments)はハードウェアやドライバ問題の手掛かりになります。
- Probably caused byやMODULE_NAMEは疑わしいドライバ候補です。
- STACK_TEXTはスタックの流れを追うために重要です。
スタックトレースやモジュール情報で疑わしいドライバを特定する方法
スタックトレースとモジュール情報を突き合わせると、原因ドライバがかなり絞れます。まずはスタック上位に出るモジュール名を確認し、そのモジュールのバージョンやパスを調べてください。
疑わしいドライバが見つかったら、ドライバの更新履歴やデジタル署名をチェックすると良いです。必要ならドライバを無効にして再現性を確認してください。
lmvmでモジュール情報を確認しkやkvでスタックを辿ってドライバ名を特定する手順
lmvm モジュール名でモジュールのベースアドレスやバージョンを確認します。
kやkvでスタックフレームを表示し、アドレスがどのモジュールに属するかを確認します。
アドレスが示すモジュール名とlmvmの結果を照合して疑わしいドライバを特定してください。
MacでBootCampや外付けドライブからWindowsのクラッシュログを取り出す方法
MacでBootCampや外付けドライブに入ったWindowsのクラッシュログを取り出すときは、慌てずにまずコピーを取ることが肝心です。ここでは安全にファイルを持ち出す方法をやさしく案内します。
主に取り出すのはWindows\MinidumpとWindows\System32\winevt\Logsのファイルです。Finderで読み取り可能ならそのままコピーするのが一番簡単で、書き換えはしないでください。
- Finderでボリュームを開いてコピーする。手軽で安全です。
- 読み書きが必要なら第三者製NTFSドライバーを使う（例ParagonやTuxera）。
- Finderで見えないときはWindowsで外付けをマウントしてから作業する。
Mac上でWindowsボリュームからminidumpとイベントログをコピーする方法
FinderでWindowsボリュームを扱う基本は、ボリュームをサイドバーの「場所」から選ぶことです。BootCampは通常そのまま表示されますが見えないときはFinderの環境設定で「外部ディスクを表示」を確認してください。
System32配下は隠しファイルになっていることが多いので、隠しファイル表示を有効にしてからWindows\MinidumpとWindows\System32\winevt\Logsを別フォルダへコピーしてください。元ファイルは移動せずコピーするのが安全です。
FinderでWindowsボリュームを開きWindows\MinidumpとWindows\System32\winevt\Logsを探してコピーする操作
Finderのサイドバーの「場所」からBootCampまたは外付けドライブを選択してください。
隠しファイルが見えない場合はCommand+Shift+.で表示を切り替えてください。
Windows\MinidumpとWindows\System32\winevt\LogsをMac側の安全なフォルダにコピーしてください。
実体験に基づく応用テクニックでWindowsのブルースクリーン原因を早く特定する方法
ブルースクリーンが出ると焦りますね、でも焦って再起動を繰り返すとログが上書きされて手がかりを失いやすいです。まずは落ち着いてダンプとイベントログを収集することが一番の近道です。
複数のダンプとイベントを突き合わせると再現に必要な操作や共通のモジュールが浮かび上がります。プログラマー目線のコツとしてはタイムスタンプのずれやドライバのビルド日時に注目することです。
- ダンプはC:\Windows\Minidumpから全部拾い、ファイル名とタイムスタンプをメモする。
- イベントビューアのSystemとApplicationをBugCheckやエラー系で絞り、該当時間帯を抽出する。
- WinDbgで!analyze -vを実行しMODULE_NAMEやSTACK_TEXTの共通項を探す。
- 疑わしいドライバは署名やビルド日で照合し、別PCや仮想環境で再現を試してみる。
Windowsマニア焦らず順番に進めれば必ず手がかりが見つかります、まずはログを集めてから一つずつ確認していきましょう。
複数のダンプとイベントを突き合わせて再現条件を絞る方法
複数のダンプとイベントを同時に見ると発生前後に繰り返し出るイベントを見つけやすいです。特にカーネル例外ではクラッシュ直前のドライバ呼び出しやI/Oエラーがヒントになります。
タイムウィンドウを揃えてログを並べ、同じモジュール名や同時間帯に発生する警告を突き合わせます。頻出するモジュールやその時刻帯に行われた更新や操作があれば再現条件を絞る手掛かりになります。
タイムスタンプとイベントIDを照合して共通のモジュールや操作を特定する手順
ダンプとイベントの時刻がUTCなのかローカルなのか確認し、同じ基準に揃える。
クラッシュ前後前後1分のイベントを抽出して同じイベントIDやモジュール名をリスト化する。
疑わしいモジュールをドライバのロールバックやセーフモードで切って再現を試し原因を絞る。
よくある質問
- イベントビューアでブルースクリーンに関するログはどこを見ればよいですか
イベントビューアを開き、Windowsログ→システムをチェックしてください。レベルがエラーの行を探し、ソースにBugCheckやMicrosoft-Windows-WER-SystemErrorReportingがあるイベントを確認してください。詳細にあるバグチェックコードやドライバー名が最初の手がかりになります。
- ミニダンプファイルはどこにあり、どうやって使うのですか
通常はC:\Windows\Minidumpに保存されています。自動生成されないときはシステムの詳細設定で小さなメモリダンプを有効にしてください。取得した.dmpはWinDbgやWhoCrashedで読み込むと原因の絞り込みがしやすくなります。
- イベントにドライバー名が表示されないときはどうすればよいですか
ドライバー名が出ない場合は、クラッシュ直前のログや関連するイベントを時刻で突き合わせてください。必要ならWinDbgでシンボルを設定して解析するとモジュール名が出ることがあります。メモリやディスクの簡易診断も並行して行うと安心です。
- ログ解析で優先して確認すべきポイントは何ですか
まずはバグチェックコードと発生時刻を確認してください。次に直前に動いていたドライバーや最近の更新履歴をチェックして原因を絞ります。最後にハードウェア検査や再現テストで確かめると結論が安定します。
- 初心者がやりがちな間違いと安全な調べ方は
イベントの一行だけで結論を出すのは避けてください。ログは手がかりなので、ドライバーのロールバックや安全モードでの再現確認を行って確かめてください。解析は管理者権限で行い、元のダンプは必ずバックアップしてください。
まとめ
このまとめではブルースクリーンの原因を絞るための要点をやさしく整理します。まずはイベントビューアの「システム」ログや「アプリケーション」ログでエラーやイベントIDを探し、BugCheckやKernel-Powerといった記録がないか確認してください。合わせてC:\Windows\Minidumpにあるミニダンプ（小さなメモリダンプ）を集めると解析の材料が揃います。
解析にはWinDbg（Microsoft公式のデバッガー、シンボルファイルがあると精度が上がります）やBlueScreenView（GUIで見やすい）がおすすめです。ダンプを開くとドライバ名やBugCheckコードが分かりますが、ntoskrnl.exeなどのOS要素は本来の原因ではなく結果であることが多い点に注意してください。
対処は疑わしいドライバの更新、BIOSやチップセットドライバの更新、メモリ検査（memtest86）やディスクチェックでハードの問題を除外する順が手堅いです。自力で判断が難しい場合はミニダンプと該当時刻のログをまとめて相談すると原因特定が早く進みやすくなります。