SSDが突然消失してブルースクリーン（KERNEL_DATA_INPAGE_ERROR 0x7A/0xC000000E）：SATA 500GBで起きる原因と対処・再発防止ガイド

作業中にいきなりSSDが消え、アプリが落ち、KERNEL_DATA_INPAGE_ERRORでブルースクリーン──。ケーブル交換やポート変更をしても直らない。そんな“断続的に消えるSSD”は、OS設定・ログ・SMART・配線・ファームウェアを順に当てていくと、短時間で原因が固まります。本記事は500GBクラスのSATA SSDを前提に、実際の現場で役立つ切り分けと再発防止の運用までを一気通貫で解説します。

ケースの概要（前提条件と症状の整理）

500GB SATA SSDを使用。ファイルの読み書き中に突然ドライブが認識されなくなる。
アプリがクラッシュし、PCはブルースクリーン：KERNEL_DATA_INPAGE_ERROR (0x7A)。ダンプのステータスに0xC000000Eが含まれる。
ケーブル交換／ポート変更／ドライバ更新／ページファイル移動を実施済みも改善なし。
デバイスマネージャーに灰色表示（無効・切断状態）の重複ドライブが残る。
PSU（電源）や他のSSD 3台には異常がない。

この症状が示唆するもの：0x7A／0xC000000Eの意味

KERNEL_DATA_INPAGE_ERROR (0x7A)は、OSが「ストレージからメモリへ必要なページを読み戻せなかった」状態で発生します。パラメータのステータスが0xC000000E (STATUS_NO_SUCH_DEVICE)の場合、OSから見て「対象デバイスが存在しない/消えた」と解釈されるため、SATAリンク断・電源瞬断・SSDコントローラのハング/リセットが強く疑われます。

観測症状	よくある原因	確認ポイント
0x7A + 0xC000000E	SSDが瞬断/内部リセット、SATAリンク断、電源供給不安定	イベントログ（ディスク/StorAHCI/iaStor）、SMART(187/197/198/199)、配線
灰色の重複ドライブ	切断・再接続によるゴーストデバイスの残骸	「隠しデバイスの表示」で非表示デバイスを整理
他のSSDは安定	個体差（対象SSDのコントローラ/ファームが不安定）	対象SSDのみでエラーが再現するかを交換検証

最優先はデータ保全：まず安全に退避する

原因追跡より先に、破損・消失のリスクを最小化しながらバックアップを取りましょう。不安定なSSDに負荷をかけると途切れやすくなります。次の工夫で退避成功率が上がります。

低速インターフェース経由で読む：外付けUSB 2.0ドックや古いUSB-SATAブリッジを使うとスループットは落ちますが、転送コマンドの深さが浅く、リンク再ネゴシエーションの頻度が減るため切断しにくくなります。
再開可能なコピーを使う：WindowsならRobocopyでエラー時に即座に次ファイルへ進めます。

robocopy E:\ D:\Backup\ /E /COPY:DAT /R:0 /W:0 /LOG:C:\robocopy.log

※ E: が不安定なSSD、D: が退避先。/R:0 /W:0で再試行しない（固まらない）。

OS側で今すぐやる緊急回避（再発時の被害を最小化）

問題のSSD上のページファイルを無効化し、システムドライブ（C:）に固定サイズ（例：512MB）で置く。ページングI/Oが問題のSSDに飛ばなくなります。
小容量（ミニ）ダンプを書き出す設定にする。障害解析に必要十分で、I/O負荷も軽い。

設定手順（GUI）

システムの詳細設定 > [詳細設定] タブ > [パフォーマンス] > [詳細設定] > 仮想メモリで、問題のSSDのチェックを外す。C: にカスタムサイズ（初期/最大とも512MBなど固定値）を指定。
[起動と回復] > [デバッグ情報の書き込み] を小さいメモリダンプ（256KB）に設定。ダンプ保存先 C:\Windows\Minidump を確認。

設定手順（コマンド）

