「ゲーム起動→ディスク使用率100%→クラッシュ→SSDが消える」という厄介な症状は、ソフトよりもハード/ファーム起因であることが多く、闇雲な再インストールでは解決しません。本記事は、実機(Windows 10/ASUS B760/Intel 第12世代)で発生した事例をもとに、原因の考え方・切り分け手順・UEFI設定の勘所・再発防止策を、再現性のある手順としてまとめた実践ガイドです。
事例の全体像(要約)
以下は実機で観測された環境・症状・ログ・実施済み対処です。記事本体では、なぜその順序で切り分けるのか、各イベントIDが何を意味するのか、最終的に「メモリ不良」に辿り着いた経緯までを体系化して解説します。
環境
| 項目 | 構成 |
|---|---|
| OS | Windows 10 |
| マザーボード | ASUS TUF GAMING B760 Wi‑Fi D4 |
| CPU | Intel Core i7‑12700K |
| SSD(主) | WDC PC SN530 |
| SSD(副) | MSI M480 PRO(RMA履歴あり) |
症状
- CS2などゲームを起動すると、タスクマネージャーのディスク使用率が100%に張り付く一方で読み書き速度は0 B/sに停滞し、数秒後にゲームがクラッシュ。
- クラッシュ直後からSSD自体がエクスプローラーに表示されなくなる(再起動で復帰)。
- BSODは発生しないが、イベント ビューアーに以下のエラーが蓄積:
- WHEA Logger ID 17(PCI Express Root Portの訂正済みハードウェアエラー)
- StorNVMe ID 129/11(\Device\RaidPort1 のリセット・コントローラエラー)
- Disk ID 50/51(読み書き失敗の警告)
既に試したこと
- SSDの差し直し/M.2スロット変更、Windowsクリーンインストール、MemTest86、SFC・CHKDSK、BIOS & ドライバー更新、ASPM/C‑State無効化、レジストリ修正など。
- MSI M480 PROをRMA → 一時的に改善も、今度はWDC SN530側で同様の症状が再発。
結論(この事例):RAMを1枚外すと完全に症状が消失。不良メモリモジュールが根本原因でした。
「ディスク使用率100%・0 B/s」の正体:WindowsとNVMeの動作原理
「使用率100%なのにスループットが0 B/s」という一見矛盾した見え方は、ストレージI/Oキューが詰まり、OSがデバイス応答待ちで足踏みしている状態を示します。NVMeではコマンドをキューに投入→デバイスが完了通知(Completion Queue)を返す流れですが、PCIeレイヤでのエラー・再送・リンクリセットが発生すると、OS側は「待っている間もI/O資源を占有」するため使用率は100%に見えつつ、実際の転送量は伸びない=0 B/sという状況になります。
- WHEA ID 17は、PCIeの物理/データリンク層で訂正可能なエラー(例:LCRCなど)が多発しているサイン。
- StorNVMe 129/11は、WindowsのNVMeミニポートドライバーがデバイス応答停止を検知し、ポート/コントローラのリセットやタイムアウトに踏み切った痕跡。
- Disk 50/51は、その結果としてFS(NTFS)レイヤから見える読み書き失敗の二次的症状。
つまり、論点はディスクI/O自体ではなく、NVMeがぶら下がるPCIe経路の安定性にあります。
イベントログの読み解き早見表
| イベント | 意味 | 主に疑うべき範囲 | 再現しやすい負荷 |
|---|---|---|---|
| WHEA Logger ID 17 | PCIe Root Portで訂正済みのハードウェアエラー(CRC再送など)を検知 | PCIeリンク品質(配線/スロット/コントローラ/電源安定度) | 高頻度I/O + GPU負荷同時(クロック変動・電流変動) |
| StorNVMe ID 129/11 | デバイス応答停止→ポート/コントローラのリセットが発動 | NVMeコントローラ、ドライバ、リンクリセット誘発の外乱 | ゲーム起動・大容量アセットのストリーミング |
| Disk ID 50/51 | 高レイヤから見える読み書き失敗/遅延の警告 | 上記の結果(根はPCIe/NVMe側) | I/O集中時全般 |
根本原因の仮説:SSD単体ではなく「PCIe経路の不安定」
- 複数SSD(MSI M480 PRO → RMA → 一時改善、のちWDC SN530でも再発)で持ち回り。SSD個体故障一点狙いでは説明しづらい。
- WHEA 17とStorNVMe 129/11の組合せはPCIe通信の再送・タイムアウト・リンクリセットの典型。
- 発生が断続的かつ再起動で復帰する点からも、電源瞬断/クロック遷移/メモリエラーに起因する一過性のI/O化けを疑うのが合理的。
優先して切り分けたいのはマザーボード/CPU(内蔵PCIe/DMI)/電源/メモリの4点です。ソフト層の施策(再インストール、レジストリ調整、サービス停止)は、既に十分試行済みで効果薄なため打ち止めで構いません。
実践フロー:最短で原因に辿り着く切り分け手順
| 段階 | 対処内容 | ポイント |
|---|---|---|
| 1. 根本原因の推定 | SSD間で持ち回り → PCIe経路の不安定を優先。WHEA 17 + StorNVMe 129/11はPCIe通信エラーの示唆。 | ソフト側深掘りは切り上げ、ハード/ファームに注力。 |
| 2. BIOS/UEFI調整 | PCIe速度をGen3固定。ASPM・CPU C‑State・PCIe電源管理を全無効。メモリのXMP/EXPOを切りJEDEC定格へ。 | クロックと省電力遷移を緩め、リンクの安定度を最優先。 |
| 3. 最小構成テスト | SSD1台・RAM1枚・GPU・キーボード/マウスのみ。USBや増設カードは撤去。可能ならiGPUで起動しGPUを外す。 | 干渉源を排除し、原因コンポーネントを露出。 |
| 4. メモリ診断の再実施 | MemTest86でCleanでも油断せず、スロット/枚数を変えて実機で再現性確認。本事例は「RAMを1枚外したら完治」。 | 軽微なメモリエラーはI/O集中時のみ顕在化しやすい。 |
| 5. RMA・修理判断 | 改善なし → マザーボード or CPUのPCIeコントローラ不良を疑い、詳細ログ同梱でRMA申請。ノートは即RMA推奨。 | 部品交換が最終手段。自己分解不可の筐体は無理をしない。 |
BIOS/UEFIで見るべき具体項目(ASUS系の例)
- PCIe Link Speed:Auto/Gen4 → Gen3(安定度優先)。
- ASPM(L0s/L1/CPPC):Disabled。
- Native PCIe Power Management:Disabled。
- CPU C‑States:Disabled(一時評価)。
- DRAM:XMP/EXPOをOFF、JEDEC定格で検証。
- iGPU有効化:一時的にdGPUを抜き、iGPU(UHD 770)で起動して再現確認。
メニュー名称はBIOSバージョンで前後しますが、概ね「Advanced」「PCI Subsystem」「CPU Configuration」「Platform Misc」付近に集約されています。評価が安定したら、項目を一つずつ元に戻し、どの設定で再発するかを丁寧に逆探索してください。
最小構成の鉄則
- ドライブは検証対象のNVMeのみ。SATAやUSBストレージは全撤去。
- RAMは1枚挿し(A2スロット推奨)→ 切り替えテストで個体不良をあぶり出す。
- 拡張カードは外す。ケース外でベンチテーブル運用できれば理想。
- 可能なら別系統の高品質PSUで短時間の代替給電試験。
なぜ「メモリ不良」でNVMeが落ちるのか(仕組みから説明)
NVMeのデータ転送はCPUとメモリ間のDMA(Direct Memory Access)で動きます。ストレージI/O経路は「NVMeコントローラ ⇔ PCIe ⇔ CPU/DMI ⇔ メモリ」という一本の鎖で、いずれかのリンクが不安定だとNVMeのコマンド完了通知やデータ整合性が崩れ、タイムアウトやリンクリセットを誘発します。
- 軽微なビット化け:ECCなしの一般的なDDR4では、まれなビット化けがI/O集中時にだけ顕在化し、NVMeコマンドが完了しない/完了通知が欠落する。
- IOMMU(VT‑d)マッピングの不整合:メモリ不具合でページテーブルが乱れると、DMA先が不正→コントローラがハング→StorNVMe 129/11へ。
- 結果:OSはデバイス応答を待ち続け、使用率100%・0 B/s、最終的にドライブが見失われる(リセットで復帰)。
本事例はまさにこのパターンで、RAMを1枚外しただけで完治。MemTest86で異常が出ないケースでも、実アプリ負荷(ゲームの巨大アセットストリーミング)のほうが敏感に不具合を炙り出す場合があります。
電源と温度:見落としがちな「品質」の話
- 電源品質:容量だけでなくレギュレーションの良さ(変動・リップル)が重要。瞬間負荷変動で電圧が崩れるとPCIeのエラーレートが上昇します。80 PLUS Platinum以上やハイエンド相当の実力が望ましい。
- NVMe温度:70 °C前後でサーマルスロットリングが始まる製品が多く、ヒートシンク装着/エアフロー改善は基本対策。
- ケースの正圧化:吸気>排気で埃流入を抑えつつ、M.2周辺の風路を作る。
再現試験のテンプレート(手順書)
- UEFIを「Gen3/省電力OFF/JEDEC」にして保存・再起動。
- 最小構成(NVMe 1台、RAM 1枚、iGPUまたはdGPU単体)で起動。
- 空のテスト用フォルダにゲームランチャーを新規導入し、タイトルキャッシュの初回生成(ストレージ負荷が高い)で挙動観察。
- イベント ビューアーをリアルタイム表示で開き、WHEA 17/StorNVMe 129/11/Disk 50/51の発生時刻をメモ。
- RAMを入れ替え・スロット変更・本数変更 → どの組み合わせで発生/沈静化するかを表に記録。
| RAM構成 | 発生の有無 | メモ |
|---|---|---|
| モジュールAのみ(A2) | — | 安定/不安定 |
| モジュールBのみ(A2) | — | 安定/不安定 |
| A+B(デュアル) | — | 発生時刻とイベントID |
| Aのみ(B2) | — | スロット起因を同時確認 |
PowerShellでログ・指標をまとめて採取する
復旧やRMA時に根拠を示すため、以下の簡易スクリプトで必要ログを一括採取しておくと説得力が増します。
イベントログ(WHEA/StorNVMe/Disk)抽出
# 管理者PowerShell
$from = (Get-Date).AddDays(-7)
$whea = Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=$from; ProviderName='Microsoft-Windows-WHEA-Logger'} |
Where-Object {$_.Id -eq 17} | Select-Object TimeCreated, Id, Message
$stor = Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=$from; ProviderName='stornvme'} |
Where-Object {$_.Id -in 11,129} | Select-Object TimeCreated, Id, Message
$disk = Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=$from; ProviderName='disk'} |
Where-Object {$_.Id -in 50,51} | Select-Object TimeCreated, Id, Message
$whea + $stor + $disk | Sort-Object TimeCreated | Format-Table -Auto
ストレージ信頼性カウンタ
# 対応デバイスではSMART相当のカウンタを取得
Get-StorageReliabilityCounter -PhysicalDisk (Get-PhysicalDisk) |
Select-Object FriendlyName,Temperature,CriticalErrorCount,ReadErrorsTotal,WriteErrorsTotal,Wear | Format-Table -Auto
パフォーマンスログ(I/O待ち)
# 10分間だけI/O待ちやディスクキュー長をロギング
logman create counter IOTrace -o "$env:TEMP\IOTrace.blg" -c "\LogicalDisk(_Total)\Avg. Disk sec/Transfer","\LogicalDisk(_Total)\Current Disk Queue Length" -f bincirc -max 20 -si 00:00:01
logman start IOTrace
Start-Sleep -Seconds 600
logman stop IOTrace
これらの出力と発生時刻をテスト表と紐付けておくと、ハードRMAでも説明が通りやすくなります。
BIOS/UEFI調整のコツ(安定性最優先チューニング)
- Gen3固定:Gen4で不安定でもGen3なら安定するケースが多い。速度は下がるが、まずは落ちないことが最優先。
- ASPM・C‑State OFF:原因切り分けのための一時措置。安定が確認できたら、一項目ずつ戻す。
- DRAMは定格:XMPは最後に戻す。戻した時点で再発するならメモリ/IMC限界の可能性。
- DMI/PEGとM.2の競合:GPU側のリンク速度・レーン占有でPCH側の余裕が変わることがある。iGPU検証は価値が高い。
誤解しがちな対策:効果が薄い/副作用が出やすいもの
- Windowsの再インストール連打:ハード起因なら効果がない。1回のクリーンインストールで十分。
- 不要サービス大量停止:問題の本質はPCIe/NVMeの信号品質であり、サービス停止では解決しない。
- AHCIドライバ入れ替え:NVMeはAHCI経由ではない。方向違い。
- SSDを片っ端からRMA:持ち回るならSSD単体の確率は低い。先にメモリ・電源・マザーから疑う。
ノートPCで同様症状が出たら
ASUS ROG Strix G16などノートでも、ゲーム起動直後の使用率100%・0 B/s → アプリクラッシュ → ドライブ消失という報告があります。ノートは部品交換の自由度が低く、開封で保証リスクも高いため、即RMAの判断が合理的です。可能なら、上記のPowerShellログと再現手順を添えて申請しましょう。
チェックリスト:再発防止と安定化のToDo
- 電源:十分な容量+高品質(80 PLUS Platinum以上相当)。瞬時負荷に強いモデルを。
- メモリ:信頼ブランド・同一ロット・QVL準拠。疑わしければまずは1枚運用で安定確認。
- NVMe冷却:マザーボード付属のM.2ヒートシンク+ケースファンで風を当てる。
- 配線と固定:M.2スクリューの締め直し、ライザーカードや変換アダプタの排除。
- UEFI更新:ストレージ互換性改善が含まれる場合がある。更新後は最適化設定をやり直し。
- OS安定化:不要なチューニングは避け、標準NVMeドライバでまず検証。
FAQ:現場でよく出る質問
Q. タスクマネージャーの使用率100%はバグ表示?
A. いいえ。I/Oキューが塞がっている(応答待ち)状態でも使用率は100%になります。スループットとは別概念です。
Q. MemTest86でエラー0なのにメモリが犯人?
A. あり得ます。I/O集中・高温・クロック変動などの実アプリ条件でのみ顕在化する軽微な不良があります。枚数/スロットを替えた実機テストが有効です。
Q. 先にSSDを全部RMAに出すべき?
A. 持ち回る場合は非効率。メモリ → 電源 → マザーの順で切り分けてから判断してください。
Q. BIOSはどこまで戻せばよい?
A. まずは定格・省電力OFF・Gen3固定。安定を確認後、1項目ずつ戻して再発ポイントを特定します。
Q. ドライブが消えた直後にやることは?
A. 再起動前にイベントログ採取(WHEA 17/StorNVMe 129/11/Disk 50/51)と時刻メモ。可能ならPowerShellで即時出力。
Q. ゲーム固有の問題では?
A. ゲームは巨大アセットのストリーミング負荷が高く、問題を露呈しやすいトリガーに過ぎません。根はハード/リンク品質です。
ケーススタディ(本記事の実機):最終的な解決まで
- SSD移設・RMA・OS再インストールでも完全解消せず。
- WHEA 17 + StorNVMe 129/11が再現 → PCIe経路に焦点。
- UEFIをGen3固定、ASPM/C‑State無効、メモリ定格で再試験 → 発生頻度減少。
- 最小構成へ(NVMe 1台、RAM 1枚、iGPU) → 現象が消える。
- RAMを入れ替え試験 → 特定モジュール挿入時のみ再発。当該モジュールを撤去で完治。
このように、理詰めの順序で削っていけば、時間と費用を最小化しながら原因に到達できます。
トラブルシューティング早見表(原因×対処)
| 兆候 | 疑う場所 | 試す設定/対処 | 判定の目安 |
|---|---|---|---|
| WHEA 17が連発 | PCIeリンク品質 | Gen3固定/ASPM OFF/PSU交換試験 | 発生頻度が減ればリンク品質起因の可能性大 |
| StorNVMe 129/11が同時に出る | NVMeコントローラ or 外乱 | 最小構成/iGPUでGPU排除/NVMeを別スロット | 構成を変えても出る→NVMe以外の外乱が濃厚 |
| RAMを1枚にすると消える | メモリ/IMC | モジュール入替/スロット変更/定格運用 | 特定組み合わせでのみ発生→メモリ不良の線が強い |
| PSU交換で安定 | 電源品質 | 高品質PSUで代替給電 | 瞬停・電圧変動がPCIeエラーを誘発していた可能性 |
RMA申請のための「伝わる」資料の作り方
- 再現手順:タイトル起動→キャッシュ生成→クラッシュの秒単位の時系列。
- ログ添付:WHEA 17/StorNVMe 129/11/Disk 50/51の一覧、PowerShell出力。
- 構成表:マザーBIOSバージョン、RAM型番・ロット、PSU型番、M.2スロット位置。
- 切り分け結果:RAM AでOK/RAM BでNGなど、誰が見ても再現する書き方。
再発防止の運用Tips
- アップデートの順番:UEFI → チップセット → GPU → Windows(セキュリティ)→ ゲーム。
- 温度監視:ゲーム中のNVMe温度・CPU Package温度を定点観測。
- ケーブル/固定:PCIe補助電源・M.2スクリュー・バックプレートの締め直し。
- 設定の記録:安定構成をバックアップ(UEFIプロファイル、PowerShellのエクスポート)。
まとめ
「ディスク使用率100%→0 B/s→クラッシュ→ドライブ消失」は、OSやアプリの問題に見えても、実態はPCIe/NVMe経路の不安定に起因することが多い症例です。特にWHEA 17 + StorNVMe 129/11の組み合わせは、リンク品質低下・電源瞬断・メモリ不良などハード側の外乱を強く示唆します。本記事の事例では不良メモリモジュールの撤去で完全解決しましたが、同じ症状でもマザーボードや電源が原因となる例は珍しくありません。
紹介した5段階の切り分けフロー(Gen3固定/省電力OFF/最小構成/メモリ入替/RMA)を順に実施すれば、無駄なRMAやOS再インストールを最小化しながら、原因の本丸に短時間で到達できます。ゲーム用途はI/Oと電源変動が激しく、潜在的な不具合を露呈しやすい環境です。だからこそ、「安定最優先」→「段階的に元へ戻す」という原則で、堅牢な常用環境を築いてください。
付録:トラブルシュート手順のチェックシート(印刷用)
| 項目 | 実施内容 | 結果 | メモ |
|---|---|---|---|
| UEFI Gen3固定 | Auto/Gen4→Gen3 | ✔/✖ | |
| ASPM/C‑State無効 | 一時的に全無効 | ✔/✖ | |
| DRAM定格 | XMP/EXPO OFF | ✔/✖ | |
| 最小構成 | NVMe 1台・RAM 1枚・iGPU | ✔/✖ | |
| RAM入替 | Aのみ/Bのみ/A+B | ✔/✖ | |
| PSU代替 | 高品質PSUで試験 | ✔/✖ | |
| ログ採取 | WHEA/StorNVMe/Disk | ✔/✖ | |
| RMA準備 | 再現手順・構成表 | ✔/✖ |

コメント