こんにちは、パソガジェなびのkeitoです。
Windows 11で突然アプリが落ちたり、勝手に再起動したりすると、「エラーログを見れば原因が分かるのかな？」と気になりますよね。イベントビューアーを開いてみたものの、赤いエラーや黄色い警告が大量に並び、どれを確認すればいいのか迷ってしまう方も多いかなと思います。
ここで大切なのは、エラーログに表示された警告を片っ端から直そうとしないことです。Windows 11では正常に使えているパソコンでも警告やエラーが記録されることがあります。実際に不具合が発生した時刻とログを照らし合わせ、同じ症状と一緒に繰り返し発生しているイベントを探すのが原因特定の近道ですよ。
この記事では、Windows11のエラーログを見る基本操作から、Kernel-Power 41、信頼性モニター、Windows11のトラブルシューティング、DISM・SFC、さらにWindows11 dumpの確認まで順番に解説します。難しそうに見えるログも、見るポイントを絞ればかなり整理できます。
ポイント
- Windows11のエラーログを確認する方法
- イベントIDと発生時刻から原因を絞る考え方
- トラブルシューティングができない時の修復方法
- Windows11 dumpを使ったクラッシュ原因の調べ方
本記事にはプロモーションが含まれています
Windows11のエラーログを確認して原因を調べる
Windows 11の不具合を調べる時は、最初から設定変更や初期化をするのではなく、まず「いつ」「どの機能で」「どんなエラーが起きたのか」を確認します。ここではイベントビューアーを中心に、見るべきログと原因を絞り込む基本的な流れを整理していきます。
イベントビューアーを開く方法
Windows11のエラーログを見る時に中心となるのがイベントビューアーです。スタートボタンを右クリックしてイベントビューアーを選ぶ方法のほか、「Windows＋R」で「ファイル名を指定して実行」を開き、eventvwr.mscと入力して起動できます。
イベントビューアーを開いたら、左側のメニューから「Windows ログ」を展開します。ここには「Application」「Security」「Setup」「System」などがありますが、パソコンのフリーズ、突然の再起動、ドライバー異常などを調べたい時は、まずシステムを見るのがおすすめです。アプリだけが落ちる場合は「アプリケーション」を確認すると効率的ですよ。
イベントビューアーには膨大な履歴が保存されているため、赤いマークを見つけたからといって、そのイベントが現在の不具合の原因とは限りません。症状が発生した時刻を先にメモしてからログを見るだけでも、関係のない記録をかなり除外できます。
◆keitoのワンポイントアドバイス
イベントビューアーを開くとエラーの多さに驚くかもしれませんが、エラーの数そのものより「不具合が起きた時間に何が記録されたか」を見るのがポイントですよ。
システムとアプリログの違い
「システム」ログには、Windows本体、デバイスドライバー、サービス、ストレージ、電源管理など、OS全体の動作に関係する情報が記録されます。突然再起動した、USB機器を認識しなくなった、ネットワークが切れたといった問題では、こちらを優先して確認します。
一方、「アプリケーション」ログには、インストールしたソフトやWindows上で動くプログラムの異常が記録されます。特定のアプリだけが起動直後に閉じる場合や、作業中に突然終了する場合は、「Application Error」や「.NET Runtime」などの記録がないか確認してみてください。
Windows Updateの失敗を詳しく調べたい場合は「セットアップ」ログも候補になります。更新エラーはネットワークだけでなく、システムファイルや更新データの破損でも発生します。更新時のエラーコードが分かっている場合は、Windows11更新エラーコード別の原因と修復手順もあわせて確認してみてください。
| ログ | 主に確認できる内容 | 向いている症状 |
|---|---|---|
| システム | Windows、ドライバー、サービス、電源 | 再起動、フリーズ、機器の異常 |
| アプリケーション | アプリやプログラムの動作 | アプリが落ちる、起動しない |
| セットアップ | Windowsの更新や構成 | 更新失敗、アップグレード異常 |
| セキュリティ | ログオンや監査情報 | サインインやアクセスの確認 |
重大とエラーを絞り込む方法
大量のログを一つずつ読む必要はありません。「システム」など確認したいログを選択した状態で、右側の「現在のログをフィルター」を開きます。まずはイベントレベルの重大とエラーにチェックを入れ、不具合が起きた時間帯まで絞り込んでみましょう。
ただし、黄色い「警告」を完全に無視していいわけではありません。例えば、エラーが発生する数分前から同じドライバーの警告が何度も記録され、その直後にシステムが停止している場合、警告が原因を探る重要な手掛かりになることがあります。まず重大とエラーを確認し、その前後にある警告まで広げて見る方法が分かりやすいです。
一度だけ発生したエラーより、同じ症状と同時に何度も再現するエラーを優先してください。正常動作中にも発生しているログなら、今回のトラブルとは無関係な可能性があります。「赤い表示＝故障」と決めつけないことがWindows11のエラーログを見るうえでかなり大切ですよ。
注意：イベントビューアーにはWindowsが内部で処理できたエラーも記録されます。重大やエラーが存在するだけで、SSDやメモリ、マザーボードなどの故障と断定することはできません。
イベントIDとソースの確認
原因候補になりそうなログを見つけたら、次に確認したいのがイベントIDとソースです。イベントIDは何が起きたかを分類する番号で、ソースはそのイベントを記録したWindowsの機能やドライバーを示します。この2つをセットで見ると、調査範囲をかなり狭められます。
例えば「Kernel-Power」「Disk」「WHEA-Logger」など、ソース名を見るだけでも電源、ストレージ、ハードウェア周辺のどこから記録されたのか見当をつけられます。ただし、イベントIDだけで原因となった部品まで確定できるわけではありません。同じイベントでも複数の原因から発生することがあります。
より詳しく確認したい時はイベントのプロパティを開き、「詳細」タブも見てみましょう。XML表示にはエラーコードや各種パラメーターが含まれている場合があります。内容が難しい時は、まず「ソース」「イベントID」「発生日時」「全般に表示された説明」を控えるだけでも十分です。
メーカーやサポート窓口へ相談する場合も、症状だけでなく「発生日時・イベントID・ソース・表示されたエラーコード」を伝えると状況を共有しやすくなります。
発生時刻と症状を照合する
Windows11のエラーログで最も重要なのが、ログの時刻と実際の症状を照らし合わせることです。例えば午後3時20分ごろに画面が固まったなら、その時刻だけでなく数分前まで遡り、直前にどんな警告やエラーが記録されていたか確認します。
特に役立つのが「直前に何をしていたか」という情報です。Windows Updateを実行した、グラフィックドライバーを更新した、USB機器を接続した、ゲームを起動した、スリープから復帰したなど、環境の変化をログと組み合わせます。同じ操作をした時だけ同じエラーが発生するなら、かなり有力な手掛かりになります。
反対に、エラーは記録されているものの症状とは時間が離れている、正常な時にも同じイベントが出ているという場合は、優先度を下げて構いません。あなたがログを見る時も「エラーがあるか」ではなく、症状と一緒に再現するかという視点で見てみてください。
Kernel-Power 41の見方
突然再起動したパソコンでよく見つかるのが、ソース「Kernel-Power」、イベントID「41」です。Kernel-Power 41は「Windowsが前回正常にシャットダウンされなかった」ことを示す記録であり、イベント41そのものが故障原因を示しているわけではありません。
ブルースクリーン、完全なフリーズ、停電、電源ユニットの問題、強制終了などでも記録される可能性があります。詳細のXMLにある「BugcheckCode」が0以外なら、ブルースクリーンなどのバグチェック情報が残っている可能性があります。「PowerButtonTimestamp」などの値も、電源ボタン操作を含めて状況を切り分ける手掛かりになります。
Kernel-Power 41を見つけた時は、イベント41だけを見るのではなく、その直前のログを確認しましょう。WHEA-Logger、ストレージ、ディスプレイドライバーなどのエラーが先に発生していないか確認します。Windows自体が起動しなくなっている場合は、Windows11が起動しない時の原因切り分けと対策も参考にしてください。
Kernel-Power 41＝電源ユニット故障ではありません。電源断の結果として記録されるイベントなので、ログだけで部品交換を判断しないようにしてください。
エラーの原因を特定して適切に対処する
ログから原因候補を絞れたら、次は実際の対処へ進みます。Windows 11には自動診断機能だけでなく、信頼性モニター、DISM、SFC、クラッシュダンプなど複数の方法があります。簡単でリスクの低い確認から順番に進めるのがおすすめですよ。
信頼性モニターで履歴を確認
イベントビューアーが細かなログを見る道具なら、信頼性モニターはパソコンの状態を日付ごとに確認するのに向いています。スタートメニューで「信頼性」と検索して「信頼性履歴の表示」を開くか、「Windows＋R」を押してperfmon /relを実行すると起動できます。
画面にはアプリケーション障害、Windows障害、その他の障害、警告、情報などが時系列で表示されます。例えばドライバーやアプリをインストールした直後から赤いエラーが増えているなら、その変更がトラブルのきっかけだった可能性を考えられます。イベントビューアーより視覚的なので、初心者の方にも使いやすいですよ。
私は、原因がまったく見えないトラブルでは「信頼性モニターで異常が始まった日を確認→その日の変更内容を調べる→イベントビューアーで同じ時刻を詳しく見る」という順番をおすすめします。いきなり数千件のログを読むより、はるかに原因を追いやすくなります。
◆keitoのワンポイントアドバイス
「昨日から急に調子が悪い」という時こそ信頼性モニターが便利です。更新やアプリのインストールと不具合が始まった日が重なっていないか見てみてください。
トラブルシューティングを実行
原因の分野が分かったら、Windows11のトラブルシューティング機能も試してみましょう。「設定」→「システム」→「トラブルシューティング」から関連する診断機能へ進めます。ネットワーク、オーディオ、Bluetooth、プリンター、Windows Updateなど、症状に合った項目を選ぶのがポイントです。
現在のWindows 11では、従来のMSDTを基盤としたトラブルシューティング機能から、「問い合わせ（Get Help）」を使った診断へ移行が進んでいます。そのため、Windows 11のバージョンや対象機能によって、以前の記事や画面と手順が異なる場合があります。設定画面から実行した際に「問い合わせ」が開いても異常ではありません。
トラブルシューティングは便利ですが、すべての問題を自動修復できるわけではありません。特定のドライバーが繰り返し落ちている、システムファイルが破損している、Windows Update自体が正常に動かないといった場合は、次のDISMやSFCによる修復へ進みます。Windowsの仕様は更新されるため、画面構成などの正確な情報はMicrosoft公式サイトも確認してください。
実行できない時はDISMとSFC
Windows11のトラブルシューティングができない、設定画面が正常に動かない、Windows Updateが繰り返し失敗する場合は、システムファイルの破損も疑います。この場合は管理者権限のターミナルやコマンドプロンプトを開き、まずDISMでWindowsのコンポーネントストアを修復します。
基本的な流れは、最初にDISM /Online /Cleanup-Image /RestoreHealthを実行し、正常に完了したらsfc /scannowを実行します。SFCはWindowsの保護されたシステムファイルを検査し、破損が見つかった場合は正常なファイルへの置き換えを試みます。具体的な操作はWindows11でSFCとDISMを使ってシステムを修復する方法でも詳しく解説しています。
Windows Update側が壊れていてDISMが修復データを取得できない場合は、Windows 11のISOやインストールメディアを修復ソースとして指定する方法もあります。ただし、エディションやビルドに合わないイメージを使うと正常に修復できない可能性があります。重要なデータをバックアップしたうえで実施し、自信がない場合はメーカーや専門業者へ相談してください。
基本的な修復順序
DISM /Online /Cleanup-Image /RestoreHealth
正常に完了したら、続けて以下を実行します。
sfc /scannow
DISMやSFCの実行中は、できるだけ電源を切らないようにしてください。ストレージ自体に異常が疑われる場合や重要なデータが保存されている場合は、修復操作より先にバックアップを優先しましょう。
Windows11 dumpを解析する
ブルースクリーンが発生している場合は、Windows11のエラーログだけでなくdumpファイルも重要な手掛かりになります。一般的な最小メモリダンプはC:\Windows\Minidump\、カーネルメモリダンプなどは通常C:\Windows\MEMORY.DMPに保存されます。アプリ単体のクラッシュでは、ユーザー領域のCrashDumpsフォルダにダンプが作成される場合もあります。
ダンプは普通のテキストファイルではないため、内容を確認するにはMicrosoftのデバッガであるWinDbgなどを使用します。ダンプを開いたらシンボルを読み込み、!analyze -vを実行すると、Bug Check Code、クラッシュしたスレッド、スタック、関連するドライバーなどを調べられます。ただし、表示されたドライバー名が必ず根本原因とは限らない点には注意してください。
ブルースクリーンが出たのにdumpがない場合は、ダンプ設定やページファイル、保存先、ストレージの状態なども確認します。必要なページファイル容量はダンプ方式や搭載メモリなどによって変わるため、固定値だけを頼りに変更するのはおすすめしません。Windowsが起動できず回復環境から作業する場合は、Windows11のオプションの選択から修復する方法も参考にしてください。
| ダンプの種類 | 主な保存場所 | 向いている用途 |
|---|---|---|
| 最小メモリダンプ | C:\Windows\Minidump\ | BSODの履歴比較や原因ドライバーの調査 |
| カーネル・メモリダンプ | C:\Windows\MEMORY.DMP | カーネルやドライバーを詳しく解析 |
| ユーザーモードダンプ | ユーザー領域のCrashDumps | 特定アプリのクラッシュ解析 |
WinDbgの解析結果は専門的です。「MODULE_NAME」に表示された名前だけで原因を断定せず、イベントログ、発生時刻、直前の操作、複数回のdumpで共通する傾向まで確認するのがおすすめです。
Windows11エラーログに関するよくある質問（FAQ）
Q1. Windows11のエラーログに赤いエラーがあれば故障ですか？
A. いいえ。赤いエラーが記録されているだけでハードウェア故障とは判断できません。Windowsが自動的に復旧した処理でもエラーが残ることがあります。不具合が発生した時刻と一致しているか、同じ症状と一緒に繰り返しているかを確認してください。
Q2. Kernel-Power 41があれば電源ユニットの故障ですか？
A. Kernel-Power 41だけでは電源ユニットの故障とは判断できません。正常なシャットダウンが行われなかった結果として記録されるため、ブルースクリーン、フリーズ、停電、強制終了などでも発生します。イベント41の直前に記録されたログまで確認しましょう。
Q3. Windows11のトラブルシューティングができない時はどうすればいいですか？
A. まず再起動やWindows Updateを確認し、それでも実行できない場合はDISMとSFCでシステムファイルを修復します。設定アプリ自体が正常に開かない場合は、回復環境やセーフモードから原因を切り分ける方法もあります。
Q4. Windows11 dumpが作成されないのはなぜですか？
A. ダンプの設定、ページファイル、保存先、空き容量、ストレージの異常など複数の原因が考えられます。「起動と回復」のダンプ設定とページファイルの状態を確認し、イベントビューアーにダンプ作成失敗の記録がないかも確認してください。
Q5. イベントビューアーでは何を一番最初に確認すればいいですか？
A. 最初に確認したいのは不具合が発生した時刻です。その時間帯の「システム」または「アプリケーション」ログを開き、重大・エラーを中心に確認します。その後、イベントID、ソース、直前の警告という順番で広げていくと原因を絞りやすいですよ。
まとめ：エラーログは症状とセットで判断しよう
Windows11のエラーログは、パソコンで何が起きたのかを調べるための大切な手掛かりです。ただし、イベントビューアーにエラーや警告があるだけで故障と判断する必要はありません。
- まず不具合が発生した時刻を確認する
- システムとアプリケーションのログを使い分ける
- イベントIDとソースをセットで確認する
- 同じ症状と一緒に再現するエラーを優先する
- Kernel-Power 41だけで原因を断定しない
- 原因が見えない時は信頼性モニターも使う
- トラブルシューティングができない時はDISMとSFCを検討する
- BSODが続く場合はWindows11 dumpも確認する
「エラーを全部消す」のではなく、「実際の不具合と関係しているログを見つける」ことが一番大切です。発生時刻、再現条件、直前の操作を整理してからログを見ると、原因特定の精度は大きく変わってきますよ。
レジストリ変更、DISMの高度なソース指定、ページファイルの手動変更、ハードウェア交換などは環境によって影響が異なります。重要なデータは事前にバックアップし、Windowsの最新仕様についてはMicrosoftやパソコンメーカーの公式情報をご確認ください。ハードウェア故障が疑われる場合や大切なデータを扱うPCでは、最終的な判断をメーカーサポートや専門業者へ相談することをおすすめします。