WHEA-LoggerのイベントID 1とは｜Corrected Machine Checkの条件と17・18・19との違い【2026年版】
本記事にはアフィリエイト広告（Amazon・楽天市場等）のリンクが含まれています。
同じ番号でも「訂正済み」と「致命的」の両方が記録されるため、17・18・19とは確認の仕方が変わります
イベントビューアーでWHEA-Loggerを調べると、イベントID 17・18・19の解説はよく見かけるのに、自分のPCに記録されているのはイベントID 1だった、というケースがあります。ID 1はほかの3つと違い、番号だけでは訂正済みのエラーなのか致命的なエラーなのかが決まっていません。実際に記録された内容と、Microsoft公式のWHEA関連文書にもとづいて、ID 1が何を意味し、どう対処すべきかを整理します。
出典：Microsoft WHEA概要・Microsoft Hardware Errors and Error Sources・Microsoft Bug Check 0x124・Microsoft WHEA_ERROR_SEVERITY・Microsoft WHEA_ERROR_PACKET_V2・Microsoft WHEA_XPF_CMC_DESCRIPTOR・Microsoft WHEA_EVENT_LOG_ENTRY_ID・Microsoft Interpreting a WHEA error for a MCA fault・Intel 64 and IA-32 Architectures SDM Volume 3B
イベントビューアーを開き、WHEA-Loggerで検索してみると「イベントID 1」が記録されていた。ネットで調べるとイベントID 17・18・19の解説ばかりで、自分の状況とどう対応するのか分からない。そんな状態でCPUやパーツの故障を疑って身構える前に、確認しておきたいことがあります。
この記事では、WHEA-LoggerのイベントID 1が実際にどんな内容で記録されるのか、Corrected Machine Check（訂正済みのMachine Check）として記録される条件とは何かを、Microsoft公式のWHEA関連文書とIntelのMachine Check Architecture仕様にもとづいて整理します。
17は常に訂正済みのPCIeエラー、18は常に致命的なMachine Check、19は常に訂正済みのMachine Check、という具合に、既存記事で解説したイベントID 17・18・19は番号ごとに重大度が固定されています。一方でイベントID 1は、実際に記録された内容を見比べると、同じ番号のまま「訂正済み」にも「致命的」にもなるという性質があります。Corrected・Uncorrectedの危険度早見表とあわせて、ID 1特有の確認ポイントを解説します。
目次
基礎知識WHEA-LoggerのイベントID 1とは
WHEA（Windows Hardware Error Architecture）は、CPU、メモリ、PCI Expressデバイス、ストレージコントローラーなど、さまざまなハードウェアが検出したエラー情報を標準化し、Windowsのシステムイベントログへ記録する仕組みです。この記録を実際にイベントビューアーへ書き出す役割を担っているのが「Microsoft-Windows-WHEA-Logger」というプロバイダーで、System ログにWHEA-Loggerという名前で表示されます。
イベントID 17・18・19の記事で解説したとおり、この3つは番号ごとに重大度がほぼ固定されています。17はPCI Expressで検出された訂正済みエラー、18はCPUが報告する致命的なMachine Check Exception、19はCPUが報告する訂正済みのMachine Checkです。番号を見れば、おおよその重大度と確認すべき範囲の見当がつきます。
イベントID 1はこの並びとは性質が異なります。Microsoft-Windows-WHEA-Loggerが記録するイベントの中でも、ID 1は古くから存在する汎用的な番号で、CPUのMachine Check以外のエラーソースでも使われることがあります。番号だけを見て「ID 1だからCPUの訂正済みエラーだ」と決めつけると、実際の原因を見誤る可能性があります。
実例同じID 1でも「訂正済み」と「致命的」の両方が記録される
WHEA-LoggerのイベントID 1として実際に記録された内容を確認すると、次のように、メッセージ本文が明確に異なる複数のパターンが存在します。
A corrected hardware error has occurred.
Reported by component: Processor Core
Error Source: Corrected Machine Check
Error Type: Cache Hierarchy Error
Processor APIC ID: 20この例では、Reported by component、Error Source、Error Typeの並びが、イベントID 19の記事で紹介したCorrected Machine Checkの表示例とほぼ同じ形式です。訂正済みのCPUエラーであり、Windowsの動作は継続しています。
A fatal hardware error has occurred. A record describing the condition is contained in the data section of this event.一方でこちらの例は、まったく同じイベントID 1でありながら、メッセージの一文目が「Fatal（致命的）」を示しています。さらに、CPUのMachine Checkとは無関係に、ストレージコントローラーのドライバー（Storportや特定のRAID/AHCIドライバーなど）に関連する情報が記録として残っていた事例も確認できます。この場合、Reported by componentやError SourceにCPU関連の文言は出てきません。
つまりイベントID 1は、番号自体に「訂正済み」「CPU起因」といった意味が固定されていません。メッセージ本文の一文目が「A corrected hardware error has occurred」なのか「A fatal hardware error has occurred」なのか、そして詳細欄のReported by component・Error Source・Error Typeに何が表示されているのかを確認するまでは、危険度も原因のパーツも判断できません。
仕組みCorrected Machine Checkとして記録される条件
先ほどの訂正済みの例のように、イベントID 1がCPUのCorrected Machine Check（訂正済みMachine Check、以下CMC）として記録される場合、その背景にはIntelのMachine Check Architectureが定める2つの報告経路があります。
1つ目はCorrected Machine Check Interrupt（CMCI）と呼ばれる割り込みベースの仕組みです。IntelのSoftware Developer’s Manual Volume 3Bによると、CPUの各Machine Checkバンクには訂正済みエラーの発生回数を数えるカウンターがあり、ソフトウェアがIA32_MCi_CTL2レジスタでしきい値を設定しておくと、カウンターがそのしきい値へ達した時点でCMCIという局所割り込みが発生し、OS側へ即座に通知されます。単純な定期ポーリングよりも早く訂正済みエラーの増加を検知できる仕組みです。
2つ目はポーリングです。CMCIが利用できない、または不安定と判断されたプラットフォームでは、WHEAが一定間隔でMachine CheckバンクのMSRを自ら読みに行き、訂正済みエラーの有無を確認します。Microsoftの技術文書に定義されているWHEA_XPF_CMC_DESCRIPTOR構造体は、CPUごとのCorrected Machine Checkエラーソースを表す構造体で、その中に「Notify」という通知方式の記述領域を持っています。この通知方式は、割り込みベースかポーリングベースかを切り替えられる構造になっており、IntelのCMCIとポーリングという2つの経路にそのまま対応しています。
どちらの経路であっても、訂正済みのMachine Checkバンクエラーが検出されると、WHEAはそのエラー条件を重大度「Corrected」のエラーレコードとして生成します。この重大度は、WHEA_ERROR_SEVERITYという列挙型で定義されており、WheaErrSevCorrected（ハードウェアまたはファームウェアによって訂正済み）、WheaErrSevFatal（訂正されておらず致命的）、WheaErrSevRecoverable（訂正されていないが回復の可能性がある）、WheaErrSevInformational（エラーは発生していない）の4種類に分かれます。CPUが報告したCorrected Machine Checkは、この中のWheaErrSevCorrectedとして扱われ、WHEA-Loggerが「A corrected hardware error has occurred」というメッセージとともにSystemログへ書き出します。
非公開なぜ19番ではなく1番になることがあるのか
ここまでの内容を踏まえると、疑問が残ります。同じ「CPUが報告した訂正済みのMachine Check」であるなら、なぜイベントID 19として記録される場合と、イベントID 1として記録される場合があるのか、という点です。
結論からいうと、この具体的な割り当てロジックは、Microsoftの公開文書では説明されていません。Windows Driver Kitのリファレンスには、WHEA関連の内部イベントに使われるWHEA_EVENT_LOG_ENTRY_IDという列挙型が存在しますが、Microsoft自身がこの列挙型の説明として「reserved for system use. Do not use.（システム内部での使用のために予約されており、使用しないでください）」と明記しています。
また、Microsoftのエンジニアが公開した技術ブログ「Interpreting a WHEA error for a MCA fault」では、WHEA形式のエラーレコード（CPER：Common Platform Error Record）のヘッダー部分がWHEA_ERROR_PACKET_V2構造体であり、この構造体自体が重大度（ErrorSeverity）とエラーの種類を保持していると説明されています。つまり、エラーの重大度そのものはエラーレコードの内部に格納されている情報であり、Windowsのイベントビューアーに表示される数字（Event ID）とは別の場所で管理されています。
この記事では、Event IDの具体的な採番ロジック（OSのビルド、マザーボードのACPIテーブル、どの低レベルハードウェアエラーハンドラーが処理したかなど、何が1番と19番を分けているのか）について、公式文書で確認できる範囲を超えて推測することはしません。実務上重要なのは、ID 1という番号そのものではなく、記録されたメッセージ本文とError Source・Error Typeの内容です。
確認方法イベントビューアーとPowerShellで詳細を読む
PowerShellから確認する場合は、管理者として開き、次のコマンドでイベントID 1だけを抽出できます。
Get-WinEvent -FilterHashtable @{
LogName = 'System'
ProviderName = 'Microsoft-Windows-WHEA-Logger'
Id = 1
} | Select-Object TimeCreated, Id, LevelDisplayName, Message | Format-ListLevelDisplayNameが「エラー」なのか「警告」なのかも参考になりますが、最終的な判断はMessageプロパティの一文目（訂正済みか致命的か）とReported by component以下の内容を優先してください。
判断放置していいか、対処すべきか
イベントID 1であっても、放置していいかどうかの判断基準そのものは、Corrected・Uncorrectedの危険度早見表で解説した内容と変わりません。番号ではなく、メッセージ本文が示す重大度と、症状の有無、発生頻度で判断します。
- メッセージ本文が「A corrected hardware error has occurred」
- Reported by componentがProcessor Core、Error SourceがCorrected Machine Check
- 記録が単発で、フリーズ・ブラックアウト・突然の再起動が起きていない
- 同じ内容で繰り返し記録されていない
- メッセージ本文が「A fatal hardware error has occurred」
- 同じ内容のイベントID 1が短期間に繰り返し記録される
- フリーズ・ブラックアウト・突然の再起動を伴う
- Reported by componentがCPU以外（ストレージコントローラーなど）を指している
訂正済みのCorrected Machine Checkが単発で記録され、他に症状がないのであれば、その1件だけを理由にCPUの交換を検討する必要はありません。一方で、致命的なメッセージが出ている場合や、同じ内容が短期間に繰り返される場合は、経過観察のままにしないでください。
対処原因別の対応手順
Reported by componentがProcessor Core、Error SourceがCorrected Machine Checkと表示されている場合は、イベントID 17・18・19の記事で解説したCorrected Machine Check（イベントID 19）と同じ手順で切り分けます。CPUのPBOやCurve Optimizer、手動のオーバークロックや低電圧化をいったん解除し、XMP・EXPOを無効にしてメモリを定格へ戻したうえで再発するか確認します。CPU用の電源ケーブルの挿し直しや、クーラーの取り付け・温度の確認も有効です。
メッセージ本文が「A fatal hardware error has occurred」の場合は、様子見にせず、致命的なMachine Check Exception（イベントID 18）と同じ優先度で対応してください。停止コード「WHEA_UNCORRECTABLE_ERROR」やバグチェック0x124を伴っている場合は、オーバークロックの解除、冷却の確認、メモリ診断を先に行います。BIOSを初期状態へ戻しても改善しない場合は、CPU・マザーボード・電源ユニットの検証用部品での切り分けが必要になります。
Reported by componentやError Sourceに、CPUではなくストレージコントローラーのドライバー名やデバイス情報が表示されている場合は、CPUを疑う前にストレージ側を確認します。該当するRAID・AHCIコントローラーのドライバーとファームウェアを最新化し、ケーブルとコネクタの接続、SSD・HDDのSMART情報、RAID構成であればアレイの状態を確認してください。CPUの設定を戻してもこのパターンのイベントID 1が止まらない場合は、対象がCPUではない可能性が高いというサインです。
Q&Aよくある質問
まとめID 1は番号でなく本文とError Sourceで判断する
WHEA-LoggerのイベントID 1は、17・18・19のように番号で重大度が固定されていません。「A corrected hardware error has occurred」なのか「A fatal hardware error has occurred」なのか、メッセージ本文の一文目を必ず確認してください。
CPUが報告するCorrected Machine Checkとして記録される場合、その背景にはIntelのCMCI（割り込み）とWHEAによるポーリングという2つの報告経路があり、いずれも重大度「Corrected」のエラーレコードとしてWHEA-Loggerへ渡されます。ただし、どちらの経路で1番という番号が選ばれるのかという採番ロジックは、Microsoftの公開文書では説明されていません。
実務上は、Reported by component・Error Source・Error Typeを確認したうえで、CPU起因であればイベントID 17・18・19の記事と同じ手順で切り分け、放置していいかどうかはCorrected・Uncorrectedの危険度早見表の基準にそのまま当てはめてください。
あわせて読みたい
※価格は2026年8月時点の目安・変動あり
※価格は2026年7月時点の目安・変動あり