:: ミニダンプ（256KB）を有効化（DebugInfoType=3）
wmic RECOVEROS set DebugInfoType = 3

:: ミニダンプ保存フォルダを指定（既定C:\Windows\Minidump）
wmic RECOVEROS set MiniDumpDirectory = "C:\Windows\Minidump"

:: 書き込み後の自動再起動を有効（必要に応じて）
wmic RECOVEROS set AutoReboot = True

イベントログで“消え方”の型を掴む

ブルースクリーンの前後で次のイベントが並ぶことが多いです。型がわかると配線・電源・SSD本体の優先度が決まります。

イベントID（代表例）	ログソース	内容の要旨	示唆
157	Disk	“ディスク X がサプライズリムーブされました”	物理/リンク瞬断やSSDの内部リセット
51 / 7 / 55	Disk / Ntfs	遅延書き込み失敗、I/Oエラー、NTFS不整合	メディア/コントローラ不良や電源不安定
129	storahci/iaStorA	デバイスリセット（ポートのリセット発行）	リンク層の問題やSSD応答停止
153	Disk	長時間のコマンド遅延	内部GC/エラー訂正で遅延、過熱

ログ抽出はPowerShellが便利です。

# 直近3日のDisk/StorAHCI/iaStor関連をざっと確認
Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=(Get-Date).AddDays(-3)} |
  Where-Object {$_.ProviderName -match 'Disk|storahci|iaStor'} |
  Select-Object TimeCreated, Id, ProviderName, Message |
  Sort-Object TimeCreated

ハードウェア診断：配線・ポート・電源・温度の実地チェック

配線とポートの入れ替え検証

SATAデータケーブル：新品へ交換済みでも、別メーカー/別ロットで再試す。ラッチ付き（抜け防止）推奨。
マザーボード側SATAポート：他のポートに移す。チップセット/サードパーティコントローラ混在のボードはチップセット優先。
電源分岐：5Vラインは直系のコネクタから取り、Y分岐やハブ的配線は避ける。

温度とエアフロー

2.5インチSATAでも夏場の密閉ベイでは60〜70℃に達することがあります。70℃超が常態なら、サーマルスロットリングやエラー訂正の過多で応答が止まりやすくなります。吸排気ファンの風をベイに通し、ベイ間のスペーサで隙間を作ると改善します。

電源品質

PSU自体は正常でも、5Vの瞬低やSATA電源コネクタの接触が悪いとSSDがリセットします。
別系統のSATA電源ケーブルへ挿し替え、酸化した端子は接点復活を実施（液剤は微量）。

SMARTで“ケーブル由来か本体由来か”を見極める

CrystalDiskInfo等でSMARTを確認します。次の属性が要点です。

ID	属性名（代表）	見方の要点	典型的対処
05	Reallocated Sector Count	SSDでも閾値越えは注意。閾値に近づく増加は寿命/故障傾向。	早期バックアップ、交換検討
187	Reported Uncorrectable Errors	修正不能I/O。増加が止まらないならメディア/コントローラ不良濃厚。	データ退避後に交換/メーカー診断
197	Current Pending Sector	読めない論理ブロックの保留。SSDでの継続増は危険サイン。	バックアップ、完全フォーマット/セキュアイレース後も増えるなら交換
198	Uncorrectable Sector Count	修復不能の累積。徐々に増えるなら限界接近。	速やかに交換
199	UDMA CRC Error Count	ケーブル/コネクタ由来が多い。増加が止まれば“大本は配線”。	ケーブル・ポート変更、ラッチ付ケーブル、埃除去
241/242	総書き込み/読み出し量	耐久指標（TBW）に対する消耗度の目安。	TBW上限が近い場合は計画交換

例として、Samsung 860 EVO 500GBの公称TBWは約300TBです。総書き込みがこの値に迫る、あるいは超えている場合は寿命要素を疑い、重要用途から退役させる判断材料になります。

デバイスマネージャーの灰色ドライブ（ゴースト）を整理する

