LARG Studio

VirtualBoxが異常に重い・再起動やシャットダウンで固まる原因がWindows Hello/VBSだった実例【AMD-V/NEM】

LARG LABO / TROUBLESHOOTING LOG

Windows 11ホスト上のVirtualBoxで、ゲストOS自体は高負荷ではないのにホスト側だけCPU負荷が跳ね上がる、再起動やシャットダウンの途中で固まる、ウィンドウを非アクティブにすると戻ってこない、といった症状に遭遇した。

最終的に今回の環境では、Windows Hello配下のDeviceGuardシナリオがVBS（Virtualization-Based Security）を生かし続け、WindowsハイパーバイザーがAMD-Vを先に確保していたことが大きな原因だった。VirtualBoxはAMD-Vを直接使えず、NEM / Hyper-V経由の低速実行へフォールバックしていた。

Windows Helloを無効化してVBSを停止させた結果、VirtualBoxの実行エンジンはNEMからVT-x/AMD-Vへ切り替わり、起動・再起動・シャットダウンが数秒単位まで短縮した。

症状

  • VirtualBox起動中、ホストWindows側のCPU負荷が高い。
  • ゲスト側のCPUインジケーターは高負荷ではない。
  • Windowsゲストの再起動・シャットダウン画面で停止する。
  • VirtualBoxの「閉じる」メニューを開いてキャンセルすると、止まっていた処理が再開する。
  • 負荷中にゲストからホストへフォーカスを移すと、ゲストが固まりやすい。
  • Pause / Resume相当の操作を入れると復帰することがある。

特に不可解だったのは、ゲストOSではなくホスト側VirtualBoxプロセスだけが高負荷になる点だった。

VirtualBoxログでNEM / Snail実行を確認

実行ログを確認すると、VirtualBoxはAMD-Vを直接使用できず、NEMへフォールバックしていた。

HM: HMR3Init: Attempting fall back to NEM: AMD-V is not available
NEM: WHvCapabilityCodeHypervisorPresent is TRUE
PGM: Enabling NEM mode
NEM: NEMR3Init: Snail execution mode is active!

この状態ではVirtualBox自身も「Hyper-Vを使用するWindows機能を無効化しないと最大速度で動作できない」とログへ出していた。

確認には次のコマンドを使用した。

& "$env:ProgramFiles\Oracle\VirtualBox\VBoxManage.exe" showvminfo "Windows" --log 0 |
Select-String "AMD-V|NEM|Snail|HM:"

Hyper-Vを切ったはずなのにVBSが生きていた

通常のHyper-V、Windows Hypervisor Platform、Virtual Machine Platform、Memory Integrityなどを確認しても、VirtualBoxはAMD-Vを直接取得できなかった。

DeviceGuardの実状態を確認すると、次のようになっていた。

Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard -ClassName Win32_DeviceGuard |
Format-List *

結果は、Credential GuardやMemory Integrityの実行サービスがないにもかかわらず、VirtualizationBasedSecurityStatus = 2。つまりVBS自体は有効かつ実行中だった。

VirtualizationBasedSecurityStatus : 2
SecurityServicesConfigured        : {0}
SecurityServicesRunning           : {0}

通常のDeviceGuard設定は0。それでもVBSは動いていた

レジストリを確認すると、一般的なVBS有効化キーは両方とも0だった。

Get-ItemProperty `
'HKLM:\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard',
'HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard' `
-ErrorAction SilentlyContinue |
Format-List *
EnableVirtualizationBasedSecurity : 0
Locked                            : 0

ここが今回の落とし穴だった。通常のVBSキーだけを見れば「無効」に見えるのに、実際のVBSステータスは2だった。

DeviceGuardのScenarioを確認するとWindowsHelloだけが1

Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios' -ErrorAction SilentlyContinue |
ForEach-Object {
    $p = Get-ItemProperty $_.PSPath
    [PSCustomObject]@{
        Scenario = $_.PSChildName
        Enabled  = $p.Enabled
        Locked   = $p.Locked
        WasEnabledBy = $p.WasEnabledBy
    }
} | Format-Table -AutoSize

この環境では次の結果だった。

Scenario                        Enabled
HypervisorEnforcedCodeIntegrity       0
KernelShadowStacks                    0
KeyGuard
WindowsHello                          1

有効になっていたのはWindowsHelloだけだった。

WindowsHelloシナリオをバックアップして無効化

