Windows 10 / 11 をクリーンインストールしたのに、突然ブルースクリーン「KERNEL_SECURITY_CHECK_FAILURE（Bugcheck 0x139）」が出て再起動してしまう…。本記事では、このエラーの正体と典型的な原因、現場での切り分け手順、ミニダンプ解析のポイントまで、実務で使えるレベルで整理します。
症状：Bugcheck 0x139（KERNEL_SECURITY_CHECK_FAILURE）でPCが再起動する
今回のケースでよく見られるのは、次のような状況です。
- Windows をクリーンインストールした直後はしばらく安定している
- 数日〜数週間後、突然ブルースクリーンが発生し自動再起動
- イベントビューアーの「システム」に次のようなログが記録される
ソース：BugCheck
メッセージ：The computer has rebooted from a bugcheck.
Bugcheck: 0x00000139 (0x..., 0x..., ...)
ミニダンプ: C:\Windows\Minidump\xxxxxx.dmp
過去にも同じPCでクラッシュが出ており、OSを再インストールしても再発する場合、単なる「Windows の不調」ではなく、ドライバーやハードウェア側に根本原因がある可能性が高いです。
Bugcheck 0x139（KERNEL_SECURITY_CHECK_FAILURE）とは何か
0x139 = KERNEL_SECURITY_CHECK_FAILURE は、Windows カーネルが「内部の整合性チェックに失敗した」ことを検知してシステムを強制停止した際のバグチェックコードです。
ざっくり言うと、
- 本来アクセスしてはいけないメモリを触った
- すでに解放済みのメモリを書き換えた（ダブルフリーなど）
- カーネル内部構造体が壊れていて辻褄が合わない
といった「メモリ破壊」系の挙動を検知したときに発生するエラーです。
主な原因カテゴリ
0x139 が出る典型的な原因は、次の4パターンに集約できます。
- サードパーティ製ドライバーのバグ・不正アクセス
… 古いドライバーや相性の悪いドライバーがカーネルメモリを壊す。 - メモリ（RAM）の物理的な不良・相性・OC/XMPの不安定
… 実際にビット化けが起きてカーネル構造体が壊れる。 - ストレージやファイルシステムの破損
… システムファイルが壊れていて、結果的にカーネルが異常な動作をする。 - 過度なオーバークロック・電源不足・熱暴走
… 高負荷時にのみメモリやCPUが誤動作し、結果として 0x139 が出る。
よくあるのは「ミニダンプを WinDbg で開いても ntoskrnl.exe しか出てこない」というパターンです。この場合、カーネルが「壊れていること」はわかるが、壊した犯人までは一発で特定できないことが多く、複数回分のダンプと切り分けが重要になります。
| カテゴリ | 具体例 | 0x139 につながるパターン |
|---|---|---|
| ソフトウェア | 古い GPU ドライバー、チューニングツール、仮想化ソフト、アンチウイルスなど | カーネルモードドライバーが不正なメモリアクセスを行い、カーネル整合性チェックに引っかかる |
| メモリ | 不良メモリ、相性問題、XMP/EXPO 設定、メモリ OC | 実データが壊れ、正常なドライバーでも異常なデータを処理させられてクラッシュ |
| ストレージ | 劣化した SSD/HDD、SATA ケーブル不良、コントローラーの不具合 | システムファイル破損 → カーネルやドライバーが壊れたコードを読み込む |
| 電源・熱 | 電源ユニット劣化、電力不足、冷却不足 | 負荷時に瞬断や誤動作が発生し、ランダムなメモリ破壊として現れる |
まず最初にやるべき設定と基本対策
再発待ちの「手ぶら時間」を無駄にしないために、最初に次の5つを必ずやっておきます。
ミニダンプを確実に残す設定
原因調査の生命線はミニダンプです。まずは確実に保存されるよう、設定を確認します。
- 「スタート」ボタンを右クリック → 「システム」を開く
- 右側（または下部）の「関連設定」から「システムの詳細設定」を開く
- 「詳細設定」タブ → 「起動と回復」の「設定」をクリック
- 「デバッグ情報の書き込み」を以下のいずれかに設定
- 小（256KB）メモリダンプ
- または 自動メモリダンプ
- 「小メモリダンプのディレクトリ」が
%SystemRoot%\Minidumpになっていることを確認
クラッシュごとに C:\Windows\Minidump にファイルが増えていくので、3〜5件たまったところで一括解析すると傾向が見えやすくなります。
不要な常駐ソフト・ツールを一旦外す
サードパーティ製常駐ソフトは、BSOD の原因トップクラスです。まずは以下を目安に「Windows Defender + 必要最小限」まで絞り込みます。
- 他社製アンチウイルス・セキュリティスイート
- システムチューニングツール（最適化・クリーナー・レジストリ掃除系など）
- マザーボード・GPU のユーティリティ（OC・ファン制御・RGB 制御など）
- 常駐型バックアップ・同期ソフト（クラウド同期など）
- 仮想ドライブ・仮想化ツール・VPN クライアント
いったんアンインストールまたは常駐停止した状態で、しばらく様子を見ます。これだけで 0x139 がピタッと止まるケースも珍しくありません。
OC・XMP・電源設定を標準に戻す
オーバークロックや XMP/EXPO 設定は、メモリ破壊系 BSOD の「お約束」です。
- BIOS/UEFI で「Load Optimized Defaults」「工場出荷設定に戻す」等を選択
- CPU/GPU のオーバークロック・アンダーボルト設定をすべて解除
- メモリの XMP/EXPO プロファイルを一時的に無効化（標準クロックで動かす）
- メモリ電圧を盛っている場合は標準電圧へ戻す
OC を戻しただけでクラッシュが止まる場合、ソフトではなくハードの安定性問題と切り分けできます。
重要ドライバーを公式版に揃える
ドライバーは「自動更新に任せればOK」というイメージがありますが、BSOD が出ている環境では、むしろ公式サイトからのクリーン再インストールが安全です。
- マザーボード・PC メーカー公式サイトから最新のチップセットドライバー
- ストレージ関連（Intel RST / AMD SATA / NVMe ドライバーなど）
- GPU ドライバー（NVIDIA / AMD / Intel）
- LAN / Wi‑Fi / Bluetooth ドライバー
GPU ドライバーは特に壊れやすいので、
- セーフモードでDDU（Display Driver Uninstaller）などを使って完全削除
- 再起動後、公式サイトから最新版のみをクリーンインストール
という流れにすると、ドライバー周りの疑いを切りやすくなります。
Windows とストレージの整合性チェック
システムファイルやストレージに問題があると、正しいドライバーでも異常なコードを読み込まされてクラッシュすることがあります。管理者権限のターミナル（PowerShell / コマンドプロンプト）で次を順に実行します。
sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth
chkdsk /scan
| コマンド | 役割 | ポイント |
|---|---|---|
sfc /scannow | システムファイルの整合性チェックと自動修復 | 破損した Windows ファイルを検出・修復してくれる |
DISM /Online /Cleanup-Image /RestoreHealth | コンポーネントストアの破損修復 | SFC でも直らない深刻な破損を修復することがある |
chkdsk /scan | オンラインでのドライブ検査 | ファイルシステムやセクタエラーの有無をざっくり確認 |
再発時に「必ず集めておきたい」情報
単発のミニダンプ1つでは、原因を特定しきれないケースが多いです。再発したときに備えて、以下の情報を定常的に集めておきましょう。
ミニダンプを 3〜5 件集める
クラッシュのたびに C:\Windows\Minidump フォルダーを確認し、ファイル名と時刻をメモしておきます。目安は次の通りです。
- 3〜5件以上のミニダンプがたまったら一括で解析
- クラッシュしたときの状況（ゲーム中、動画視聴中、ブラウジング中など）を簡単にメモ
- ハードウェア構成やドライバー更新のタイミングも記録しておくと相関を取りやすい
外部に解析を依頼したい場合は、これらの .dmp ファイルを日付ごとにまとめて ZIP 化するとよいでしょう。
msinfo32（システム情報）・イベントログを保存
ミニダンプだけでは見えない情報を補うため、次のデータも合わせて用意すると解析精度が上がります。
- システム情報（msinfo32）
Win + R→msinfo32と入力して Enter- 「ファイル」 → 「保存」で
.nfo形式で保存
- イベントログ（システム）
- イベントビューアーを開く
- 「Windows ログ」→「システム」を右クリックして「すべてのイベントを名前を付けて保存」
.evtxファイルとして保存
特に クラッシュ直前に Disk / StorPort / WHEA-Logger などの警告・エラーがないかは重要なヒントになります。
再現パターンをメモしておく
地味ですが、後から効いてくるのが「再現パターンのメモ」です。
- 高負荷（3Dゲーム・エンコード・ベンチマーク）でのみ発生するのか
- アイドルや軽い作業中にランダムに落ちるのか
- スリープ復帰、USB デバイス接続直後など、特定操作の直後に出るのか
- クリーンインストール前後で発生タイミングが似ているか
ソフトウェア原因なら操作内容と強くリンクすることが多く、ハードウェア原因なら負荷・温度・時間経過とリンクしやすくなります。
ハードウェア起因を疑うときのチェックポイント
メモリ（RAM）の検査
0x139 をはじめとするメモリ破壊系 BSOD の「本命候補」はやはり RAM です。検査は次のように行います。
- MemTest86 など専用ツールでの検査（USB からブートして最低 4 パス以上）
- Windows 標準の「Windows メモリ診断」を拡張設定で複数回実行
- メモリを 1 枚ずつ挿し替えてテスト（どのモジュールが怪しいか切り分け）
- メモリスロットを変えてテスト（マザーボード側の不良確認）
エラーが出たモジュールは、一時的に外して運用してみると再現性が変わるかを確認できます。XMP/EXPO 無効＋標準クロックでエラーが止まるなら、設定起因・相性問題の可能性が高いです。
ストレージ（SSD / HDD）の健全性
ストレージの状態は、SMART 情報を確認できるツールでざっくり把握できます。
- 異常な再代替セクタ数・エラー数が増えていないか
- 総書き込み量・使用時間が極端に多く、寿命に近づいていないか
- 温度が常時高温になっていないか
また、SATA ケーブル・電源ケーブルの接触不良や、M.2 SSD の固定ネジゆるみも意外と多いトラブル要因です。物理的な接続も合わせてチェックしましょう。
温度・電源・物理要因
高負荷時にだけ 0x139 が出る場合、電源や温度の問題も疑います。
- CPU / GPU 温度が 90℃ 近くまで上がっていないか
- 使用している電源ユニットの容量が構成に対して不足していないか
- 経年劣化した電源（5年以上使用）を流用していないか
- 延長コード・タップの接触不良、家のコンセント自体の問題など
別の電源ユニットや別系統のコンセントで動かしてみて症状が変わる場合、電源周りが犯人の可能性が高くなります。
最小構成での検証
一見関係なさそうな周辺機器が BSOD のトリガーになっていることもあります。次のような「最小構成テスト」も有効です。
- マウス・キーボード・ディスプレイ以外の USB 機器をすべて外す
- 増設カード（キャプチャボード、サウンドカード等）があれば一旦抜く
- メモリを 1 枚構成にしてみる
- 可能であればオンボード GPU のみ・単体 GPU のみなど構成を変えてみる
最小構成で安定するなら、追加したどこかの機器やそのドライバーが 0x139 の原因である可能性が高まります。
WinDbg でミニダンプを読む基本
ソフトウェア起因かハード起因かを見極めるには、やはりミニダンプ解析が強力です。ここでは、0x139 を読むときの最低限のポイントだけ押さえておきます。
WinDbg の導入とダンプの開き方
- Microsoft Store から「WinDbg」（WinDbg Preview）をインストール
- WinDbg を起動し、「File」→「Open dump file」から
C:\Windows\Minidump\*.dmpを選択 - 読み込みが終わったら、コマンド入力欄に
!analyze -vと入力して Enter
しばらく待つと解析結果が表示されます。
BUGCHECK_STR: KERNEL_SECURITY_CHECK_FAILURE
PROCESS_NAME: xxx.exe
STACK_TEXT:
fffff... nt!KeBugCheckEx
fffff... nt!...
...
MODULE_NAME: driver_name
IMAGE_NAME: driver_name.sys
Probably caused by : driver_name.sys ( driver_name+0x1234 )
毎回同じ driver_name.sys が出てくるようであれば、そのドライバーが強く疑われます。ただし、単発ダンプの「Probably caused by」だけで犯人扱いするのは危険です。
複数ダンプをまたいでパターンを見る
0x139 のようなメモリ破壊系は、スタックがバラバラになりやすく、「たまたま巻き込まれた無関係なドライバー」が原因として表示されることがあります。そこで重要なのが、
- 3〜5件のダンプを順番に開いて
!analyze -vを確認する - 毎回同じドライバー名が出ているか
- スタックの途中に同じドライバーが頻繁に出ていないか
- 特定のプロセス名（ゲーム名やアプリ名）でのみクラッシュしていないか
という「パターン探し」です。複数回のダンプで共通項が見えたら、
- そのドライバーを最新版にする / 一旦削除する
- 関連するハードウェアを外してみる
といった形で絞り込みができます。
Driver Verifier でドライバーの不正をあぶり出す（上級者向け）
Driver Verifier（ドライバー検証ツール）は、問題のあるドライバーをあえてクラッシュさせて特定するための仕組みです。ただし、設定を誤ると起動ループに陥るリスクがあるため、あくまで上級者向けです。
Driver Verifier の有効化手順
- 重要データのバックアップと、可能ならシステム復元ポイントを作成
- 管理者権限のコマンドプロンプト or PowerShell を開く
- 次のコマンドを実行
verifier /standard /driver *nonMicrosoft*
- PC を再起動すると、非 Microsoft 製ドライバーに対する厳格なチェックが有効化されます。
- 問題があるドライバーがあれば、起動直後や操作中に BSOD が多発するようになります。
この状態で 0x139 などの BSOD が出た場合、ミニダンプ中により明確なドライバー名が出てくることがあります。
解除方法（必ず覚えておく）
Driver Verifier を有効にしたままにすると、問題が解決しても BSOD が増え続けてしまうため、原因ドライバーの修正後は必ず無効化します。
- 再度、管理者権限のコマンドプロンプト or PowerShell を開く
- 次のコマンドを実行
verifier /reset
もし起動ループに陥った場合は、セーフモードで起動してから同じコマンドを実行すると解除できます。
原因別の対処早見表
ここまでの内容を、「症状から当たりをつける」ための早見表にまとめます。
| 症状・手掛かり | よくある原因 | 具体的な対処 |
|---|---|---|
| 0x139 がたまに出るが、ミニダンプでは原因モジュール不明 | サードパーティ常駐ソフト、ドライバーのメモリ破壊 | 常駐ソフトを一旦削除 / 停止、公式ドライバーに統一、必要なら Driver Verifier で洗い出し |
| クラッシュ直前に Disk / StorPort / NTFS の警告・エラー | ストレージ・ケーブル・電源の問題 | SATA / 電源ケーブル交換、ストレージのファーム更新、SMART 確認、別電源での検証 |
| ゲームや 3D ベンチマーク時にのみ発生 | GPU ドライバー、GPU OC、温度 | DDU で GPU ドライバーをクリーン再インストール、OC 解除、冷却強化、ケース内エアフロー改善 |
| アイドル中や軽い作業中にもランダムに再起動、メモリエラーが出ることも | RAM 不良 / 相性、XMP/EXPO の不安定 | XMP 無効化、1 枚挿しでの検証、MemTest86 実行、不良モジュールの切り離し |
| クリーンインストール前後で同じように 0x139 が再発 | OS ではなくハードウェア起因の可能性が高い | メモリ・ストレージ・電源・マザーボードのハード検査を優先し、可能ならスペアパーツで代替検証 |
| 特定の周辺機器（USB デバイス）を接続した直後に発生 | 周辺機器のドライバー / ファームウェア不具合 | デバイスを外して様子見、別ポートに接続、ドライバー・ファームウェア更新、別 PC での再現確認 |
実務的な切り分けフロー例
実際の現場で 0x139 と向き合うときの、現実的なフロー例を示します。迷ったらこの順番で進めてみてください。
- ミニダンプの保存設定を確認し、Minidumpフォルダが増えていくかチェック
- サードパーティ常駐ソフトを外し、Windows Defender のみにして様子を見る
- BIOS を最適化初期化し、OC / XMP / EXPO をすべてOFFにする
- チップセット・ストレージ・GPU・LAN など主要ドライバーを公式最新版に統一
- sfc /scannow、DISM、chkdsk /scan を順に実行して Windows 側の破損を修復
- それでも再発するようなら、ミニダンプを 3〜5件集め、WinDbg で共通パターンを確認
- パターンから特定のドライバーが怪しければ、それを更新 / 削除 / 無効化して変化を見る
- 並行して MemTest86 やストレージ SMART チェックなどハード診断を実施
- ハード診断で怪しいパーツがあれば、外して運用 or スペアと入れ替えて再現性を確認
- どうしても特定できない場合に限り、Driver Verifier を使ってドライバーを絞り込む
この流れで進めると、「ソフト側で済む話なのか」「ハード交換が必要なのか」がかなりの確度で見えてくるはずです。
よくある質問（FAQ）
Q. クリーンインストールしたのに 0x139 が出ます。OS の問題では？
A. クリーンインストール後もしばらくしてから再発する場合、OS よりもハードウェアかドライバー構成を疑った方が現実的です。特に、再インストール前と同じタイミング（ゲーム中だけ、スリープ復帰時だけ等）で再発する場合は、ハード起因の線が濃くなります。
Q. ミニダンプが 1 つしかないのですが、それでも解析できますか？
A. 不可能ではありませんが、1 つだけでは ntoskrnl.exe しか見えないなど「はっきりした原因まで踏み込めない」ケースが多いです。なるべく 3〜5 件集めてパターンを見た方が、原因ドライバーやハードの切り分けに役立ちます。
Q. Driver Verifier を常用しておけば安定しますか？
A. いいえ。Driver Verifier は「問題のあるドライバーをあえてクラッシュさせて炙り出す」ためのツールであり、常用するとむしろ BSOD が増えます。原因特定のために一時的に使い、終わったら必ず verifier /reset で無効化しましょう。
Q. 0x139 が出たら必ずメモリ不良ですか？
A. メモリ不良は有力候補ですが、ドライバーのバグでメモリ破壊が起きているだけというケースも多いです。MemTest 等で物理メモリを検査し、問題がなければドライバー・常駐ソフト・OC 設定などソフト側を重点的に疑うのが現実的です。
まとめ
- Bugcheck 0x139（KERNEL_SECURITY_CHECK_FAILURE）は「カーネル整合性チェック失敗」＝メモリ破壊系のエラーであり、犯人は多くの場合「ドライバー」か「メモリ・ストレージ・電源」などのハードウェアです。
- 単発のミニダンプでは原因特定が難しいことが多いため、ミニダンプを 3〜5 件集め、WinDbg で共通パターンを見ることが重要です。
- まずは 常駐ソフトの整理、公式ドライバーへの統一、OC/XMP の解除、Windows の整合性チェックといった「ソフト側の基本対策」から着手しましょう。
- 再発が続く場合は、MemTest86・SMART・温度・電源チェック・最小構成テストでハードウェア起因を疑い、怪しいパーツを切り分けていきます。
- どうしても特定できないときは、上級者向けですが Driver Verifier を利用することで、問題ドライバーを集中的に炙り出せる場合があります（ただし起動ループには要注意）。
- 外部に相談する際は、複数のミニダンプ + msinfo32 の NFO + イベントログ（システム）をセットで用意すると、短時間で原因にたどり着きやすくなります。
0x139 は一見「原因不明のブルースクリーン」に見えますが、情報をきちんと集めて順序立てて切り分けていけば、かなりの確率で原因候補を絞り込むことができます。本記事の手順をベースに、ご自身の環境に当てはめて診断を進めてみてください。
コメント