切断/再接続が繰り返されると、同一SSDでも別経路・別識別子として非表示デバイスが積み上がります。視認性を高めるため、以下で整理します。

Win + R > cmd
次を順に実行：

set devmgr_show_nonpresent_devices=1
start devmgmt.msc

デバイスマネージャーで [表示] > [非表示のデバイスの表示] をON。
ディスクドライブ／ストレージコントローラ配下で灰色の重複を右クリック > [デバイスのアンインストール]。
※ 現在接続中の正規デバイスを誤って削除しないように、シリアルや型番を照合してください。

OSのI/O負荷を抑えながら動作確認する

書き込みキャッシュポリシー：対象SSDは一時的に「デバイスの書き込みキャッシュを無効にする」を検討（デバイスのプロパティ > ポリシー）。切断時の整合性を保ちやすくなります。
電源プラン：高パフォーマンス/最小省電力設定にし、ストレージのリンク省電力を弱めます（AHCI LPMが強すぎるとリンク断リスクが上がる構成があるため）。
CHKDSKの注意：メディア不良が疑われる段階で chkdsk /f /r をかけると大負荷でとどめを刺すことがあります。バックアップ完了までは /scan など読み取り中心に留めます。

バックアップ後：完全フォーマット／セキュアイレース／ファームウェア更新

データ退避が完了し、検証用に使える状態になったら次を順に実施します。

完全フォーマット（フルフォーマット）
Windowsのフルフォーマットは全LBAsへの書き込みを伴い、論理的に不良ブロックの洗い出しと内部再配置（SSD側の管理領域による）を促します。完了後にSMARTの197/198が増え続ける場合は物理劣化が濃厚です。
セキュアイレース/サニタイズ
メーカー提供ツールで“出荷時初期化”に近い消去を実行。マッピングテーブルや保留ブロックをフラットにできます。実行中に切断する可能性が少しでもあるなら中止（ブリック化回避）。
ファームウェア更新
特定ロットの安定性問題がファーム更新で解消することがあります。必ずバックアップ完了後に行い、電源断リスクの低い環境（UPS等）で実施します。

改善しない場合：交換判断とRMA/修理の進め方

以下のいずれかなら物理故障の線が濃厚です。業務用途では迷わず交換しましょう。

ログの157/129が繰り返し、SMARTの187/197/198が増え続ける。
ベンチマーク/コピーでコマンドタイムアウトが頻発（イベント153が多発）。
別PC・別OS・別ケーブルでも同一症状。

RMAや販売店検査へ出す際は、イベントログ抜粋・ミニダンプ・SMARTスクリーンショット・再現手順をまとめて添付すると、交換判断が早くなります。

“SATAリンク断”と“SSD本体不良”を見分ける実践的フロー

手順	目的	判定の目安	次アクション
別ケーブル/別ポートで再現	物理接続要因の排除	UDMA CRC(199)が増え続ける→配線要因濃厚	ケーブル/ポート固定で安定化 or 交換
他PC/他OSで再現	ホスト側要因の排除	環境を変えても落ちる→SSD本体	バックアップ＆交換/RMA
低速USBブリッジ経由で読み出し	リンク負荷の低減	USBで安定・SATAで不安定→SATAリンク層疑い	SATA配線/電源/ポートの見直し
フルフォーマット/セキュアイレース後のSMART	メディア健全性の確認	187/197/198が増加継続→メディア劣化	交換確定

WinDbgでダンプを素早く読む（要点だけ）

ミニダンプをWinDbgで開き、以下を確認します。

!analyze -v

BugCheck 7Aで、STATUS_NO_SUCH_DEVICE (c000000e) と表示されれば「デバイス消失」による読み戻し失敗。
スタックにStorAHCI/iaStor経由のResetやTimedOut文字列が見える場合、リンクやSSD応答停止の線がより濃くなります。

ページファイルの運用指針（再発防止）

