0. 結論（2026-08-28 04:30 更新・決定的証拠を取得）
フリーズの正体は「CPUのコアが1つ、割り込み(IPI)に応答しなくなり、他のコアが全員それを待ったまま止まる」現象です。
8/28 03:50 のフリーズで、設置したブラックボックスの効果でついにカーネルダンプ（2.18GB）が保存され、Windows純正デバッガ(WinDbg)で解析できました。
6個のCPU（#0,1,2,3,8,9）が全員 KeFlushProcessWriteBuffers → KiIpiStallOnPacketTargetsPrcb＝「他のコアからの返事待ち」で固まり、同じ状態が約43秒間まったく変化しませんでした（同一スタックを2,762回連続で採取）。その他のコアは全部アイドル。
つまりソフトの暴走・メモリ不足・ディスク待ちではありません。1つのコアが割り込みに答えなくなり、システム全体が巻き込まれて停止しています。
引き金（フリーズの直前に必ずやっていた操作）＝「全プロセスの一覧を取る」問い合わせ
落ちたスレッドは NtQuerySystemInformation / NtQueryInformationProcess（＝プロセス一覧の取得）でした。この処理は32スレッド全部に割り込みを一斉送信して返事を待つため、応答しないコアがあると即座に全体が止まります。
これを毎秒〜数秒おきに行うもの＝タスクマネージャー・各種モニターツール・監視スクリプト。「重いな」と思ってタスクマネージャーを開くと固まる、という体感はこれで説明が付きます。
対処済み：私が設置したブラックボックスも5秒ごとにこの問い合わせをしていたため、60秒ごとに変更しました（＝記録は続けつつ、引き金を引く回数を1/12に）。
安定しているOS（C:）との唯一の決定的な違い＝ハイパーバイザ（メモリ整合性 / VBS）が動いているかどうか
同じ機体・同じBIOSなのに、片方だけ落ちる理由を突き止めました。
・不調OS（D:）… HypervisorEnforcedCodeIntegrity = 1＝メモリ整合性ON → ハイパーバイザ稼働中（ダンプにも IsHyperV:1）
・安定OS（C:）… VBS = 0（完全にOFF）・ハイパーバイザのログも0件
さらにダンプ上で ApicVirtualizationAvailable: 0＝割り込みの高速化機能(AMD AVIC)が効いていないため、コア間の割り込みが全部ハイパーバイザ経由の重い処理になります。32スレッドのRyzenでこれは最悪の組み合わせで、既知の不具合が多発している領域です。
次にやること（この順・上から順に試す）
- 対策1：ハイパーバイザ（メモリ整合性）を切る ― ワンクリックで用意済み。SH-PCで起動して
D:\BASECORD-BLACKBOX\FIX-1-hypervisor-off.cmd（SH-PCで起動中はC:\BASECORD-BLACKBOX\…）をダブルクリック → 再起動。
副作用：この間 WSL2 / Docker Desktop / Windowsサンドボックス / Hyper-V仮想マシン が使えなくなります。元に戻すのは同じフォルダのREVERT-1-hypervisor-on.cmdをダブルクリックするだけ。 - 対策2（対策1で直らなければ）：BIOS設定 ― ASRock X570 Extreme4 / BIOS P5.80。
① Power Supply Idle Control → Typical Current Idle（Ryzenの「アイドル時に固まる」の定番対策）
② PBO / Curve Optimizer を無効（Auto→Disabled） ③ DOCP/XMP を無効（メモリ定格2666で動かす） - 対策3：それでも落ちる場合 ― CPU(またはメモリコントローラ)自体の劣化を疑い、1枚ずつのmemtest86＋CPU交換の検討へ。マザーボード交換は今も優先度が低い（マザー起因なら安定OS側でも同じ症状が出るはずのため）。
ハードウェアエラー（WHEA）3件について：8/27 17:55・18:08、8/28 00:45 に記録された Machine Check Exception（Bus/Interconnect Error ×2、Cache Hierarchy Error ×1）は今も有効な事実で、ハード側にも弱点があることを示します。ただし 8/28 の2回のフリーズでは WHEAは1件も出ていません。したがって「WHEAが直接の死因」ではなく、ハードの弱さ＋ハイパーバイザ経由の割り込みという負荷条件が重なったときに固まる、と読むのが最も整合します。対策1と対策2は、この両面からそれぞれ手を打つものです。
0-旧. 最初の結論（2026-08-28 未明・参考として残置）
引き金は「起動直後に走る常駐ソフト」の可能性が高い。ただし根っこはハード寄り（メモリ／CPU／電圧のどれかが不安定）。
理由：CPU自身が「ハードウェアが壊れている」と報告する記録（WHEA / Machine Check Exception）が3件出ています。これはアプリやOSがどれだけ暴れても発生しません。一方で、同じPCの別SSDの Windows は安定して動いており、そちらには問題の常駐ソフトが1つも入っていません。
＝「弱っているハードを、起動直後の重い常駐処理が毎回踏み抜いていた」という筋が最も辻褄が合います。
やったこと：疑わしい常駐7個を停止しました（元に戻せます）。マザーボード交換は保留のままで構いません。
1. 機体の構成
| PC名 | SH-PC（不調のOS = D:ドライブ側） ／ 今起動中の別OS = DESKTOP-F6ULUBI（C:ドライブ側） |
|---|---|
| CPU | AMD Ryzen 9 5950X 16コア32スレッド |
| マザーボード | ASRock X570 Extreme4 ／ BIOS P5.80（2026/03/24） |
| OS | Windows 11 Pro build 22631（導入 2023/03/28） |
| ストレージ | SPD SP300-2TNV3（1908GB）／ Hanye HE70-2TBNHS1（1908GB） 2台とも健康状態 Healthy・摩耗0%・ストレージエラーの記録ゼロ |
| メモリ （現在） |
チャンネルA: 16GB F4-3600C19-16GSXWB ＋ 8GB F4-2666C19-8GNTチャンネルB: 16GB F4-3600C19-16GSXWB ＋ 8GB F4-2666C19-8GNT4枚とも実動作 2667MHz（16GB側は本来3600だが、遅い方に引きずられている） |
2. 何が起きていたか（時系列）
0x116 VIDEO_TDR_ERROR（GPUが応答しない）。単発・3か月前なので今回とは別件。0x9F DRIVER_POWER_STATE_FAILURE（スリープ復帰の失敗）。これも単発・別件。同日 GPU電力制御の常駐を導入。0x133 DPC_WATCHDOG_VIOLATION（処理が返ってこない＝固まった時の典型）。0xA IRQL_NOT_LESS_OR_EQUAL（Windowsの記録では原因 ntoskrnl.exe＝カーネル本体。実質「原因不明」の意味）。0x133、直後に3件目のWHEA — Cache Hierarchy Error（CPUキャッシュの異常）。3. 実測データ
3-1. WHEA（CPU自身が出したハードウェアエラー）＝3件
| 発生時刻 | 種類 | 場所 | 生データ |
|---|---|---|---|
| 08-27 17:55:35 | Bus/Interconnect Error | APIC ID 0 / MCA Bank 27 | MciStat=0xb2a000000000080b |
| 08-27 18:08:56 | Bus/Interconnect Error | APIC ID 0 / MCA Bank 27 | MciStat=0xb2a000000000080b |
| 08-28 00:45:14 | Cache Hierarchy Error | APIC ID 9 / MCA Bank 5 | MciStat=0xbea0000000000108 |
※ 今起動している別SSDのWindows（C:）側では WHEA は0件。同じ物理マシンでも、不調OS側でだけ発生していた。
3-2. ブルースクリーン（Minidump）＝5件＋古い1件
| 日時 | 停止コード | 意味 | 今回との関係 |
|---|---|---|---|
| 08-28 00:38 | 0x133 | DPC_WATCHDOG_VIOLATION | 今回 |
| 08-27 22:03 | 0x133 | DPC_WATCHDOG_VIOLATION | 今回 |
| 08-27 16:29 | 0xA | IRQL_NOT_LESS_OR_EQUAL | 今回 |
| 08-27 15:53 | 0x133 | DPC_WATCHDOG_VIOLATION | 今回 |
| 08-19 05:40 | 0x9F | DRIVER_POWER_STATE_FAILURE | 別件 |
| 05-22 21:10 | 0x116 | VIDEO_TDR_ERROR | 別件 |
なお MEMORY.DMP（フルダンプ）は残っていません。上記はすべて Minidump からの読み取りです。
3-3. フリーズ直前の負荷（FreezeFlightRecorder の記録）
8/27 16:26 に仕込まれた記録ツールが、1分ごとにCPU使用率・空きメモリ・接続数を書き続けていました。その最後の行が示すのは——
[2026-08-28 00:57:30] cpu=5% freeMB=35263 udp=36 tcp=256
[2026-08-28 00:58:32] cpu=9% freeMB=34708 udp=38 tcp=236
← ここで記録が途切れる（＝一瞬で固まった）
つまり 「アプリの暴走」「メモリ不足」「じわじわ重くなる」タイプではない。何の前触れもなく一瞬で止まっています。起動からフリーズまでは 約3分半〜26分でした。
3-4. ストレージ（SSD）は無罪
2台とも SMART 健康状態 Healthy・摩耗 0%、ストレージ関連のエラーイベントは1件も記録なし。「片方のOSだけ固まる＝そのSSDの故障」という線は消えました。
4. 不調OS（D:）だけにあった常駐ソフト
安定している側のWindows（C:）には1つも入っていない一方、不調OS側は起動と同時にGPU・CPU・ネットワークを一斉に叩く構成になっていました。追加された時期は、ちょうどガレリア機・動画生成の作業をしていた8月19日〜24日に集中しています。
| 名前 | 実体 | 追加日 | 処置 |
|---|---|---|---|
| h3comfy8199 タスク | C:\Users\SH\h3-bench\comfy8199.cmdComfyUI（画像・動画生成）をポート8199で自動起動 | 08/21 | 🛑 停止 |
| h3progress タスク | ...\ComfyUI\venv\Scripts\pythonw.exe h3-progress-win.py生成の進捗を常時監視 | 08/21 | 🛑 停止 |
| BASECORD GPU Power Control タスク | wscript.exe "C:\BASECORD\gpu-power\Launch-GpuPower.vbs"GPUの電力制御を常駐 | 08/19 | 🛑 停止 |
| GalleriaControl.bat スタートアップ | node.exe ...\GalleriaControl\server.jsガレリア機を遠隔操作するNodeサーバー常駐 | 08/24 | 🛑 停止 |
| WolChecker.bat スタートアップ | WolChecker.ps1（他機の電源を監視） | 08/23 | 🛑 停止 |
| Ollama.lnk スタートアップ | ローカルAIモデル実行環境の自動起動 | 02/25 | 🛑 停止 |
| IdleForceSleep タスク | C:\Users\SH\Scripts\IdleForceSleep.vbs放置で強制スリープ（スリープ絡みのBSOD歴があるため） | 06/10 | 🛑 停止 |
| SH-FanDaemon タスク | fc_daemon.ps1LibreHardwareMonitor 経由でポンプ・ファンを直接制御 | 06/02 | 既に無効 （触っていない） |
残したもの：ComTunnel2222.bat（COMへのSSHトンネル＝この調査の生命線）／ FreezeFlightRecorder.bat（フリーズ記録ツール） | |||
.OFF を付けただけです（削除していません）。元に戻したい時は .OFF を消せば復活します。例：
D:\Users\SH\h3-bench\comfy8199.cmd.OFF → comfy8199.cmd
5. 一度疑って、取り下げた説
取り下げ「8GBメモリ F4-2666C19-8GNT が犯人」説
当初、この型番が犯人だと判断しました。根拠は、過去に別PC（ai-dev）で同じ型番に1ビット反転エラー3,509件が出て、抜いたら安定した実績があり、しかもその時の宿題が「SH-PCに同じロットが混入していないか確認する」だったためです。実際に4枚中2枚がその型番でした。
しかし取り下げます。酒井さんの指摘どおり、クラッシュしていた当時この8GBは刺さっておらず、16GB×2枚だけだったためです。刺さっていなかった部品は犯人になり得ません。
むしろ逆の可能性が浮上：「メモリの動作クロック」説
| クラッシュしていた時 | 今（安定） | |
|---|---|---|
| メモリ構成 | 16GB×2 のみ | 16GB×2 ＋ 8GB×2 の4枚 |
| 動作クロック | おそらく3600（DOCP/XMP有効） | 2667（実測） |
規格の違うメモリを混ぜたため、BIOSが低い方（2667）に合わせています。つまり 「8GBを足したから直った」のではなく、「8GBを足したせいでクロックが3600→2667に落ちて安定した」——これなら「2枚で落ちる／4枚で落ちない」という事実が全部つながり、Bus/Interconnect Error が出ていたこととも符合します。
6. 次にやること（この順番が最短）
- 常駐を止めた状態で、D:（SH-PC）を普通に起動して30分以上使う
落ちなければ「常駐が引き金」でほぼ確定します。※ 落ちたら、その時のログはCOM側から読めます（SSHトンネルは残してあります）。 - それでも落ちるなら、セーフモード（ネットワーク有効）で30分
落ちない → ドライバ側の問題。落ちる → ハード確定。ここで白黒つきます。 - ハード寄りと出たら、BIOSを疑う
DOCP / XMPをオフ（定格2666）にする。PBO・Curve Optimizerを既定値に戻す。Ryzenの Bus/Interconnect Error はこの2つが定番の原因です。 - それでも落ちるなら、16GBを1枚ずつ挿して memtest86
CPU内蔵のメモリコントローラの劣化という線も残るため、ここまでやって切り分けます。Windows標準のメモリ診断は精度が低く、ai-devの不良も memtest でしか検出できませんでした。「異常なし」と出ても信用しないでください。
- 不調SSDへの
chkdsk /fなどの修復系コマンド — 中身が書き換わり、原因の証拠が消えます（読み取りだけなら安全） - マザーボード交換 — 手順1〜3で絞り込む前にやると、直った理由が分からなくなります。今は保留
7. この調査のやり方（記録として）
不調のOSは一度も起動していません。別SSDから起動した正常なWindows（C:）に、COMサーバーのAIがSSH逆トンネル経由で入り、不調OSのドライブ（D:）をただのデータドライブとして読み取る方法で全部調べました。
| 読んだもの | 場所 |
|---|---|
| イベントログ（WHEA・Kernel-Power・BugCheck） | D:\Windows\System32\winevt\Logs\System.evtx |
| ブルースクリーンのダンプ | D:\Windows\Minidump\ |
| 自動起動の一覧 | レジストリ（D:\Windows\System32\config\SOFTWARE 等をオフラインで読み込み）＋ D:\Windows\System32\Tasks\ ＋ スタートアップフォルダ |
| フリーズ直前の負荷 | D:\Users\SH\Scripts\FreezeFlightRecorder.log |
| SSDの健康状態・メモリ構成 | 実機のWMI（起動中のWindowsから取得） |
壊れたOSを起動せずに調べられるのが、この方法の利点です。起動すると「固まる → 強制電源断」を繰り返し、そのたびに証拠が壊れていきます。
8. ブラックボックス（2026-08-28 設置）― 次のフリーズを取り逃がさない仕組み
これまでの記録は60秒に1回・OSのキャッシュ経由だったため、固まった瞬間の数十秒が丸ごと欠けていました。次の起動からは以下の仕組みが動きます。設置場所は不調OS側の C:\BASECORD-BLACKBOX（正常OSから見ると D:\BASECORD-BLACKBOX）です。
| 仕掛け | 内容 | なぜ効くか |
|---|---|---|
| 1秒刻みの飛行記録 | CPU／DPC・割り込み時間／メモリ／ページング／ディスク待ち行列／コンテキストスイッチ／プロセス数・スレッド数／GPU使用率・温度・消費電力／上位プロセス を毎秒CSVへ | 書き込み確定モード(WriteThrough)でディスクへ直書きするので、電源を強制で切っても直前の1行まで必ず残る |
| プチフリ検知 | 記録の間隔が3秒以上空いたら「STALL ○秒」と別ログに刻む | 完全に固まる前の「一瞬の停止」が拾える＝前兆が見える |
| 異常の即時記録 | DPC30%超・割り込み30%超・空きメモリ1GB未満・重大イベントを検知した瞬間に書き出し | ドライバ暴走かメモリ枯渇かをその場で切り分けられる |
| 起動時の検死レポート | 起動のたびに sessions\session-日時.md を自動生成。前回の最終記録時刻・最後の25行・落ち方（イベント41／ブルースクリーン1001）・WHEA・ダンプ一覧・メモリ構成・自動起動一覧を1枚に | 「前回どこまで生きていて、どう死んだか」が起動するだけで残る |
| 強制ダンプ（最重要） | 右Ctrl ＋ ScrollLock を2回で意図的にブルースクリーンを起こし、フリーズ中のメモリ内容を丸ごと保存 | ハングは通常ダンプが残らない。これが唯一「詰まっていた本体」を捕まえる手段 |
| ダンプ設定の格上げ | 最小ダンプのみ → カーネルメモリダンプ／専用ダンプ領域 C:\bbdump.sys 12GB／ミニダンプ保持 5→64件 | 原因ドライバやスタックまで追える情報量になる |
| イベントログ拡大 | システム／アプリケーション の上限を128MBへ | フリーズを繰り返しても古い記録が押し出されない |
D:\BASECORD-BLACKBOX を開けば全部読めます。COM側の開発AIもSSH経由で同じ場所を読みます。変更前のレジストリは backup-registry\*.before.reg に退避済みで、ダブルクリックで元に戻せます。
補足：今回スケジュールされたタスク側も点検しました。BASECORD GPU Power Control / h3comfy8199 / h3progress / IdleForceSleep / SH-SensorLogger は登録が残っていますが、起動対象のファイルを退避済み（または存在しない）ため、実行されても即失敗します＝常駐は止まったままです。
9. 「1つのコアが壊れているのか？」― ダンプの32コア全員分を読み直した結果（2026-08-28 追記）
| コア番号 | ダンプ時点の状態 | 意味 |
|---|---|---|
| 0 / 1 / 2 / 3 / 8 / 9 | KeFlushProcessWriteBuffers → KiIpiStallOnPacketTargetsPrcb で停止 | 被害者。「全コアへの一斉連絡」を出して、返事を待ったまま固まった |
| 4〜7 / 10〜31（24コア） | アイドル（優先度0・スタックが空） | この中に返事をしなかったコアがいる。眠っていたため記録が残っていない |
| 9（トドメ） | 上の待機中に時計割り込みが入り KeAccumulateTicks → 青画面 | 時計の遅れを検知して停止判断を下したコア |
止まった処理は KeFlushProcessWriteBuffers＝全32コアに一斉に割り込みを送り、全員の返事を待つ処理です。1つでも返事をしないコアがあると、待っている側が全員巻き添えで固まります。タスクマネージャーや監視ツールの「プロセス一覧取得」がこれを呼びます。
今回の失敗は「計算ができない」ではなく「深い眠りから起きて割り込みに返事ができない」です。負荷テストはコアを起こしっぱなしにするので、壊れたコアでも合格してしまいます（＝偽の安全宣言になる）。
再現させるなら「ほとんどのコアを眠らせたまま、プロセス一覧取得を高速で連打する」テストが正しい形です。
この読み直しで、BIOS の Power Supply Idle Control（省電力の深い眠り＝C6ステートの制御）が対策候補の筆頭に上がりました。Ryzen で「アイドル中・軽負荷中に固まる」時の定番の設定です。あわせてダンプ上で 割り込み高速化機能（AMD AVIC）が無効（ApicVirtualizationAvailable = 0）でハイパーバイザ経由になっていた点も、一斉割り込みを重くしていた要因です。
10. 「何の作業中に固まったのか」―― 呼び出し元まで特定した（2026-08-28 05:40 追記）
ダンプから、固まった6コアのスレッドがどのアプリのものかまで割り出しました。
| コア | 呼び出したアプリ（プロセス） | やろうとしていた作業 |
|---|---|---|
| 2 / 9 | WmiPrvSE.exe（Windows標準・WMIの窓口） | プロセス一覧の取得NtQuerySystemInformation → ExpGetProcessInformation |
| 0 | msedgewebview2.exe（親＝Microsoft Teams） | 各プロセスのCPU使用時間の取得NtQueryInformationProcess → PsQueryTotalCycleTimeProcess |
| 1 | msedgewebview2.exe（親＝WhatsApp） | |
| 8 | msedgewebview2.exe（親＝Windowsの検索 SearchHost） | |
| 3 | msedge.exe（Edgeブラウザ） |
6つとも最後は同じ場所で止まっています＝KeFlushProcessWriteBuffers → KiIpiStallOnPacketTargetsPrcb（全32コアに一斉に割り込みを送り、全員の返事を待つ）。
Teams・WhatsApp・Edge のような Chromium 系アプリは、自分の子プロセスのCPU使用率を表示するために定期的にこれを呼びます。タスクマネージャーを開けば毎秒同じことが起きます。WMI も Windows 標準の仕組みです。
＝ 特定の常駐ソフトのバグ・暴走ではありません。「返事をしないコアが1つある」ことが本体で、アプリはそれを踏んだだけです。
同じ作業を、健全なOS（C:）＝同じハードでやらせてみた
指摘のとおり、これが一番はっきりする確かめ方です。フリーズ時とまったく同じ2つのカーネル呼び出しを、6スレッドで連打し、1回ごとの所要時間を測る試験を作って実行しました（バーストの合間に休止を入れ、大半のコアを深い眠りに落としてから叩く＝故障の再現条件を作っています）。
| 測定 | 結果（健全OS C: ・1分間） |
|---|---|
| プロセス一覧の取得 | 16,850回 ／ 最大 7.4 ミリ秒 |
| CPU時間の取得 | 16,850回 ／ 最大 0.4 ミリ秒 |
| 10ms以上かかった回数 | 0回 |
| 50ms / 200ms / 1秒 / 5秒 以上 | すべて 0回 |
同じCPU・同じメモリ・同じ電源で、33,700回叩いて1度も引っかからない。不調OSでは同じ処理が43秒止まりました。
| 不調OS（D:） | 健全OS（C:） | |
|---|---|---|
| Windowsのバージョン | 24H2（build 26100） | 23H2（build 22631） |
| メモリ整合性 / VBS | ON（ハイパーバイザ稼働） | OFF（ハイパーバイザ無し） |
次の一手：不調OS側で同じ試験を走らせる（＝意図的な再現）
SH-PC（不調OS）で起動して、下のファイルをダブルクリックするだけです。
C:\BASECORD-BLACKBOX\TEST-2-ipi-latency.cmd
- 10分間、同じ2つの呼び出しを連打して1回ごとの時間を測ります
- 結果は
C:\BASECORD-BLACKBOX\logs\ipi-latency-*.summary.txt（別OSからも読めます） - 50ms以上が出れば、その時点で「ハード側が返事をしていない」証拠になります（健全OSでは0回）
- 途中で固まったら、それが再現成功です。電源ボタンの前に 右Ctrl＋ScrollLock 2回
この試験が「不調OSでだけ遅い」と出れば、原因はOS側の設定（メモリ整合性 / 24H2）で、対策1（ハイパーバイザOFF）で直る見込みが高い。
逆に「健全OSでも時々遅い」と出れば、それはハード（CPU・BIOS設定）が黒に近づきます。どちらに転んでも次が決まります。