Windows 10 で突然「KERNEL_SECURITY_CHECK_FAILURE（停止コード 0x139）」のブルースクリーンが出て再起動を繰り返すと、不安になりますよね。この記事では、Intel HAXM ドライバーが原因となるケースを中心に、再発防止まで含めた具体的な対処手順を詳しく解説します。
突然発生したブルースクリーン「KERNEL_SECURITY_CHECK_FAILURE」とは？
Windows 10 で表示されるブルースクリーン（BSoD）の中でも、「KERNEL_SECURITY_CHECK_FAILURE（停止コード 0x139）」は、カーネル内部の整合性チェックに失敗したときに出る比較的重めのエラーです。単なるアプリのクラッシュではなく、OS の中枢が「これは危ない」と判断してシステムを強制停止している状態だと考えてください。
今回のケースでは、ミニダンプの解析結果として INVALID_BALANCED_TREE というサブコードが報告されています。これは、カーネル内部で使われている「平衡木（Balanced Tree）」というデータ構造が壊れていることを示すもので、通常はドライバーのバグやメモリ破損が疑われます。
今回のような症状の典型パターン
実際に 0x139 が出るときの症状として、次のようなものがよく見られます。
- PC 起動中、あるいは Android エミュレーター起動時などに突然ブルースクリーンが出る
- 「KERNEL_SECURITY_CHECK_FAILURE」と表示され、数秒後に自動的に再起動する
- イベントビューアーを見ると、Intel HAXM（Hardware Accelerated Execution Manager）サービス関連のエラーが多数記録されている
- ミニダンプ解析では INVALID_BALANCED_TREE が報告される
これらの条件がそろっている場合、犯人候補として最も疑わしいのが、Intel HAXM ドライバーの不具合です。
主な原因候補の整理
まずは、停止コード 0x139 が出るときに考えられる原因候補を整理しておきましょう。今回のケースでは Intel HAXM にほぼ絞り込めますが、一般論としては以下のようになります。
| 想定原因 | 内容 | 典型的な状況 | 優先度 |
|---|---|---|---|
| Intel HAXM ドライバーの破損・旧バージョン | Android Studio などで利用される仮想化支援ドライバー。カーネルモードで動作し、メモリ管理や CPU 仮想化を行うため、バグや破損があるとカーネル内部構造を壊すことがある。 | Android エミュレーター起動時／仮想マシン利用時にブルースクリーンが出る。イベントログに HAXM サービスのエラーが連続して記録される。 | 最優先で確認 |
| 他のドライバーやシステムファイルの破損 | ストレージエラー、突然の電源断、不適切なクリーンアップツールなどにより、システムファイルやドライバーが破損し、カーネル構造に不整合が出る。 | 特定のアプリとは無関係にランダムなタイミングで BSoD、イベントログにさまざまなドライバー名が登場する。 | 次点で確認 |
| RAM（メモリ）やストレージなどハードウェアの不良 | 物理メモリのビット反転や、SSD/HDD の不良セクタにより読み書き内容が化け、結果としてカーネル内データ構造が壊れる。 | 高負荷時・長時間稼働時に不定期に BSoD。別の停止コード（0x1A、0x50 など）も混在することがある。 | ソフト側で改善しないときに確認 |
今回与えられている情報では、イベントログで Intel HAXM サービスのエラーが多発し、かつダンプで INVALID_BALANCED_TREE が出ていることから、まずは HAXM 周りを徹底的に疑うのが合理的です。
Intel HAXM がトラブルを引き起こす理由
Intel Hardware Accelerated Execution Manager（Intel HAXM） は、主に Android Studio のエミュレーター高速化のために利用されるドライバーです。CPU の仮想化機能（Intel VT-x）を直接扱い、ゲスト OS を高速に実行できるようにします。
このようなドライバーは カーネルモードで動作し、カーネルのメモリ領域や CPU の制御機構に深く入り込みます。そのため、
- バージョンが古い
- Windows 10 のビルドやセキュリティ更新と相性が悪くなった
- インストールが中途半端で一部ファイルだけ破損している
- Hyper-V や他の仮想化ソフトと競合している
といった条件がそろうと、カーネル内部のデータ構造を壊してしまい、結果として 0x139（KERNEL_SECURITY_CHECK_FAILURE）が発生することがあります。
特に、Windows 10 で仮想化機能（Hyper-V、Windows サンドボックス、Wsl2 など）を多用している環境では、HAXM と機能がバッティングしやすく、「以前は普通に動いていたのに、ある日から突然落ちるようになった」という現象が起こりやすくなります。
作業前にやっておきたい準備
これから紹介する対処法の中には、システムに大きく手を入れるものも含まれます。トラブルを悪化させないために、次の準備をしてから作業を始めてください。
- 重要ファイルのバックアップ（ドキュメント、デスクトップ、Android プロジェクトなど）
- 復元ポイントの作成（システムのプロパティ → システムの保護 → 作成）
- 現在の環境メモ（インストール済みの仮想化ソフト、Android Studio のバージョンなど）
ここまで準備ができたら、まずは最も成功率の高いIntel HAXM の再インストールから試していきます。
対処1：Intel HAXM ドライバーを再インストールする
0x139 の原因として HAXM が疑われる場合、最初に実施したいのが「アンインストール → 最新版のクリーンインストール」です。作業の流れは次のとおりです。
Intel HAXM のアンインストール
- Windows の設定を開きます。
- 「アプリ」→「インストールされているアプリ」から、Intel Hardware Accelerated Execution Manager（もしくは類似の名称）を探します。
- 該当項目を選択し、アンインストールを実行します。
- アンインストール完了後、必ず一度PC を再起動します。
「アプリ」一覧に見つからない場合は、
- 「コントロールパネル」→「プログラムと機能」
- 「デバイス マネージャー」で「システム デバイス」や「ソフトウェア デバイス」の中
も確認してみてください。古い HAXM が残っていると、ここに表示されていることがあります。
最新版 HAXM の入手とインストール
アンインストールができたら、次は最新版をインストールします。入手方法は大きく 2 パターンです。
- Android Studio の SDK Manager からインストールする方法
- 公式配布サイトからインストーラーをダウンロードする方法
Android Studio を利用している場合は、SDK Manager からインストールするのが簡単です。
- Android Studio を起動します。
- 「More Actions」や「Tools」メニューから SDK Manager を開きます。
- 「SDK Tools」タブを開き、Intel x86 Emulator Accelerator (HAXM installer) にチェックを入れます。
- 「OK」または「Apply」を押してインストールを実行します。
- 必要に応じてインストーラーのウィザードが表示されるので、案内に従って完了させます。
SDK Manager を使わずに手動でインストーラーを使う場合は、公式の配布元から HAXM のアーカイブ（例：haxm-windows_v7_8_0.zip など）をダウンロードし、解凍して setup.exe を実行します。インストーラーの途中で割り当てるメモリ量を聞かれた場合は、PC の物理メモリの 1/4 程度を上限の目安にすると無難です。
インストール後の確認ポイント
HAXM の再インストールが終わったら、次の点を確認しておきましょう。
- サービス一覧（services.msc）に Intel HAXM サービス が表示され、状態が「実行中」になっているか
- Android エミュレーターが正常に起動するか
- その後しばらく使用しても、同じブルースクリーンが再発しないか
ここまでで症状がピタッと収まれば、原因はほぼ HAXM にあったと考えてよいでしょう。その場合でも、後述する「メモリ診断」や「システムファイルチェック」を一度実行しておくと安心です。
対処2：HAXM 自体が不要ならアンインストールしてしまう
最近の Android エミュレーターは、Hyper-V ベースの仮想化を利用できるようになっており、Intel HAXM を使わなくても快適に動作するケースが増えています。もし現在の開発環境や用途で HAXM が不要であれば、思い切ってアンインストールしてしまうのも有効な選択肢です。
HAXM を完全に削除することで、
- HAXM ドライバーによるカーネルメモリ破壊のリスクがなくなる
- Hyper-V や Wsl2 など他の仮想化機能との競合を減らせる
- 将来の Windows 更新に伴う相性問題を避けられる
既に Hyper-V ベースの Android エミュレーターに切り替えている場合や、そもそも Android エミュレーターを使っていない場合は、HAXM は「単なるリスク要因」に変わります。「使っていないドライバーを残さない」というのも安定運用の大事なポイントです。
対処3：Windows インプレースアップグレードで OS を上書き修復
HAXM を入れ替えても症状が改善しない、あるいはそもそも他のドライバーが怪しい、という場合に強力なのが Windows 10 のインプレースアップグレード（上書き修復）です。
インプレースアップグレードでは、現在使っている Windows 10 の環境に対して、最新ビルドの Windows 10 を「上書きインストール」します。このとき、通常は以下のものが保持されます。
- ユーザーデータ（ドキュメント、デスクトップ、ピクチャなど）
- インストール済みアプリケーション
- 基本的な設定
一方で、OS のコアファイルや多くのドライバーは最新状態に置き換えられるため、どこかに潜んでいた破損や不整合が一気に解消される可能性があります。
インプレースアップグレードの大まかな流れ
- 事前にバックアップと復元ポイントを作成しておきます。
- Microsoft の公式サイトから Windows 10 のインストール用ツール（更新アシスタントやメディア作成ツール）を入手します。
- ツールを実行し、「この PC を今すぐアップグレード」あるいは「個人用ファイルとアプリを引き継ぐ」を選択します。
- あとはウィザードの案内に従って進め、インストールが完了するまで待ちます。
- 再起動後、Windows のバージョンとビルド番号が新しくなっていることを確認します。
インプレースアップグレードは、作業時間が比較的長く、再起動も複数回行われますが、システムファイルの破損と古いドライバーをまとめてリフレッシュできる「切り札」的な手段です。原因をピンポイントで特定できなくても、広い範囲を一気にクリーンアップできるのが大きな利点です。
対処4：追加の健全性チェック
HAXM の入れ替えと、必要に応じてインプレースアップグレードを行ったら、仕上げとして Windows 全体の健全性チェックをしておくと安心です。ここでは代表的なものを紹介します。
Windows メモリ診断で RAM をチェック
メモリ不良は、どんな種類のブルースクリーンも引き起こす「元凶候補」です。HAXM などソフト側が改善しても、物理メモリに問題があれば再発する可能性があります。
- スタートメニューで「Windows メモリ診断」を検索して起動します。
- 「今すぐ再起動して問題の有無を確認する」を選択します。
- 再起動後、メモリテストが実行され、終了すると結果が表示されます。
エラーが報告された場合は、メモリモジュールの交換を検討する必要があります。複数枚搭載している場合は、1 枚ずつ抜き差しして切り分けを行うと特定しやすくなります。
DISM と SFC でシステムファイルを修復
システムファイルの破損が疑われる場合は、DISM と SFC を組み合わせた修復が有効です。管理者権限のコマンドプロンプトまたは PowerShell を開き、次のコマンドを順番に実行します。
DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow
DISM は Windows イメージ自体をチェック・修復し、SFC はシステムファイルの整合性を確かめて破損したものを正常なコピーで置き換えます。完了後に PC を再起動し、同じエラーが出ないか数日様子を見ましょう。
ドライバーと Windows Update の適用状況を確認
古いドライバーや適用漏れの Windows Update が原因でブルースクリーンが出るケースも少なくありません。
- 「設定」→「Windows Update」から、保留中の更新プログラムがないか確認し、すべて適用する
- グラフィックスドライバー、チップセットドライバー、ストレージドライバーなど、ハードウェアメーカー公式の最新版に更新する
- 不要な古いドライバー（使っていない周辺機器や仮想デバイスなど）はアンインストールする
特に、仮想化関連のドライバー（他社製仮想マシンソフト、旧バージョンのセキュリティソフトのドライバーなど）は、HAXM と同様にカーネルに深く入り込むため、重複や競合がないか注意して見ておきましょう。
ストレージエラーのチェック（必要に応じて）
HDD/SSD の不良セクタやケーブル不良が原因でシステムファイルが破損している場合には、ストレージのチェックも役立ちます。必要に応じて、管理者権限で次のようなコマンドを実行してみてください。
chkdsk C: /f /r
実行には時間がかかるため、PC を長時間触らないタイミングで実行することをおすすめします。
ミニダンプが生成されない場合の設定
ブルースクリーンが出ているのに C:\Windows\Minidump にファイルが生成されない場合、「デバッグ情報の書き込み」設定を確認する必要があります。トラブルシューティングを続けるうえでミニダンプは非常に重要なので、必ず有効にしておきましょう。
小メモリダンプ（256KB）の設定手順
- スタートボタンを右クリックし、「システム」を開きます。
- 右側または下部の「システムの詳細設定」をクリックします。
- 「起動と回復」欄の「設定」ボタンをクリックします。
- 「デバッグ情報の書き込み」で、「小メモリ ダンプ (256 KB)」を選択します。
- 「小メモリ ダンプのディレクトリ」が
%SystemRoot%\Minidumpになっていることを確認します。 - 「OK」で閉じて設定を保存し、必要であれば再起動します。
これで次回ブルースクリーンが発生した際には、C:\Windows\Minidump にミニダンプファイルが生成されるはずです。解析ツール（WinDbg など）を使えば、どのドライバーやモジュールが問題の中心にいるかをより詳しく追跡できます。
INVALID_BALANCED_TREE が示すもの
ミニダンプの解析で INVALID_BALANCED_TREE が出ている、という点も重要な手がかりです。これは、カーネル内部で使われている平衡木構造（バランスツリー）が壊れていることを示すサブコードで、通常は次のような原因で発生します。
- カーネルモードドライバーが誤ったメモリアドレスに書き込み、データ構造を汚した
- メモリ破損（物理 RAM の不良など）で格納されている値が勝手に変わってしまった
- マルチスレッド処理や割り込み処理の中で、ロックを取らずにデータ構造を更新してしまった
このエラー自体は「ツリー構造が壊れています」と知らせているだけで、「どのドライバーが壊したのか」は別途スタックトレースなどから判断する必要があります。今回のように、スタック上に HAXM が登場している、あるいはイベントログに HAXM エラーが集中している場合は、かなり高い確率で HAXM がトリガーだと考えられます。
一方で、HAXM を完全に削除したあとも INVALID_BALANCED_TREE を含む 0x139 が繰り返し発生するようなら、他のドライバーやハードウェア不良も視野に入れて再調査する必要があります。その際は、ドライバーの更新・無効化、メモリ差し替えなど、より広範囲な切り分け作業が必要になるでしょう。
対処方法ごとのメリット・デメリット比較
ここまでに紹介した主な対処方法を、メリットとデメリットの観点から整理しておきます。
| 施策 | メリット | デメリット | 想定シナリオ |
|---|---|---|---|
| HAXM 再インストール | 作業が比較的軽い Android Studio などの設定をほとんど変えずに済む 原因が HAXM にある場合はこれだけで収束することが多い | 古い設定や競合環境が残っていると再発する可能性 HAXM 自体が不要な環境では「余計なドライバー」を残すことになる | Android エミュレーターを HAXM 前提で使い続けたい開発者向け |
| HAXM の完全アンインストール | 根本原因となりうるドライバーを丸ごと排除できる 仮想化関連の競合リスクが減る 長期的な安定性向上につながる | Android エミュレーターを別方式（Hyper-V など）に切り替える必要がある 古いプロジェクトによっては動作検証環境の見直しが必要 | 既に Hyper-V ベースのエミュレーターに移行済み、または今後 HAXM を使う予定がない環境 |
| Windows インプレースアップグレード | OS コアと多くのドライバーをまとめてリフレッシュできる 原因が特定できない場合でも「広く浅く」修復できる Windows Update の適用漏れも同時に解消できることが多い | 作業時間が長く、複数回の再起動が必要 一部の設定やドライバーが再設定・再インストールになることがある ノート PC では AC アダプタ必須など、実行条件が厳しめ | HAXM 以外の要因も疑われる／システム全体の安定性を一度リセットしたいとき |
| メモリ診断・DISM/SFC などの健全性チェック | ハードウェア不良やシステムファイル破損の有無を客観的に把握できる 今後別のエラーが出たときの切り分けにも役立つ | 実行に時間がかかることがある 「異常なし」と表示されても 100% 問題なしとは言い切れない | HAXM 対応が完了したあと、再発防止と念のための確認として実施 |
再発時に確認しておきたいログとチェックポイント
上記の対処を行っても、まれに 0x139 が再発する場合があります。そのときは、次のポイントを重点的に確認してみてください。
- イベントビューアーの確認
「Windows ログ」→「システム」の中で、「BugCheck」「Kernel-Power」などのイベントと、その直前の「エラー」や「警告」をチェックします。特定のドライバー名やサービス名が何度も出ていないか注意して見ましょう。 - ミニダンプの継続的な保存
ミニダンプ設定が正しく行われているか再度確認し、新しいダンプが生成されるたびにバックアップしておきます。複数のダンプを比較することで、共通して現れるドライバーを特定しやすくなります。 - ハードウェア構成の変化
最近増設したメモリ、交換した SSD、接続した USB デバイスなどがきっかけになっていないか振り返ります。新しい機器を外してみるだけで症状が止まることもあります。
特に、「HAXM を削除したのにまだ 0x139 が出る」という状況であれば、別のドライバーやハードウェアに原因が移っている可能性が高いため、イベントログとミニダンプの両方から「共通点」を探すことが重要です。
まとめ：まずは HAXM を見直し、その後システム全体を整える
停止コード 0x139 KERNEL_SECURITY_CHECK_FAILURE は、カーネルが「内部構造の破損」を検出したときに発動する、防御的なブルースクリーンです。今回のように INVALID_BALANCED_TREE が報告され、なおかつ Intel HAXM サービスのエラーがイベントログに多数記録されている場合、HAXM ドライバーの不具合がトリガーとなっている可能性が高いと考えられます。
実際の対処の流れとしては、次のステップで進めるのがおすすめです。
- Intel HAXM を最新版に入れ替える（または不要なら完全アンインストールする）
- 改善しない場合は、Windows 10 インプレースアップグレードで OS とドライバーをまとめてリフレッシュする
- 仕上げとして、Windows メモリ診断・DISM/SFC・ドライバー更新などの健全性チェックを実施する
- ミニダンプ設定を有効にし、再発した場合はダンプ解析で他のドライバーやハードウェアの線も調査する
これらを段階的に実施すれば、多くのケースで 0x139 の再発を防ぎつつ、Windows 10 環境全体の安定性を高めることができます。ブルースクリーンは見た目こそショッキングですが、ログとダンプを丁寧に追っていけば原因にたどり着けるトラブルです。焦らず一つずつ手順を進めて、安定した開発・作業環境を取り戻していきましょう。
コメント