ページファイルは常用・高信頼のシステムSSD上に固定し、問題がある/負荷が高いデータ用SSDへは置かない。
最小/最大を固定（例：RAM容量の数百MB〜数GB）。断続的な拡張/縮小I/Oを避ける。
クラッシュダンプ取得要件を満たす容量は維持（ミニダンプなら小さくて良い）。

“書き込みが多い作業”はTBWの大きいドライブへ逃がす

小容量SSDはオーバープロビジョニングが少なく、ランダム書き込みや一時ファイルの負荷が集中すると消耗が早まります。動画キャッシュやビルドキャッシュ、仮想化の差分ディスクなど書き換え頻度が高い用途はTBWの大きいSSDか、少なくとも容量の大きいモデルへ移すのが定石です。

Windowsでの確認・調整に使えるコマンド集

TRIMが有効か確認

fsutil behavior query DisableDeleteNotify
:: 0 = 有効（推奨）、1 = 無効

物理ディスクの健全性（概況）

wmic diskdrive get model,serialnumber,status

※“OK”でも詳細はSMARTツールで確認。

PowerShellで物理ディスクの状態

Get-PhysicalDisk | Select-Object FriendlyName, MediaType, Size, HealthStatus, OperationalStatus

イベントの簡易抽出（ストレージ関係）

Get-WinEvent -FilterHashtable @{LogName='System'; ID=157,51,129,153} |
  Select-Object TimeCreated, Id, ProviderName, Message |
  Sort-Object TimeCreated

“やってはいけない”チェックリスト

不安定なSSDにベンチ連打：連続I/Oで切断→ファイル破損の悪循環。
バックアップ前の強制修復：chkdsk /f /rやパーティション操作は最後の手段。
ファーム更新を最初に試す：途中切断で失敗すると復旧が難しくなる。必ず退避後。
電源のY字分岐多用：5Vラインの電圧低下や接触不良の温床。

交換時の判断基準（実務向け）

基準	目安	備考
SMARTのエラー属性	187/197/198が増加傾向	退避後に交換確定
UDMA CRC(199)	配線交換後も増える	マザボ/SSD側コネクタを疑う
TBW消耗	公称TBWの8〜9割到達	重要用途から計画退役
温度	高負荷で70℃付近に達する	ケース/ベイのエアフロー改善でも変わらなければ交換
再現性	別PC・別OSでも同様	SSD本体不良で確定

復旧後の再発防止：運用テンプレート

ページファイルはシステムSSDに固定：データSSDに置かない。
月次SMARTチェック：しきい値前からトレンドを見る（増え方が重要）。
温度管理：ベイ間スペーサ、吸排気強化、ケーブルのエアフローブロックを排除。
バックアップ二重化：RAID1やクラウド/オフサイト併用で“人災・機材災害”の両面に備える。
ログ保全：イベントログとミニダンプを自動保存。切断発生時刻と突き合わせ。
書き込み多い用途の分離：ブラウザ/動画/ビルド/VM一時領域はTBWの大きいSSDへ。

“なぜUSB2.0ドックが効くのか”の技術的背景

高機能なUASPブリッジやNCQを活かすSATA直結はスループットが高い一方、深いキューと高速リンクで“切断→再ネゴシエーション→OSタイムアウト”の連鎖が起きやすいことがあります。USB 2.0相当の低速経由ではコマンド深度が浅く、SSD内部のエラー訂正やGCが追いつきやすいため、読み切る確率が上がるという現場知見があります。速度より成功率を優先する局面で有効です。

具体的な復旧シナリオ（サンプル手順）

いますぐバックアップ：USB 2.0経由 + Robocopyで重要データから。失敗したファイルはログに残して後で個別に再トライ。
ページファイルの移動/固定：問題SSDから外し、C: 固定 512MB。
ミニダンプを有効化：次回発生時の根拠確保。
配線・電源の再構成：ラッチ付ケーブル、別ポート、別SATA電源系統。
SMARTトレンド観測：199が止まれば配線、187/197/198が増え続ければSSD。
バックアップ完了後：フルフォーマット→セキュアイレース→最新FW。
なおれば継続利用（要監視）、だめなら交換：RMA/新品へ置換。

