WHEA-Loggerのエラーは無視しても大丈夫か｜Corrected・Uncorrectedで変わる危険度早見表【2026年版】

出典：Microsoft Hardware Errors and Error Sources・Microsoft Bug Check 0x124・Microsoft WHEA概要・Microsoft Interpreting a WHEA error for a MCA fault・Intel 64 and IA-32 Architectures SDM Volume 3B

イベントビューアーを開いたら、システムログに「WHEA-Logger」という警告やエラーが記録されていた。それでもPCは普段どおり起動し、ゲームも普通にプレイできている。そんなとき、このログをそのまま放置していいのか、それとも今すぐ何かを確認すべきなのか、判断に迷うことがあります。

WHEAが記録するハードウェアエラーには、ハードウェア自身が自己修復できたCorrected（訂正済み）と、修復できなかったUncorrected（未訂正）という明確な区分があり、Uncorrectedはさらに回復を試みられるNonfatalと、回復不能なFatalに分かれます。この記事では、Microsoft公式ドキュメントとIntelのMachine Check Architecture仕様にもとづいて、この3つの違いと、放置していい度合いがどう変わるのかを整理します。

既存の記事では、イベントID 17・18・19それぞれが何を示し、原因をCPU・メモリ・PCIe・GPUのどこに求めるかを扱っています。本記事はその内容を前提に、「結局、放置していいのか」という危険度の判断だけに焦点を絞り、様子見でいいケースと今すぐ確認すべきケースを早見表で対比します。

定義Corrected・Uncorrected・Fatalは何が違うのか

WHEA（Windows Hardware Error Architecture）は、CPUやメモリ、PCI Expressデバイスなどが検出したハードウェアエラーを、Windowsのシステムイベントログへ記録する仕組みです。Microsoft公式のドキュメントでは、このハードウェアエラーを大きくCorrected（訂正済み）とUncorrected（未訂正）の2つに分類し、UncorrectedをさらにFatal（致命的）とNonfatal（非致命的）に分けています。

Correctedは、OSがエラーの存在を通知される時点で、すでにハードウェアやファームウェアが訂正を終えているエラーです。Uncorrected（Nonfatal）は、訂正できなかったものの、OSが回復を試みる余地があるエラーで、回復に失敗した場合はOSが停止処理（バグチェック）を発生させます。Fatalは、ハードウェアが回復不可能と判断した未訂正のエラーで、発生した時点でOSはただちに停止処理を生成します。

CPU側の実装を見ても、Intelの仕様書（Machine-Check Architecture）には、エラーが訂正されたかどうかを示すビットと、処理を継続できない状態かどうかを示すビットが個別に用意されており、この2段階の判定でOSへ回復可能かどうかを伝える設計になっています。Machine Check ArchitectureはIntel・AMD双方のx86プロセッサに実装されている仕組みで、AMD製CPUも同じ枠組みにもとづいてエラーを報告するため、CorrectedかUncorrected（Fatal含む）かという分類の考え方自体は、CPUメーカーを問わず共通しています。

対応イベントID 17・18・19はどの分類に入るか

WHEA-Loggerで頻繁に見かけるイベントID 17・18・19は、いずれもこのCorrected・Uncorrected・Fatalという分類にそのまま対応しています。

数字が大きいほど深刻というわけではありません。18だけがFatal（回復不能）で、17と19はどちらもCorrected（訂正済み）です。この対応を取り違えると、本来は経過観察でよいイベントID19を過剰に心配したり、逆に対応が必要なイベントID18を様子見してしまったりします。それぞれのIDが具体的に何を意味し、原因をCPU・メモリ・PCIe・GPUのどこに求めるかは後述のリンク先で詳しく整理しています。

対比様子見でいいケースと今すぐ確認すべきケース

分類と頻度、症状の有無を踏まえると、次のように整理できます。

判断軸回数の基準がない理由と、増えているかどうかの見きわめ方

「何回までなら様子見していいのか」は、多くの人が知りたいところですが、Microsoft・Intelいずれの公式資料にも、具体的な回数の基準は示されていません。WHEAの分類はCorrected・Uncorrected（Nonfatal）・Fatalという種類の違いであり、発生回数を基準にした重大度の定義ではないためです。

ただし、頻度の変化そのものを無視してよいわけではありません。Intelの仕様書（64 and IA-32 Architectures Software Developer’s Manual Volume 3B）には、CPUキャッシュで発生した訂正済みエラーの件数を内部でカウントし、一定のしきい値を超えると「Yellow」状態としてサービスのスケジュールを促す仕組みが定義されています。これはWindowsのイベントログの件数と直接連動する仕組みではありませんが、「訂正済みのエラーでも、頻度が増えること自体が点検のサインになる」というハードウェア側の考え方を示しています。

実務的には、次の3つを手がかりに判断してください。1つ目は、直近数日で発生件数が明らかに増えているかどうか。2つ目は、特定のゲームや高負荷時、スリープ復帰時など、条件が決まって発生しているかどうか。3つ目は、同じPrimary Device NameやAPIC IDで繰り返しているかどうかです。ランダムに月1回程度発生している場合と、同じ条件で毎日発生している場合とでは、対応の優先度が変わります。

チェック放置か対処か迷ったら確認する3つの項目

Get-WinEvent -FilterHashtable @{
    LogName      = 'System'
    ProviderName = 'Microsoft-Windows-WHEA-Logger'
} | Group-Object { $_.TimeCreated.Date } | Select-Object Name, Count | Sort-Object Name

一覧状況別の危険度早見表

分類・頻度・症状の3軸を組み合わせると、次のように危険度と対応が変わります。

Q&Aよくある質問

まとめ訂正済みの単発は経過観察、頻度と症状で判断する

あわせて読みたい

トラブル・設定

WHEA-Logger 17・18・19の原因と直し方｜CPU・メモリ・PCIe・GPUをイベントログで切り分ける【2026年版】

トラブル・設定

ゲーム中にPCが落ちる・固まる原因と直し方｜電源不足からドライバまで5つの診断

トラブル・設定

LiveKernelEvent 141・117とは｜ゲーム中のブラックアウト・GPUクラッシュを直す方法

トラブル・設定

PCI Expressのリンク状態の電源管理はオフにすべきか