VirtualBoxでWindows 11が黒い画面になるときの切り分け——1コアで起動できた検証記録

VirtualBoxでWindows 11の検証用VMを作ったところ、起動直後から黒い画面のまま止まり、Windowsのロゴも表示されませんでした。

今回の環境では、CPUを一時的に1コアへ変えるとセットアップ画面まで進めたため、ISOや仮想ディスクだけの問題ではないと切り分けられました。最終的には通常のインストールではなく、検証用VMとしてWindowsイメージを展開する回避策で起動しています。

ただし、原因を「EFIと2コアの組み合わせ」と断定できたわけではありません。ホスト側のハイパーバイザー、VirtualBoxの版、仮想マシン設定など複数の要素が関係した可能性があります。この記事は、同じような黒画面が出たときに確認する順番と、今回の検証記録をまとめたものです。

忙しい人向けの結論

1コアで画面が出ても、それが恒久的な解決とは限りません。Windows 11のVMは2コア以上、UEFI、Secure Boot対応、TPM 2.0、64GB以上のストレージを前提に作るのが基本です。

Windows 11のストレージ要件は64GB以上です。今回の50GBは検証途中の構成だったため、これから作成する場合は64GB以上にしてください。

保存状態が残っていると、設定を変えても以前の状態から再開されることがあります。「閉じる」ではなく「仮想マシンの電源オフ」を選び、VirtualBoxの管理画面で「電源オフ」になっていることを確認します。

ストレージ設定でISOが光学ドライブへ接続されているか、起動順序で光学ドライブが有効かを確認します。別のVMでISOを起動できれば、ISOファイル自体の切り分けにもなります。

Windowsゲストでは、まず次の構成で確認しました。

環境によっては3Dの有効・無効で挙動が変わるため、ひとつずつ変更して比較します。

今回の環境では2コアだと黒い画面でしたが、1コアにするとWindowsセットアップが表示されました。これで「ISOがまったく起動できない」のではなく、複数CPUを含む仮想化経路で問題が起きている可能性が見えてきました。

ただし、Windows 11は2コア以上を要件としているため、1コアのまま通常インストールを完了する方法ではありません。あくまで切り分けです。

ログは通常、次の場所にあります。

C:\Users\ユーザー名\VirtualBox VMs\仮想マシン名\Logs\VBox.log

今回のログには次の記録がありました。

HM: HMR3Init: Attempting fall back to NEM: VT-x is not available
NEM: WHvCapabilityCodeHypervisorPresent is TRUE

これは、VirtualBoxがVT-xを直接利用せず、Windowsのハイパーバイザーを経由するNEMへ切り替わったことを示します。ただし、この行があるだけで黒画面の原因と確定するわけではありません。起動時刻周辺のエラーや停止位置も合わせて確認します。

VirtualBoxのトラブル情報では、Hyper-V、仮想マシンプラットフォーム、Windowsハイパーバイザープラットフォーム、VBS、メモリ整合性の無効化が案内されることがあります。

これらを止めるとVirtualBoxの動作が変わる場合はありますが、Windows Sandbox、WSL 2、Credential Guardなどへ影響し、セキュリティも弱める可能性があります。今回も無効化だけでは改善しませんでした。

検証する場合は、現在値と戻す手順を記録し、必要な機能がないテストPCに限定してください。変更後に改善しなければ、元へ戻します。

# ハイパーバイザーを再び自動起動へ戻す例（管理者権限）
bcdedit /set hypervisorlaunchtype auto

# VSMを再び自動起動へ戻す例（変更していた場合）
bcdedit /set vsmlaunchtype auto

反映には実PCの再起動が必要です。組織管理PCでは、自分で変更せず管理担当者へ確認してください。

DISMによる展開へ進む前に、WindowsセットアップのCPU要件を回避するLabConfigも試しました。しかし、今回の環境では同じ要件画面が表示され、通常セットアップを続けられませんでした。

通常セットアップを進められなかったため、今回の検証用VMでは、BIOS・MBR構成へ変更し、WinPEからDISMでWindowsイメージを展開しました。その後、CPUを2コアへ戻すことでデスクトップまで起動しています。

ただし、これはWindows 11が想定するUEFI・Secure Boot・TPM 2.0の標準構成から外れます。GPOの動作確認など、ネットワークを隔離した短期検証には使えても、本番利用や重要なデータを扱うVMへそのまま勧められる構成ではありません。

同じ症状でも、まずは新しいVMを64GB以上・2コア・EFI・TPM 2.0で作り直し、VirtualBoxの最新版と新しいISOで再確認する方が安全です。

このVMをGPO検証へ使う場合は、OSのセットアップ後にGPOでネットワークドライブを配布する手順も確認できます。

ホストの起動設定を戻す場合も、上記の auto は変更前が自動起動だったときの例です。元の値や設定の有無を控えていない場合は、一律に書き換えず先に確認します。今回の記録では黒画面の単一原因までは特定できていないため、セキュリティ機能の無効化を解決策として繰り返す手順にはしていません。