補足：0x7Aのパラメータは何を語るか

0x7Aの第1パラメータは原因の分類、ステータスコードはI/Oエラーの詳細を表します。0xC000000Eは「デバイスが存在しない（消えた）」で、コントローラ暴走・リンク断・電源瞬断と符合します。他方、0xC000009C/0xC0000185等ならメディア/ケーブル色が強まります。ミニダンプとイベントログを突き合わせると、再現の度に同じ型のエラーが出ているかが確認できます。

FAQ：現場でよく出る質問

Q. CHKDSKで直りますか？

A. 直りません。ファイルシステムの整合性を保つツールで、物理層やリンク断は解決できません。むしろ負荷が増えて切断しやすくなります。退避後に最小限で実施してください。

Q. ファーム更新は万能ですか？

A. いいえ。ファーム既知の不具合なら効きますが、メディア劣化や電源問題には無力です。まずはバックアップ、次に配線/電源/温度、最後にファームです。

Q. グレー表示の重複ドライブは放置して良い？

A. 動作には直結しませんが、トラブル時の識別を難しくします。整理しておくと解析がスムーズです。

まとめ：今回のケースの処方箋

0xC000000Eはデバイス消失のサイン。SSDコントローラ/ファームかSATAリンク/電源が主因。
データ保全を最優先（低速経由＋再開可能コピー）。
ページファイルを問題ドライブで無効化し、ミニダンプ有効化で根拠を蓄積。
SMARTの187/197/198/199とイベント157/129/153で“配線か本体か”を決め打ち。
バックアップ後にフルフォーマット→セキュアイレース→FW更新。改善しなければ交換。
以後はTBWと温度の管理、ページファイルの置き先、書き込み負荷の分散、二重化バックアップで再発を避ける。

付録：チェックと対策の早見表

優先度	アクション	目的	効果	リスク/注意
高	USB2.0経由でバックアップ	データ保全	切断率低下・コピー完走率向上	遅い（だが安全）
高	ページファイル移動・固定	BSOD再発時の被害縮小	問題SSDへのI/O削減	適正容量の確保
高	ケーブル/ポート/電源系統の見直し	リンク断排除	199の増加停止で効果判定可	内部配線の手戻りに注意
中	SMART/イベントログのトレンド監視	原因の型を特定	交換判断の根拠に	ツールの信頼性・解釈の正確さ
中	フルフォーマット/セキュアイレース	論理配置の再構築	軽微な論理崩れなら改善	寿命を少し消費、途中切断は厳禁
中	ファームウェア更新	既知不具合の是正	安定度向上の可能性	停電・切断リスクに備える
低	ケース/ベイのエアフロー最適化	温度安定	遅延/タイムアウト低減に寄与	効果は環境依存

おわりに

“ランダムに消えるSSD”に正面から向き合うには、データ保全→ログとSMART→配線/電源→FWの順で淡々と潰すのが近道です。0x7A/0xC000000EはOS側の論理不具合ではなく、I/O経路のどこかが落ちていると読むのが正解。今回の手順で原因の芯を掴み、交換するなら迷いなく、継続利用するなら根拠をもって──という判断ができるはずです。

実践メモ：本記事の簡易チェックリスト

ミニダンプ（256KB）有効化／保存先確認
ページファイルをC:固定（問題SSDでは無効）
USB2.0経由＋Robocopyで緊急退避
イベント157/129/153の有無を確認
SMART：187/197/198/199/温度/TBWを確認
ケーブル・ポート・電源系統の入替検証
フルフォーマット→セキュアイレース→FW更新（退避後）
改善せねば交換（RMA/新品）
運用：TBWの大きいSSDへ書き込み負荷を逃がす／月次SMART／二重バックアップ

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。