Windows 11 環境で突如現れる「WHEA_UNCORRECTABLE_ERROR (STOP 0x124)」のブルースクリーン。イベント ビューアーにも決め手がなく、原因がハードかソフトか判断できない――そんな“もやもや”を、実際のミニダンプ解析と再現検証、そしてBIOS／チップセット更新で解消した事例をベースに、再発防止まで一気通貫でまとめました。AMD 環境で発生しやすい落とし穴や、解析時に見るべきポイントも余さず解説します。
事象の概要と前提
本記事のケースでは、Windows 11 PC で以下の現象が不定期に発生していました。
- ブルースクリーン：WHEA_UNCORRECTABLE_ERROR（0x124）
- ログ：WHEA-Logger には断片的な情報のみ、決定打なし
- ミニダンプ：クラッシュ時のプロセスは
aces.exe、モジュールにAuthenticAMDが見える - マシン：AMD プラットフォーム（例：ASUS ROG CROSSHAIR VIII FORMULA）
| 項目 | ポイント |
|---|---|
| エラーコード | 0x124（WHEA が通知する「訂正不能」＝致命的ハードウェア エラー） |
| 頻度 | 完全なランダム。アイドル中／高負荷中のどちらでも発生 |
| イベントログ | WHEA-Logger に CPU/メモリ/PCIe 周辺の断片情報はあるが根因が特定できない |
| ダンプ | PROCESS_NAME: aces.exe。スタックに AuthenticAMD の文字列（※後述）が含まれる |
WHEA_UNCORRECTABLE_ERROR（0x124）の正体
WHEA（Windows Hardware Error Architecture）は、CPU が備える Machine Check Architecture (MCA) や PCIe の AER など、ハードウェア自身の自己診断／訂正機構から上がってくるエラーを OS に標準化して通知する仕組みです。0x124 はその中でも “訂正不能（Uncorrectable）” と判断された深刻なハードウェア例外を意味します。典型的には、以下のようなカテゴリが関与します。
- Processor Core / L1〜L3 キャッシュ階層のエラー
- Memory Controller / DRAM サブシステムの異常（メモリエラー、メモリコントローラのタイミング不整合など）
- Bus/Interconnect（PCIe 等） のプロトコルエラーやタイムアウト
- VRM/電源品質の問題 に起因する一過性の機械チェック例外
重要なのは、0x124 は「OS の不具合」ではなく、ほぼ確実にハードウェア階層で検知された例外だという点です。ドライバーが間接的に誘発することはあり得ますが、根本の検知はハード側で起きています。
ミニダンプで何を見るか：実践的な手順
原因を絞り込むにはミニダンプが最短距離です。Windows 11 なら C:\Windows\Minidump に最新クラッシュが保存されます。ここでは WinDbg（Preview）想定で、解析の「見どころ」を絞って紹介します。
シンボル設定と基本コマンド
.symfix
.reload
!analyze -v
!analyze -v の出力で最初に注目するのは次の 4 点です。
- BUGCHECK_STR：
0x124_AuthenticAMDなど、ベンダー名と一緒に出ることがある - PROCESS_NAME：
aces.exeなど、クラッシュ時に実行中だったプロセス名（＝犯人ではなく状況証拠） - Arg2：WHEA エラー レコードへのポインタ
- STACK_TEXT：ドライバー絡みの痕跡がないか薄く確認
WHEA エラーレコードを掘る
Arg2 に示されるアドレスを !errrec（または拡張コマンド）で展開すると、エラー種別がわかります。
!errrec ffff8f0a`12345678
ここで Error Type が Cache Hierarchy Error / Bus Interconnect Error / Memory Controller Error のいずれかで示され、APIC ID、Bank、Status、Address といった MCA 情報が付随します。同じ Bank/同じコア ID に偏っているなら CPU/メモリ/PCIe のどこに寄っているかが見えてきます。
「AuthenticAMD」とは何か
注意：
AuthenticAMDは CPUID のベンダーストリングであり、実在するドライバー ファイル名ではありません。WinDbg の出力に登場しても、それ自体が壊れているわけではありません。0x124 の「ハードウェア検知」という性質を示す補助的なヒントとして扱います。
プロセス名 aces.exe の扱い
クラッシュ時の PROCESS_NAME に何が表示されても、それは「その瞬間に CPU を使っていた実行体」に過ぎません。aces.exe が見えたとしても、それが直接の原因とは限りません。WHEA の種別（Cache/Bus/Memory）とセットで解釈しましょう。
まずやるべき 4 ステップ（本件で効いた対策）
本件では以下の 4 手順で安定化しました。優先度順に実施することを推奨します。
- マザーボード公式サイトから最新の AMD チップセット ドライバーを「入れ直す」
OS 再インストール級に効くことがあります。旧版や破損、互換性のズレを一掃します。必ず マザーボード ベンダーの提供版 を用い、セットアップ後は再起動します。 - BIOS を最新に更新する
マイクロコード（CPU）や AGESA（AMD プラットフォーム初期化）の更新で WHEA の沈静化が期待できます。ASUS ROG CROSSHAIR VIII FORMULA では 2025‑01‑13 公開の Ver. 5002 以降が推奨でした（機種固有の例）。 - アップデート直後は「完全シャットダウン → コールドブート」
高速スタートアップのキャッシュを使わないよう、コマンドで明示的にシャットダウンしてから起動します。shutdown /s /t 0 - ミニダンプを「複数」集めて共通項を確認
3〜4 回分で 同一 Bank/同一 APIC ID/同一 Error Type に偏りがあるかを見ます。偏りがあるほど根因に近づけます。
| 対処 | 狙い | 注意点 |
|---|---|---|
| チップセット ドライバー再インストール | ACPI/PCIe/電源管理の初期化不整合を解消 | ベンダー版を使用。インストール後は再起動を2回実施すると安定しやすい |
| BIOS 更新 | AGESA/マイクロコード更新で WHEA 低減 | 更新後は XMP/EXPO・PBO・Curve Optimizer 等のOC設定を一度すべて既定に戻す |
| 完全シャットダウン | 高速スタートアップの影響を排除 | 電源ランプ消灯後、数十秒待ってから起動 |
| 複数ダンプの相関確認 | 再現性のある共通因子を抽出 | 日時・温度・負荷状況もメモしておく |
補助診断：WHEA の裏取りとハード健全性チェック
“とりあえず更新”で安定することは多いですが、裏取りをしておくと再発時の切り分けが爆速になります。
| チェック項目 | 目的・ポイント | 実施のコツ |
|---|---|---|
| メモリ診断（MemTest86 等） | DRAM のビットエラー検出 | EXPO/XMP を切って JEDEC 速度で 1 周、問題なければ EXPO/XMP で 2〜3 周 |
| CPU 温度・電圧モニタリング | 過熱・電圧降下による誤動作防止 | アイドルと負荷（Cinebench/OCCT）で 5 分ずつログを取り、スパイク有無を確認 |
| 電源ユニット（PSU）の健全性 | 12V レールの揺らぎ・経年劣化 | 高負荷時にリブートを伴うなら PSU 疑い。容量の 50〜60% 運用が目安 |
| WHEA-Logger の詳細確認 | エラーソースの特定（Processor/Memory/PCIe） | 「APIC ID」「Bank」「Error Type」「Address」が連続して同じかに注目 |
| システムファイル整合性（SFC/DISM） | OS 側の破損を除外 | sfc /scannow DISM /Online /Cleanup-Image /RestoreHealth |
イベント ビューアーでの痕跡の拾い方
イベント ビューアー → Windows ログ → システム で、ソースが WHEA-Logger のイベントを過去に遡って並べ替えます。以下の項目に絞ってメモを残すと、後段のチューニングに効きます。
- Error Source：Processor Core / Memory Controller / PCI Express Root Port など
- Processor APIC ID：エラーを出した CPU 論理コアの ID
- Bank：MCA バンク番号（特定の Bank に偏ると要注意）
- Address：メモリアドレスが示されるケースあり（DRAM 疑い）
PowerShell に慣れているなら、簡易的に直近の WHEA を拾えます。
Get-WinEvent -LogName System |
Where-Object {$_.ProviderName -eq "Microsoft-Windows-WHEA-Logger"} |
Select-Object TimeCreated, Id, LevelDisplayName, Message |
Sort-Object TimeCreated -Descending |
Select-Object -First 30
AMD 環境での設定見直しポイント
BIOS 更新直後は、まず 完全な定格（Auto） に戻して安定性を見ます。以下の設定は一時的に OFF/Auto を推奨し、安定後に段階的に戻すのがセオリーです。
- PBO（Precision Boost Overdrive）：一時的に無効
- Curve Optimizer（CO）：値を 0（無効）に戻す
- EXPO/XMP：いったん JEDEC で様子見 → 問題なければ有効化
- PCIe の省電力（ASPM/L1 Substates）：切り分け目的で一時的に無効
また、Windows 側の電源プランは バランス を基本にし、検証時のみ 高パフォーマンス と切り替えて温度・電圧挙動を比べると差が見えます。
GPU・PCIe 周りの切り分け
WHEA の Bus/Interconnect エラーが出るなら、GPU/拡張カード/ストレージの PCIe 周辺を疑います。
- GPU を別スロットに差し替える／補助電源ケーブルを交換する
- PCIe Gen（Auto → Gen3/Gen4 固定）を試す
- NVMe SSD のサーマルスロットリング（高温）を確認
- 不要な拡張カードを一時的に外し、最小構成で再現性をみる
実例：BIOS とチップセット更新で安定化
今回のケースでは、以下の流れで改善が確認されました。
- AMD チップセット ドライバーをマザーボード公式版で入れ直し
- BIOS を最新（例：2025‑01‑13 公開 Ver. 5002 以降）に更新
- 完全シャットダウン → コールドブート
- EXPO/PBO/CO をすべて既定に戻した状態で 48〜72 時間の安定性確認
結果として、投稿者は「安定動作を確認できた」と報告。ミニダンプの新規生成も止まり、WHEA-Logger の致命的イベントは以後観測されませんでした。ドライバーと AGESA/マイクロコードの更新が、ハードウェア例外の抑制に直結した典型例です。
再発時のエビデンス取り「型」
再発に備えて、以下のテンプレートで記録を残すと次のトリアージが数倍速になります。
| 項目 | 記録例 |
|---|---|
| 日時／状況 | 2025-02-05 21:12、ゲーム起動直後のローディング時に BSOD |
| 温度・電圧 | CPU 78℃前後、Vcore は 1.1〜1.25V で安定 |
| WHEA-Logger | Error Source: PCI Express Root Port、Bus/Device/Function=xx:yy:zz |
| ダンプ | Arg2（WHEA_ERROR_RECORD）と Bank/APIC ID を控える |
| 直前の変更 | GPU ドライバー更新、EXPO を 6000 → 6200 に変更 など |
ミニダンプが生成されない場合
「0x124 で落ちるのにダンプがない」場合は、スタートアップと回復の設定を見直します。
- システムのプロパティ → 詳細設定 → 起動と回復 → 小（256KB）メモリダンプ 以上を選択
C:\Windows\Minidumpのアクセス許可と空き容量を確認- ストレージ暗号化や一部のセキュリティ製品が妨げるケースは例外フォルダに追加
チェックリスト：0x124 の現場対応
- まずは BIOS 更新 と チップセット ドライバー入れ直し（ベンダー版）
- 完全シャットダウン → コールドブート でキャッシュ影響を除去
- EXPO/PBO/Curve Optimizer を 一旦すべて無効 に戻して観察
- WHEA-Logger の Error Source / APIC ID / Bank を控える
- ミニダンプは 3〜4 個集め、共通点（同じコア・同じ Bank）を探す
- 必要に応じてメモリテスト・電源・PCIe の切り分けを追加
- OS の整合性は
sfcとDISMで最終確認
よくある質問（FAQ）
Q. ドライバーが原因ですか？
A. 0x124 はハードウェア側の検知がトリガーです。ドライバーは間接要因（電源ポリシー／PCIe の省電力／古いチップセット）として寄与することはありますが、まずは BIOS/チップセット更新と設定の既定化で挙動を見直しましょう。
Q. PROCESS_NAME: aces.exe が犯人では？
A. プロセス名は「たまたまその時動いていたもの」。犯人扱いは禁物です。WHEA の Error Type と APIC ID/Bank が何を指しているかを優先的に読み解いてください。
Q. イベントに Corrected（訂正済み）が多く出ています
A. Corrected は OS が介入せずにハード／ファームが自己回復できた記録です。ただし短時間に多数発生するなら、将来の Uncorrectable（= 0x124）に繋がる予兆になり得ます。冷却・電圧・ドライバー更新を前倒しで実施しましょう。
Q. オーバークロック（PBO/CO/EXPO）は完全に諦めるべき？
A. いいえ。まずは定格で安定性を確立し、その後に 一項目ずつ戻してください。戻すたびに 24〜48 時間の観察ウィンドウを設け、WHEA-Logger の有無を確認するのが安全です。
トラブルシュートを短縮する「再発防止の型」
最後に、現場で役立つ「整備サイクル」を提示します。
- 更新の標準化：四半期ごとに BIOS/チップセットを見直す
- 設定のプロファイル化：定格・軽OC・高OC の 3 プロファイルを BIOS に保存
- 監視の自動化：温度・クロック・電圧の簡易ログを常時 1 分粒度で保存
- ダンプ保全：Minidump は自動で ZIP 化して世代管理（直近 10 件保持）
- 記録習慣：「直前の変更」と「発生状況」を簡易テンプレに残す
まとめ
WHEA_UNCORRECTABLE_ERROR（0x124）は、OS の上では解釈困難でも、WHEA エラーレコードとハードウェア初期化（BIOS/チップセット）を立て直すことで沈静化できることが多いエラーです。本記事の AMD 環境の事例でも、マザーボード公式チップセットドライバーの入れ直しとBIOS の最新化、そして完全シャットダウン → コールドブートという基本動作で安定を取り戻しました。再発に備えて、ミニダンプ 3〜4 件の共通項を押さえ、WHEA-Logger のエッセンス（Error Type / APIC ID / Bank）を抜き出す――この“型”さえ持っていれば、次に同じ症状が来ても迷いません。
付録：コマンド／手順スニペット集
完全シャットダウン
shutdown /s /t 0
OS 整合性チェック
sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth
WinDbg の基本フロー
.symfix
.reload
!analyze -v
r
k
!errrec <Arg2 のアドレス>
イベント ログ抽出（PowerShell）
Get-WinEvent -LogName System |
Where-Object {$_.ProviderName -eq "Microsoft-Windows-WHEA-Logger"} |
Select-Object TimeCreated, Id, LevelDisplayName |
Sort-Object TimeCreated -Descending |
Select-Object -First 30
ケーススタディの要点（再掲）
- エラーの性質：0x124 は WHEA が検出した致命的ハードウェア例外。ダンプでは
AuthenticAMDが見え、aces.exe実行中に発生。 - 主要対処：AMD チップセット ドライバーをマザーボード公式から入れ直し、BIOS を最新化（例：ROG CROSSHAIR VIII FORMULA は 2025‑01‑13 Ver.5002 以降）。完全シャットダウン→再起動。
- 検証姿勢：ダンプを 3〜4 個分析し、WHEA エラーレコードの共通点（Error Type/APIC ID/Bank）に着目。
- 補助診断：メモリ・温度/電圧・電源・PCIe・SFC/DISM を表に沿って実施。
- 結果：上記の更新で安定化を確認。
コメント