Windows 10で突然ブルースクリーン（BSOD）が出て再起動されてしまい、しかも「ntoskrnl.exe」とだけ表示されて原因が分からない――そんな状況が数か月続くと、OS再インストールやメモリ交換をしても直らず、かなり消耗します。この記事では、実際に「6か月以上ランダムにBSODが発生したケース」をベースに、ディスク・ドライバー・BIOS・ハードウェアの順で、再現性の低いBSODを現実的な手順で潰していく方法を整理します。
症状の整理：ランダムに発生する「ntoskrnl.exe」のブルースクリーン
まずは相談内容をベースに、状況を整理します。
- 発生タイミング：6か月ほど前から、完全にランダムなタイミングでBSODが発生
- すでに実施済みの対策：
- Windows 10の再インストール（クリーンインストールを含め複数回）
- チップセット・GPUなど、すべてのドライバー更新
- Windows Updateの最新化
sfc /scannow/DISM/chkdsk実行済み- RAMは交換済み（別のメモリに入れ替え）
- CPU / GPU のストレステスト実施、温度・電圧は問題なし
- CrystalDiskInfo では NVMe / SSD の状態は「正常」表示
- サードパーティアンチウイルスは無効化済み
- BSOD画面：解像度や表示崩れの影響でエラーコードが読めない
- ログ：ミニダンプ / MEMORY.dmp / イベントログは一部取得済みだが、クラッシュによってはダンプが残らないこともある
- 解析結果の一例：
- イベントログにディスク関連の警告が多数出ている
- BugCheck は
0x139 (KERNEL_SECURITY_CHECK_FAILURE) - 第1引数は
0x3 (LIST_ENTRY_CORRUPTION)→ メモリ破壊の典型パターン
ここまでやっても直らない場合、「OSや表面的なドライバー更新だけでは解決しない」層に原因が潜んでいる可能性が高いです。
「ntoskrnl.exe」と表示される理由と、0x139エラーの意味
ntoskrnl.exeは「犯人」ではなく、倒れた場所の表示
BSODの詳細に「ntoskrnl.exe」と表示されることがよくありますが、これはWindowsのカーネル本体です。カーネルがクラッシュしたとき、たまたま ntoskrnl.exe 上で異常が検出された、というだけであり、
- ntoskrnl.exe = 壊した張本人
という意味ではありません。多くの場合、
- サードパーティ製ドライバーやフィルタドライバーがメモリを壊した
- ディスクやメモリなどのハードウェアエラーが波及して、カーネルが異常状態を検出した
結果として「ntoskrnl.exe 上で例外が発生した」という形で表示されます。
BugCheck 0x139 KERNEL_SECURITY_CHECK_FAILURE と LIST_ENTRY_CORRUPTION
今回のケースで記録されている BugCheck は 0x139、シンボル名は KERNEL_SECURITY_CHECK_FAILURE です。このうち、引数として 0x3 (LIST_ENTRY_CORRUPTION) が入っている場合、代表的な原因は次のようなメモリ破壊です。
- 解放済みのメモリ（フリーリスト）に誰かが書き込んでしまった
- ダブルフリー（二重解放）や不正なポインタ操作が発生した
- カーネルオブジェクトをつなぐリスト構造（LIST_ENTRY）が壊されていた
この種のメモリ破壊を引き起こすのは、かなりの確率でカーネルモードドライバーです。特に：
- VPNクライアントのネットワークフィルタドライバー
- サードパーティ製ファイアウォール / パケットフィルタ
- サードパーティ製アンチウイルスのカーネルドライバー
- 仮想オーディオ・仮想CDドライブなど、仮想デバイスのドライバー
など、「通信」「セキュリティ」「仮想デバイス」を扱うドライバーは、OSのごく深い層に入り込むため、バグや環境依存の問題があるとメモリ破壊のトリガーになりがちです。
もっとも疑わしい主因の整理
今回のケースと同様の相談を多数見ていくと、次の3つが特に疑わしい組み合わせとして浮かび上がります。
| 候補 | 概要 | なぜ怪しいか |
|---|---|---|
| ストレージ / ファイルシステム起因 | NVMe / SSD / HDD の物理不良、ケーブル不良、ファイルシステムの破損 | イベントログに Disk / NTFS / StorPort の警告が大量に出ている |
| サードパーティ製フィルタドライバー | VPN・FW・AV・仮想デバイスなどのカーネルモードドライバー | 0x139 / 0x3 (LIST_ENTRY_CORRUPTION) はドライバーのメモリ破壊の代表例 |
| プラットフォームの古さ | 古いBIOS、古いチップセットドライバー、古いストレージドライバー | NVMe対応初期のBIOSや古いAGESAで、I/O周りが不安定になるケースがある |
ここから先は、上記3つを再発検証しやすい順に潰していきます。
ディスク・ファイルシステム健全性の徹底チェック
まずはバックアップを最優先
ディスク起因を疑う作業では、最悪ディスクが完全に読めなくなる可能性もゼロではありません。重要データは必ず以下のような形でバックアップしておきます。
- 外付けHDD / SSD / NAS へのコピー
- OneDrive / Google Drive などクラウドストレージへの同期
- ゲームやアプリの設定ファイル（セーブデータ）も忘れずに
バックアップが終わったら、いよいよディスクチェックに入ります。
chkdsk /f と /r でファイルシステム・セクタを検査
管理者として「Windows Terminal」または「コマンドプロンプト」を開き、次のコマンドを実行します。
chkdsk C: /f
- 「次回の再起動時にチェックを実行しますか？」と聞かれたら「Y」
- PCを再起動すると、起動前にボリュームチェックが実行されます
チェック後の詳細結果は、イベントビューアーから確認できます。
- イベントビューアーを開く
- 「Windowsログ」→「アプリケーション」
- ソースがWininitのイベントを探す
必要に応じて、時間がかかることを承知したうえで、バックアップ後に次のコマンドも検討します。
chkdsk C: /r
/rは不良セクタ検査を含むため、容量によっては数時間かかることもあります- 不良セクタが見つかった場合、早めのドライブ交換を強く推奨します
イベントログの Disk / NTFS / StorPort をチェック
次に、イベントビューアー「システム」ログに現れているディスク関連のエラーを洗い出します。代表的なものをまとめると次のようになります。
| ログ ソース | イベントID | 概要 | 対応の目安 |
|---|---|---|---|
| Disk | 7, 51, 153 など | I/Oエラー、再試行、タイムアウトなど | 物理ドライブ or ケーブル or ポートを疑う |
| NTFS | 55 | ファイルシステムの整合性エラー | chkdsk 実行、念のためバックアップ |
| StorPort / iaStorAC など | 129 など | デバイスリセット、ポートリセット | ストレージドライバーやファームウェアを確認 |
これらが頻発している場合、ソフトウェアだけでなくNVMe本体・スロット・ケーブル・マザーボードの不調まで視野に入れる必要があります。
NVMe / SSD のファームウェアとストレージドライバーを最新化
CrystalDiskInfo で「正常」と表示されていても、ファームウェアやドライバー起因で不安定になることがあります。次のように確認します。
- 使用しているNVMe / SSDのメーカーサイトで、最新ファームウェアの有無を確認し、専用ツールがあれば更新
- マザーボードまたはチップセット（Intel RST / AMD SATA/NVMe）のストレージドライバーを最新バージョンに更新
- NVMeを一度抜き差しし、可能なら別のM.2スロットに差して接触不良・スロット不良も切り分け
さらに可能であれば、
- 別の新しいNVMeを用意 → そちらに Windows をクリーンインストール
- 同じ使い方をしても BSOD が一切出ない ⇒ 元のNVMeの物理不良・相性の線が濃厚
という形で、ストレージ起因かどうかを実験的に切り分けると、問題の見通しが一気に良くなります。
ドライバー競合の除去：サードパーティ製フィルタドライバーを疑う
「無効化」ではなく「完全アンインストール」で検証する理由
VPNクライアントやサードパーティセキュリティソフトは、OSの深い層にフィルタドライバーを挿し込むため、「アプリを終了した」「サービスを無効にした」だけではドライバーが常駐し続けることがあります。
BSOD切り分けの目的では、完全アンインストールが必須です。具体的には、次のようなソフトを徹底的に外します。
- VPNクライアント（TAP / TUN ドライバーを入れるタイプ）
- サードパーティ製ファイアウォール / パケットフィルタ（simplewall など）
- サードパーティ製アンチウイルス
- Bitdefender などは、公式アンインストールツールで残骸ごと削除するのが安全
- 仮想オーディオ・仮想CD・仮想ドライブ系ソフト（VB-Audio 等）
アンインストール後は、再起動したうえで、しばらく Windows Defender + 標準ドライバーのみの状態で運用してみます。これで BSOD が収まるなら、ほぼ確実にソフト側が原因です。
ネットワークフィルタドライバーを目視で確認する
ネットワークまわりのフィルタドライバーが怪しい場合、「ネットワーク接続のプロパティ」から確認することもできます。
- 「設定」→「ネットワークとインターネット」→「アダプターのオプションを変更する」
- 使用中のネットワークアダプターを右クリック →「プロパティ」
- 「この接続は次の項目を使用します」の一覧に、VPNやセキュリティソフトの名前が残っていないか確認
不要な項目や、アンインストールしたはずのドライバーが残っている場合は、ソフト側のアンインストーラーや公式クリーンツールで完全削除を試みます。
BIOS・チップセット・GPUドライバーを最新にする
BIOS更新は慎重に、しかし避けて通らないポイント
NVMe全盛期の現在でも、古いBIOS（特に初期のAGESAや古いUEFI）では、NVMe・メモリ・I/O周りの安定性が微妙なことがあります。BSODが長期的に発生している環境なら、次の順で確認します。
- マザーボード型番を確認（PCケース内の印字 or システム情報から）
- メーカーサイトで、最新版BIOSと更新履歴をチェック
- 「NVMe互換性の改善」「メモリ安定性の向上」などの記載があれば、まさに今回の症状ど真ん中
BIOS更新時は、
- 停電のリスクが低いタイミングで行う
- USBメモリでの更新手順を事前に読んでおく
- OC（オーバークロック）設定を入れている場合は、一度リセットしてから
といった基本を守りつつ、メーカー推奨の方法でアップデートします。
チップセットドライバーとGPUドライバーのクリーンインストール
BIOS更新と合わせて、次のドライバーも見直します。
- Intel / AMD チップセットドライバー：公式サイトから最新を導入
- GPUドライバー：DDU（Display Driver Uninstaller）で古いドライバーを完全削除 → 最新版をインストール
特に GPU ドライバーは、複数バージョンを上書きしていくと残骸が BSOD の種になることがあります。DDU でクリーンにしてから入れ直すことで、「ドライバー自体が悪いのか」「設定や残骸が悪いのか」を切り分けやすくなります。
クリーンブートで常駐ソフトの影響を切り分ける
ここまででストレージ・ドライバー・BIOSを見直しても、なお BSOD が発生する場合は、起動時に自動起動しているサービスや常駐ソフトの影響を疑います。
クリーンブートの手順
- Win + R →
msconfigと入力して「システム構成」を開く - 「サービス」タブで、「Microsoft のサービスをすべて隠す」にチェック
- 残ったサードパーティサービスをすべて無効にする
- 「スタートアップ」タブ →「タスクマネージャーを開く」→ すべて無効
- PCを再起動
この状態で数日〜1週間程度使い、BSOD が発生するかどうかを確認します。
| 結果 | 解釈 | 次のアクション |
|---|---|---|
| クリーンブート中は BSOD が出ない | 何らかのサービス / 常駐ソフトが原因 | サービスを1つずつ（またはグループ単位で）戻し、再発したところで犯人特定 |
| クリーンブートでも BSOD が発生 | サービス外（ドライバー / ハードウェア）に原因が残っている | Driver Verifier やハードウェア診断フェーズへ進む |
BSODコードが読めないときの対処：クラッシュ情報の取り方
解像度やスケーリングの関係で、BSODのエラーコードやファイル名が読めない場合、以下の設定を見直すと改善します。
自動再起動を止めて、ダンプを確実に残す
- 「スタート」→「設定」→「システム」→「バージョン情報」→「システムの詳細設定」
- 「詳細設定」タブ →「起動と回復」の「設定」
- 「システムエラー」欄で、
- 「自動的に再起動する」のチェックを外す
- 「デバッグ情報の書き込み」を「小さいメモリダンプ（256KB）」または「自動メモリダンプ」に設定
また、ページファイル（仮想メモリ）を C ドライブで有効にしておくことも重要です。ページファイルを「なし」にしていると、ダンプが出ない原因になります。
表示スケールと解像度を標準に戻す
4Kモニターや高DPI環境でスケーリングを大きくしていると、BSODのメッセージが画面外にはみ出すことがあります。
- 「設定」→「システム」→「ディスプレイ」で、
- 解像度を推奨に戻す
- 拡大縮小（スケール）を100%にして一度様子を見る
BSOD発生時にスマホで写真を撮っておくと、後からコードを読み取るのにも役立ちます。
ダンプ解析の取っ掛かり
ダンプファイルが出るようになったら、次のようなツールで解析の第一歩を踏めます。
- BlueScreenView や WhoCrashed で「直近の BSOD の原因ドライバー」をざっくり確認
- WinDbg / WinDbg Preview で BugCheck のパラメータを詳細に確認
詳しいシンボル解析までは行わなくても、
- 毎回同じドライバーがスタックに出ているか
- 共通しているプロセス / ドライバーは何か
といった情報が分かるだけでも、原因を絞り込みやすくなります。
Driver Verifierでサードパーティドライバーを炙り出す
BSODが出たり出なかったりで再現性が低い場合、Driver Verifier でサードパーティドライバーをわざと追い詰めて、異常時に即座に落とす方法が有効です。ただし、やり方を誤ると起動ループに陥るため、慎重に進めます。
事前準備
- 復元ポイントを作成する
- セーフモードの起動方法（Shift + 再起動 → トラブルシューティング → 詳細オプション → スタートアップ設定）を把握
Driver Verifierの基本コマンド
:: サードパーティドライバーに標準テストを有効化
verifier /standard
:: 現在の設定を確認
verifier /querysettings
:: 問題がなくても、検証を終了したくなったら
verifier /reset
verifier /standard 実行後のウィザードでは、
- ターゲットドライバーとしてサードパーティ製ドライバーのみを選ぶ
- Microsoft製ドライバーは原則外す（誤検知や不要な負荷を避けるため）
Driver Verifier 有効化後、しばらく通常通りPCを使い、BSODが発生した場合、ダンプには「メモリ破壊を起こしたドライバー」がよりはっきりと記録されている可能性が高くなります。
もし Verifier 有効化後に Windows が起動しなくなった場合は、セーフモードに入り、
verifier /reset
で設定をリセットします。
ハードウェア診断：メモリ・電源・マザーボードを疑うタイミング
ストレージ・ドライバー・BIOS・クリーンブート・Verifier まで試しても BSOD が続く場合、残るのはハードウェア周りです。
メモリ：MemTest86でロングラン検査
メモリを交換済みでも、
- 交換先のメモリにも不具合がある
- メモリとマザーボードの相性が悪い
といったパターンはあり得ます。MemTest86 を USB から起動し、最低1周（できれば数周）回してみます。
- エラーが1つでも出たら、そのメモリまたはスロットは要疑い
- メモリを1枚ずつ挿してテストし、どの組み合わせでエラーが出るかを確認
電源ユニットとケーブル
意外と盲点なのが電源ユニットです。
- 長年使っている電源で、出力が劣化している
- PCIe補助電源ケーブルやATXケーブルの差し込みが甘い
といった状況でも、大きな負荷がかかった瞬間だけ電圧が落ちてBSOD、という挙動を見せることがあります。GPUやCPUには問題がないと判断されている場合でも、一度電源ケーブルの抜き差しと、可能なら別電源での検証を行ってみる価値はあります。
マザーボード・NVMeスロットの切り分け
- NVMeを別スロットに差し替えて同じ症状が出るか
- 問題のNVMeを別PCに差して、同様のエラーや警告が出ないか
- 逆に、別PCで正常なNVMeを問題のPCに差すとどうなるか
といった組み合わせ検証を行うことで、
- NVMe自体の不良
- マザーボード上の特定スロットの不良
- PCIeレーンやチップセット側の不具合
などを切り分けやすくなります。
すぐ使えるコマンドまとめ（管理者で実行）
この記事で触れた主要コマンドを、再掲としてまとめておきます。いずれも管理者権限で実行してください。
:: ファイルシステムの修復（再起動時に実行）
chkdsk C: /f
:: 不良セクタ検査を含む徹底チェック（バックアップ必須）
chkdsk C: /r
:: Driver Verifier（サードパーティのみ選択して有効化）
verifier /standard
:: 現在の Driver Verifier 設定を確認
verifier /querysettings
:: Driver Verifier を無効化（セーフモードからでも可）
verifier /reset
原因別の対処方針をざっくり整理
最後に、ここまでの内容を「症状 → 疑うポイント → 優先アクション」という形でまとめます。
| よくある状況 | 主に疑うポイント | 優先的に行うこと |
|---|---|---|
| イベントログに Disk / NTFS の警告・エラーが多い | ストレージ・ファイルシステム不良 | chkdsk /f /r、NVMeファーム / ドライバー更新、別NVMeでの検証 |
| BugCheck 0x139 / 0x3（LIST_ENTRY_CORRUPTION） | サードパーティ製カーネルドライバーのメモリ破壊 | VPN / FW / AV / 仮想デバイスを完全アンインストール、Driver Verifier で追い込み |
| 再インストールしても同じ症状が出る | ハードウェア or BIOS / チップセット | BIOS更新、チップセット更新、メモリ / NVMe / 電源の物理的な切り分け |
| クリーンブート中は BSOD が出ない | 常駐ソフト・サービス | サービスを1つずつ戻し、再発したところで原因ソフトを特定 |
| ダンプが残らない / コードが読めない | 設定・環境依存 | 自動再起動OFF、小さいメモリダンプ有効化、スケール100%、ページファイルON |
まとめ：ストレージとフィルタドライバーを最優先で疑う
「ntoskrnl.exe と表示されるランダム BSOD」の多くは、ntoskrnl.exe 自体が壊れているのではなく、
- ストレージ（NVMe / SSD）やファイルシステムの不安定さ
- VPN・FW・AV・仮想デバイスなどのサードパーティ製フィルタドライバーの競合
のどちらか、あるいは両方が根本原因になっています。
具体的には、次の順番で進めると、再発検証がしやすく、原因にたどり着きやすくなります。
- バックアップを取ったうえで、chkdsk /f /r やイベントログでディスク健全性を徹底確認、必要なら NVMe 交換で切り分け
- VPN / FW / AV / 仮想デバイスなどをアンインストールし、Windows Defender + 標準ドライバー構成で様子を見る
- BIOS / チップセット / GPUドライバーを更新し、余計なOC設定があれば一度リセット
- クリーンブートでサービス・常駐ソフトを最小構成にし、戻しながら原因を特定
- ダンプ設定と表示スケールを整え、再発時の情報を確実に採取する
- どうしても収まらない場合は、MemTest86・別電源・別NVMeスロットなどでハードウェアの徹底診断を行う
「再インストールしたのに直らない BSOD」は、心理的にはかなりつらい問題ですが、ログとダンプを取りながら一つずつ切り分けていけば、必ずどこかで手がかりが見えてきます。この記事の手順をなぞりながら、ストレージとフィルタドライバーを最優先で疑い、そのうえでプラットフォームとハードウェアを順番に確認していくことで、ランダムに見える BSOD も、再現性をもった「原因のある現象」として扱えるようになるはずです。
コメント