「朝だけ Windows 10 を起動すると必ずブルースクリーン（BSOD）で落ちる。でも再起動すると普通に使える…」という現象は、実は Android エミュレーターと Hyper‑V（Windows ハイパーバイザー）の相性問題で起きることがあります。ここでは、実際に HYPERVISOR_ERROR／UNEXPECTED_STORE_EXCEPTION が解消した手順を、再現性の高いチェックリスト付きで整理します。
毎朝の起動時だけブルースクリーンになる症状
まずは今回のケースを整理します。同じような現象に悩んでいる場合、かなり高い確率でパターンが一致するはずです。
| 項目 | 内容 |
|---|---|
| 発生タイミング | 朝一番のコールドブート直後（完全な電源OFFからの起動） |
| 現象 | 起動途中でブルースクリーン（BSOD）発生。 エラーコード：HYPERVISOR_ERROR または UNEXPECTED_STORE_EXCEPTION |
| その後 | 自動再起動後は Windows が普通に起動し、その日は問題なく使える |
| OS | Windows 10 Enterprise LTSC 21H2（バージョン 19044） |
| ハードウェア | ASUS TUF Gaming、Ryzen 7 7735HS 搭載ノートPC |
| ログ上の手がかり | ブルースクリーン時のスタックに smss.exe（セッションマネージャ）が登場 ntdll.dll もスタック上に確認 Driver Verifier で調査すると、Android エミュレーター関連ドライバー が関与している疑い |
つまり、Windows がユーザー環境を立ち上げる、かなり初期の段階でハイパーバイザー関連ドライバーがコケている、という構図です。
結論：原因は Android エミュレーターのハイパーバイザー連携
今回のケースでは、最終的に Android Studio とそのエミュレーター（AVD）をアンインストールし、再起動 したことで、毎朝の BSOD が完全に止まりました。
ポイントは次の 3 つです。
- Android エミュレーターは、標準設定で Hyper‑V／Windows ハイパーバイザー プラットフォーム（WHPX） を利用する
- Windows 起動初期の
smss.exe実行フェーズで、ハイパーバイザー系ドライバーに異常があると HYPERVISOR_ERROR に発展しやすい - 高速スタートアップや休止状態によって、前日のハイパーバイザー状態が中途半端に持ち越される と、朝一の起動だけ不安定になりやすい
この「Android エミュレーター × Hyper‑V × 高速スタートアップ」の三点セットがそろうと、朝だけ落ちるという非常にイヤなパターンが出来上がります。
実際に効いた最優先の対処法
Android Studio／エミュレーターをアンインストールする
最も確実かつ手っ取り早いのは、問題の発火源である Android Studio と AVD（Android Virtual Device）エミュレーターをアンインストール してしまうことです。
大まかな手順は以下の通りです。
- アプリのアンインストール
- 「設定」→「アプリ」→「インストールされているアプリ」
- Android Studio をアンインストール
- 別途インストールしている Android エミュレーター関連ツールがあれば、まとめて削除
- 残った AVD／SDK の掃除（可能なら）
C:\Users\ユーザー名\.android\avdなどに AVD データが残っていれば削除C:\Android、C:\Users\ユーザー名\AppData配下の Android 関連フォルダーも、不要であれば削除
- ここが重要：必ず「再起動」する
- アンインストール直後に PC の電源メニューから 「再起動」 を選択
- 「シャットダウン」ではなく再起動 にするのがポイント
再起動後、いったん完全にシャットダウンし、翌朝のコールドブートで BSOD が出なければ、ほぼ原因は Android エミュレーター関連ドライバーだったと考えて良いでしょう。
なぜ「再起動」が必須なのか
Windows 10 では、既定で 高速スタートアップ が有効になっています。高速スタートアップは、シャットダウン時にカーネルの状態を休止状態として保存し、次回起動時にそれを読み戻すことで、起動時間を短縮する仕組みです。
ところが、ハイパーバイザーのような低レベルのコンポーネントをアンインストールした直後にシャットダウンすると、古いハイパーバイザー状態のスナップショット が残ったままになり、次回起動時に妙な状態で復元されることがあります。
一方、再起動は「完全なカーネルの再読み込み」 を行うため、新しいドライバー構成でまっさらな状態から立ち上がります。つまり、環境をクリーンな状態に更新するためには、必ず再起動が必要 なのです。
アンインストールしたくない場合の代替策
「Android アプリの開発をしているので、エミュレーター自体は使い続けたい」というケースも多いはずです。その場合は、次の手順を優先順位順に試してみてください。
代替策① ハードウェア支援を使わない（ソフトウェアエミュレーション）
Android エミュレーターは、CPU の仮想化支援機能（AMD-V / Intel VT-x）や Hyper‑V を利用して高速動作を実現していますが、あえてソフトウェアエミュレーションで動かす 設定も用意されています。
一般的な方針は以下の通りです。
- AVD の設定で、ハードウェアアクセラレーション（WHPX / Hyper‑V）を使用しない 設定に切り替える
- 「仮想デバイスマネージャー」で各 AVD の設定から、ハイパーバイザー依存のオプションを無効化する
- パフォーマンスは低下しますが、起動時 BSOD のリスクは大きく下がる
開発作業では実機テストを中心にし、エミュレーターは軽い動作確認にとどめる、といったワークフローに切り替えるのも現実的です。
代替策② Hyper‑V／WHP／仮想マシンプラットフォームを使い分ける
Android エミュレーターを使う時間帯以外は、Hyper‑V や Windows ハイパーバイザー プラットフォームを無効化しておく のも有効です。Windows の機能としてオン／オフが可能なので、必要なときだけ有効にする運用にします。
無効化の手順の一例です。
- 「スタート」メニューで 「Windows の機能の有効化または無効化」 を検索し、開く
- 以下のチェックを外す（必要に応じて）
- Hyper‑V
- Windows ハイパーバイザー プラットフォーム
- 仮想マシン プラットフォーム
- OK を押すと再起動を促されるので、必ず再起動
Android エミュレーターを利用するタイミングで、必要に応じて再度チェックを付けて再起動する…という運用は少し手間ですが、「PC を仕事用として安定稼働させたい時間帯」と「開発用として多少不安定でも許容できる時間帯」を分ける という意味ではかなり現実的です。
代替策③ Android Studio／エミュレーターの自動起動を止める
ログオン直後に Android Studio や関連サービスが自動起動するよう設定している場合、起動初期の不安定なタイミングでハイパーバイザーが動き始める ことになります。
これを避けるには、以下のようにスタートアップを整理します。
- タスクマネージャーを起動（Ctrl + Shift + Esc）
- 「スタートアップ」タブを開く
- Android Studio や関連するサービスがあれば、「無効」 に変更
必要なときだけ手動で Android Studio を起動するようにすれば、OS が完全に安定してからハイパーバイザーが動き出す 形にできるため、起動時の BSOD を避けやすくなります。
代替策④ 高速スタートアップを無効化する
「朝だけ落ちる」問題の定番対処 が、高速スタートアップの無効化です。前述の通り、高速スタートアップはカーネル状態を休止し、それを使い回す機能です。これがハイパーバイザー状態と相性が悪いと、前日の不安定な状態をそのまま翌朝に持ち越す ことになります。
高速スタートアップの無効化手順は以下の通りです。
- 「コントロール パネル」→「ハードウェアとサウンド」→「電源オプション」を開く
- 左メニューから 「電源ボタンの動作を選択する」 をクリック
- 上部の 「現在利用可能ではない設定を変更します」 をクリック
- 「シャットダウン設定」の 「高速スタートアップを有効にする（推奨）」 のチェックを外す
- 「変更の保存」をクリックし、再起動
これにより、シャットダウン → 電源オンが毎回クリーンな起動になります。起動時間は若干長くなりますが、朝一で落ちて再起動に時間を食うより、結果的にはストレスが少ない ケースがほとんどです。
代替策⑤ Windows／ドライバー／BIOS を最新化する
ハイパーバイザー周りは、OS・チップセットドライバー・BIOS／ファームウェア の相性にも強く影響を受けます。特に Ryzen 搭載機では、初期 BIOS からのアップデートで安定性がかなり改善することも珍しくありません。
- Windows Update：品質更新プログラムと .NET の更新を含め、最新まで適用
- AMD チップセットドライバー：AMD 公式サイト or ASUS サポートページから最新を取得
- GPU ドライバー：Radeon / NVIDIA いずれも最新版に更新
- ASUS の BIOS／ファームウェア：機種名で検索し、サポートページから最新 BIOS を確認
特に「仮想化」「SVM」「IOMMU」などの設定項目が BIOS にある場合、最新 BIOS で挙動が改善しているケースも多いため、アップデート → 設定の見直し を一度は行っておきたいところです。
代替策⑥ DISM／SFC でシステム整合性をチェックする
ブルースクリーンが発生した環境では、システムファイルが一部破損している可能性も否定できません。念のため、以下の 2 コマンドで Windows のイメージとシステムファイルを検査・修復しておきましょう。
- スタートメニューから「Windows PowerShell（管理者）」または「コマンドプロンプト（管理者）」を開く
- 次のコマンドを順に実行
DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow
どちらも完了するまで時間がかかる場合がありますが、エラーが出ないことを確認し、最後に再起動 しておくと安心です。
代替策⑦ ストレージ／メモリの健全性も一度は確認する
今回は Android エミュレーターが原因だったとはいえ、UNEXPECTED_STORE_EXCEPTION はストレージ周りの問題で出ることもあります。万一に備え、以下もチェックしておきましょう。
- ストレージチェック
- 管理者権限のコマンドプロンプトで次を実行：
chkdsk /scan - NVMe SSD の S.M.A.R.T. 情報を、メーカー提供ツールなどで確認
- 管理者権限のコマンドプロンプトで次を実行：
- メモリ診断
- スタートメニューで「Windows メモリ診断」を検索して起動
- 「今すぐ再起動して問題の有無を確認する」を選択
これらで物理的な故障の兆候が見つかれば、ハイパーバイザー問題とは別に、早めのストレージ／メモリ交換も検討すべきです。
なぜ「smss.exe」とハイパーバイザーが関係するのか
解析ログには smss.exe（Session Manager Subsystem）や ntdll.dll が登場していました。これだけを見ると「セッションマネージャの問題？」と感じるかもしれませんが、実際には 起動初期の重要プロセスがハイパーバイザーに足を引っ張られている 状態と理解すると分かりやすくなります。
smss.exeは、ユーザーセッションや仮想メモリ、環境変数などを初期化する重要なプロセス- このフェーズでハイパーバイザー関連ドライバーが例外を出すと、CRITICAL_PROCESS_DIED や UNEXPECTED_STORE_EXCEPTION などの汎用バグチェックに巻き込まれやすい
- Driver Verifier で Android エミュレーター関連ドライバーが怪しいと出ているなら、ほぼそれがトリガー と考えてよい
つまり、表向きのエラーコードは別でも、「ハイパーバイザーが smss.exe の足を引っ張っている」 という構造を疑うのがコツです。
再発時に使える診断フロー
同じような「朝だけ BSOD」問題が再発した場合に備え、シンプルな診断フローをまとめておきます。
| ステップ | 確認内容 | ポイント |
|---|---|---|
| 1 | Android Studio／エミュレーターの有無を確認 | 入っているなら、まずアンインストール＆再起動で様子を見る |
| 2 | 高速スタートアップを無効化 | シャットダウン → 電源ONを完全なクリーン起動にする |
| 3 | Hyper‑V／WHP／仮想マシンプラットフォームの状態確認 | 不要なら無効化。必要なら ON／OFF の切り替えで挙動が変わるか確認 |
| 4 | Windows Update とドライバー更新 | 特に AMD チップセット／GPU／BIOS を最新化 |
| 5 | DISM／SFC によるシステム整合性チェック | システムファイルの破損を除外する |
| 6 | ストレージ／メモリ診断 | 物理故障が疑われる場合は早めに切り分け |
ここまで実施しても改善しない場合は、ミニダンプを WinDbg などで詳細解析 し、問題のドライバー名を特定するフェーズになります。それでもハイパーバイザー関連が怪しければ、仮想化機能自体を完全にオフにして運用する（仮想マシンは別の PC で動かすなど）判断も視野に入れてよいでしょう。
よくある疑問への回答
高速スタートアップを切ると起動が遅くならない？
確かに、高速スタートアップを無効化すると、シャットダウン → 起動の時間は数秒〜十数秒ほど長くなります。ただし、
- 朝一で BSOD → 自動再起動 → 再ログオン、という時間ロス
- 「ちゃんと起動するか毎朝ヒヤヒヤする」という心理的負担
これらを考えると、多少起動が遅くなっても、毎回安定して起動してくれる方がトータルのストレスは少ない 場合がほとんどです。どうしても起動時間が気になる場合は、スリープ主体の運用に切り替えるのも一つの手です。
Hyper‑V を無効化しても、他の機能に影響はない？
Hyper‑V／WHP／仮想マシンプラットフォームを無効化すると、
- Hyper‑V 上の仮想マシン
- WHPX を利用する一部の仮想化ソフトウェア
- Android エミュレーターのハードウェアアクセラレーション
などが動かなくなります。一方で、通常の Office 作業やブラウジング、軽い開発作業にはほぼ影響しません。「開発用 VM を別 PC に移す」「Docker Desktop を WSL2 モードで使う」など、仮想化を OS 標準の Hyper‑V に頼らない運用 を検討するのも良い選択肢です。
Android エミュレーターの代わりに実機テストだけでも大丈夫？
近年の Android 開発では、実機テスト中心のワークフロー に移行している現場も多く、必ずしもエミュレーターが不可欠というわけではありません。特にパフォーマンスやカメラ・センサーを多用するアプリの場合、実機テストの方がむしろ現実的です。
どうしてもエミュレーターが必要な場合は、
- 仮想化専用の PC を 1 台用意する
- クラウド上のリモートデバイス（テストサービス）を利用する
といった構成も検討してみる価値があります。
すぐ使えるチェックリスト（最終確認用）
最後に、今回の内容をそのまま作業メモとして使えるよう、チェックリスト形式でまとめます。
- [ ] Android Studio／AVD をアンインストールした
- [ ] アンインストール後に 「シャットダウン」ではなく「再起動」 を実行した
- [ ] 継続利用する場合、エミュレーターのハードウェア支援（WHPX／Hyper‑V）をオフにした
- [ ] Hyper‑V／Windows ハイパーバイザー プラットフォーム／仮想マシンプラットフォームを、未使用時はオフにしている
- [ ] 高速スタートアップを無効化した
- [ ] Windows Update を最新まで適用した
- [ ] AMD チップセット／GPU ドライバー、ASUS の BIOS／ファームウェアを更新した
- [ ] DISM → SFC を実行し、エラーがないことを確認した
- [ ] 必要に応じて
chkdsk /scanや「Windows メモリ診断」を実行した
まとめ：朝だけ落ちる BSOD は「仮想化まわり」を疑う
毎朝のコールドブート時にだけ HYPERVISOR_ERROR や UNEXPECTED_STORE_EXCEPTION が発生し、再起動後は安定している――という症状は、典型的な Android エミュレーターのハイパーバイザー関連ドライバーとの競合 パターンでした。
最も効果的だったのは、
- Android Studio／エミュレーターのアンインストール
- その直後の「再起動」
というシンプルな手順です。これで現象が再発しないようであれば、原因はほぼ確実にエミュレーター側 と見てよいでしょう。
もしアンインストールしたくない場合は、
- エミュレーターをソフトウェアエミュレーションで運用する
- Hyper‑V／WHP を必要なときだけオンにする
- 高速スタートアップを無効化して、毎回クリーンな起動にする
といった工夫で、開発環境と安定稼働の両立 を目指すことができます。
「朝だけブルースクリーンになる」「原因がストレージなのかドライバーなのか分からない」といった場合は、まずは仮想化まわりと Android エミュレーターを疑い、本記事のチェックリストに沿って一つずつ潰していくことで、安定した Windows 10 環境を取り戻すことができるはずです。
コメント