注意：この変更はWindows HelloのPIN・顔認証・指紋認証などへ影響する可能性がある。Windowsアカウントのパスワードでログインできる状態を確認してから行う。環境によって原因は異なるため、VBSステータスやScenarioを確認せず機械的に実行する手順ではない。

まずバックアップ。

reg export "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\WindowsHello" "$env:USERPROFILE\Desktop\WindowsHello-backup.reg" /y

その後、Enabledを0へ変更。

Set-ItemProperty `
'HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\WindowsHello' `
-Name Enabled -Type DWord -Value 0

設定確認。

Get-ItemProperty `
'HKLM:\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\WindowsHello' |
Select-Object Enabled

Enabled = 0を確認した後、ホストWindowsを再起動した。

再起動後、VBSとWindowsハイパーバイザーが停止

Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard -ClassName Win32_DeviceGuard |
Select-Object VirtualizationBasedSecurityStatus,SecurityServicesConfigured,SecurityServicesRunning

結果はVirtualizationBasedSecurityStatus = 0。

VirtualizationBasedSecurityStatus : 0
SecurityServicesConfigured        : {0}
SecurityServicesRunning           : {0}

さらにホストWindowsのハイパーバイザーも停止した。

Get-CimInstance Win32_ComputerSystem |
Select-Object HypervisorPresent
HypervisorPresent
-----------------
False

VirtualBoxがNEMからAMD-V直実行へ切り替わった

VM起動後に同じログ確認を行うと、実行経路が完全に変わった。

HM: HMR3Init: AMD-V w/ nested paging
HM: Using AMD-V implementation 2.0
HM: Enabled SVM
HM: Enabled nested paging
HM: VT-x/AMD-V init method: Local
HM: VT-x/AMD-V enable method: VirtualBox

VirtualBoxの実行中インジケーターも、以前のNative API/NEM系表示から「実行エンジン：VT-x/AMD-V」へ変化。ネステッドページングと無制限実行も有効になった。

なお、表示上の「準仮想化インターフェース：Hyper-V」は、Windowsゲスト向けにVirtualBoxが提供するparavirtualization interfaceの設定であり、ホストWindowsでHyper-Vハイパーバイザーが動いていることを意味しない。今回もホスト側はHypervisorPresent=Falseの状態で、この表示はHyper-Vのままだった。

結果

  • ホスト側の常時高負荷が解消。
  • ゲスト側の動作が安定。
  • フォアグラウンド／バックグラウンド切替後も復帰。
  • ゲストのシャットダウンが約3〜5秒で完了。
  • 起動が約5〜6秒。
  • 再起動も数秒単位で正常完了。
  • 「閉じるメニューを開いてキャンセルしないと再起動が進まない」現象が消失。

別件：VirtualBox 7.2.20でインストール破損も発生

今回の調査中、VirtualBox 7.2.20環境では別の異常も確認した。VBoxManage.exeが0 byteになり、USBエミュレーション失敗、ブリッジアダプターの物理NICを列挙できない状態になった。

7.2.20を一度削除し、7.2.18 r175117を再インストールすると、VBoxManage.exeは正常サイズへ戻り、主要ホストドライバも7.2.18へ統一された。

ただし、これは7.2.20全体に共通する既知バグだと断定しているわけではない。今回のホストで7.2.20のインストール状態が破損していた、という観測記録として分離して扱う。

このパターンで確認する順番

  1. VirtualBoxログで AMD-V is not available / NEM / Snail execution mode が出ていないか確認。
  2. VirtualizationBasedSecurityStatus を確認。
  3. VBSが2なら、SecurityServicesだけでなくDeviceGuard\Scenarios配下を確認。
  4. WindowsHelloだけがEnabled=1なら、バックアップ後に0へ変更して再起動。
  5. VBS Status=0、HypervisorPresent=Falseを確認。
  6. VirtualBoxログが AMD-V w/ nested paging / Enabled SVM へ変わったことを確認。
  7. 最後に再起動・シャットダウン・フォーカス切替を実運用条件で確認。

「Hyper-Vを無効にしたのにVirtualBoxがまだNEMで動く」「Memory IntegrityもOFFなのにAMD-Vを直接使わない」という場合、Windows Hello側のDeviceGuard ScenarioがVBSを生かしているケースもある。今回の最大の落とし穴はそこだった。

昼から夜まで追いかけた末、最後に出てきたラスボスがWindows Helloだった。仮想化トラブルは、設定画面の見た目だけでは終わらない。

dai

,
, , , ,