Whonix VMs (Gateway + Workstation) hang at black screen during boot under VirtualBox 7.2.10 on Windows 11 with active VBS/HVCI (NEM mode)

Support
1

1. Problem Summary

  • Symptom: Both Whonix VMs (Gateway and Workstation) hang on a black screen immediately after the “Choose boot mode” menu selection.

  • Reproducibility: The issue is fully reproducible on every boot, even after multiple complete fresh imports of the OVA file.

  • ACPI shutdown does not work: When the VM is hung, it does not respond to ACPI power-button signals from VirtualBox. Only “Power off” (hard shutdown) terminates the VM.

  • Comparison VM works fine: A parallel Windows 11 guest VM running under the same VirtualBox installation boots without any issues. The problem is therefore Whonix/Linux-specific.

  • Notable finding in VBox.log: Consistent entries NEM: Destroying partition … indicate that VirtualBox is running in NEM mode (Native Execution Manager via the Windows Hypervisor Platform) instead of using native VT-x hardware virtualization.

  • No network activity inside the VM: E1000 adapters show Received frames: 0 / Transmitted frames: 0 – the VM never reaches a functional userspace.

2. System Specifications

Host

  • OS: Windows 11 (latest patch level)

  • RAM: 64 GB

  • Hyper-V Windows feature: Disabled (verified via Get-WindowsOptionalFeature)

    • Microsoft-Hyper-V-All: Disabled

    • HypervisorPlatform: Disabled

    • VirtualMachinePlatform: Disabled

    • Containers-DisposableClientVM: Disabled

  • WSL2 / Windows Sandbox / Docker: Not installed yet, but planned for future use – disabling VBS is therefore not an option.

  • VBS status (relevant!):

    • VirtualizationBasedSecurityStatus = 2 (= actively running)

    • SecurityServicesRunning = {2} (= HVCI / Memory Integrity is running)

    • bcdedit hypervisorlaunchtype not explicitly set (default = Auto)

  • Device Security / Memory Integrity: Enabled

VirtualBox

  • Version: 7.2.10 r174163 (Qt6.8.0 on Windows)

  • Hardening log: Shows a regular execution flow, no anomalies.

Whonix

  • Image: Whonix-LXQt-18.1.4.2.Intel_AMD64.ova

  • Variant: LXQt (with graphical desktop)

  • Configuration: Whonix default settings (preserved across multiple re-imports)

Comparison VM (for reference)

  • OS: Windows 11 (as guest)

  • Status: Boots successfully under identical host configuration.

3. Diagnostic Steps and Configuration Changes Performed

3.1 Initial attempts – VirtualBox graphics configuration

  • Tested VBoxVGA as graphics controller → no improvement

  • Tested VMSVGA (Whonix default) → no improvement

  • Varied graphics memory: 128 MB → 64 MB → 33 MB → 16 MB → no improvement

  • Tested VBoxSVGA → VM hangs even earlier, before bootloader appears

  • Disabled 3D acceleration → no effect on the symptom

Conclusion: The problem cannot be solved by graphics driver selection alone.

3.2 Changing VirtualBox OS type

  • Changed OS type from Whonix default to “Other Linux (64-bit)”

  • Result: Gateway booted successfully on the first attempt

  • Insight: VirtualBox applies OS-type-specific hardware defaults that conflict with the Whonix OVA configuration.

  • Important: This trick did NOT work for the Workstation – only the Gateway benefited.

3.3 GRUB boot parameter modifications (for diagnosis)

  • Removed quiet splash from the kernel line to make boot messages visible

  • Added nomodeset 3 to force text mode without DRM driver

  • Tested clocksource=hpet tsc=unstable no_timer_check to bypass TSC-related issues

  • Result: No consistent improvement; boot behavior remained non-deterministic.

3.4 Arrow key phenomenon (NOT a reliable workaround!)

  • Observation: Repeatedly pressing the Up Arrow key during boot occasionally appeared to trigger successful boots

  • Important caveat: This behavior was NOT reliably reproducible:

    • Worked only occasionally with very low success rate

    • Stopped working entirely on later boot attempts

    • Most likely a coincidental correlation with other factors (timing, host background processes, CPU load, RNG pool state)

  • Conclusion: There is no known reliable workaround via keyboard input.

  • This observation should therefore not be considered a meaningful diagnostic indicator.

3.5 Paravirtualization

  • Set --paravirtprovider kvm (instead of default)

  • VBox.log confirms: GIM: KVM: Enabled wall-clock struct… → KVM paravirt is active

  • Result: No improvement in boot behavior.

3.6 CPU and hardware tweaks

  • Reduced CPU count from 2 to 1 → VM boot failed even earlier (before bootloader)

  • Reset CPU count to 2 → previous state restored

  • Changed chipset from PIIX3 to ICH9 → VM no longer reached the boot menu at all

  • Reset chipset to PIIX3 → previous state restored

  • Explicitly enabled APIC + x2APIC → no improvement

  • Explicitly enabled Nested Paging → no improvement

  • Enabled PAE/NX → no improvement

3.7 TSC mode override

  • Set VBoxInternal/TM/TSCMode = VirtTscEmulated

  • Background: VBox.log contained the warning: TM: Host/VM is not suitable for using TSC mode ‘RealTSCOffset’, request to change TSC mode ignored

  • Result: VM aborted even earlier in the boot process → override was reverted.

3.8 Hardware complexity reduction

  • Disabled audio controller (–audio-driver none)

  • Disabled all USB controllers (OHCI/EHCI/xHCI all off)

  • Changed pointing device from USB tablet to PS/2 mouse

  • Result: No significant improvement in symptom.

3.9 RAM configuration

  • Set Gateway RAM to 1024 MB (from default)

  • Set Workstation RAM to 2048 MB

  • Result: No improvement.

3.10 Serial console for diagnostics

  • Redirected UART1 (0x3F8 IRQ4) to a log file (–uart1 0x3F8 4 --uartmode1 file …)

  • Added console=ttyS0,115200 to boot parameters

  • Result: When the VM hangs, no kernel output is written to the file → confirms that the hang occurs very early (before kernel console initialization).

3.11 Aggregated “NEM-optimized” configuration (all recommendations combined)

  • Simultaneously applied: Single CPU + ICH9 + APIC/x2APIC + Nested Paging + Paravirt default + VirtTscEmulated

  • Result drastically worsened: VM runtime dropped from ~9:45 min (previous attempt) to only 0:33 min before hang

  • The boot mode selection menu was no longer reached at all

  • Conclusion: The combination of these optimizations is counterproductive.

3.12 VBox.log analysis – key findings

During some boots (before “optimizations”):

00:00:12.370156 GIM: KVM: VCPU 0: Enabled system-time struct…

00:00:18.319976 GIM: KVM: Enabled wall-clock struct…

00:04:38.489372 ip6_icmp: MTU is too small to hold RDNSS options!

→ VM booted (slowly), network became active, Tor init started

During failed boots (standard case + aggregated config):

00:00:12 GIM: KVM: …[NO further entries until hard shutdown]

00:00:33 NEM: Destroying partition … with its 1 VCpu…

00:00:33 E1000#0: Received frames: 000:00:33 E1000#0: Transmitted frames: 0

→ VM ran for 33 seconds without any boot progress; networking subsystem never activated.

3.13 Windows host hypervisor status (intentionally NOT changed)

  • VBS was deliberately not disabled, because Memory Integrity, WSL2, Sandbox, and Docker (Hyper-V-free mode) are required in the future.

  • Consequence: VirtualBox is forced into NEM mode.

  • VBox.log confirms: NEM: Destroying partition … is present in all logs.

4. Hypotheses / Suspected Cause

  • NEM mode + Linux 6.x kernel (Whonix kernel) appear to be incompatible:

    • TSC drift (TSC unreliable under NEM)

    • Display synchronization between VirtualBox VMSVGA and Linux DRM driver breaks down

    • Entropy starvation: RDRAND/RDSEED appear unreliable under NEM → blocks systemd / cryptographic init

  • Comparison argument: The Windows 11 guest works because the Microsoft kernel natively uses Hyper-V enlightenments. The Linux kernel does not have equivalent support in this NEM scenario.

  • Whonix-specific: Whonix’s anti-fingerprinting measures and hardened kernel configuration may exacerbate the underlying NEM problem (hypothesis).

5. Questions / Requests for the Whonix Team

  • Are there official recommendations for running Whonix on Windows 11 with active VBS / in NEM mode?

  • Is a Hyper-V variant of the Whonix OVA available or planned?

  • Are there recommended kernel boot parameters for booting under NEM mode?

  • Could future Whonix releases include NEM-specific workarounds by default?

  • Is it known whether the CLI variant (Whonix-CLI without LXQt) avoids this issue?

  • Is there an officially supported path for Whonix on hosts where VBS/HVCI must remain active?

I am willing to provide further logs, run additional diagnostic steps, or test patched configurations if the Whonix maintainers can suggest specific approaches. My goal is not only to resolve my own setup but also to help document this scenario for other users running Whonix alongside Windows 11 with active VBS, which is becoming an increasingly common configuration.

Thank you for any insights or guidance you can offer.

1 Like
Bug report, module tirdad fails to load
2

Does this help…?

1 Like
3

Unfortunately, not yet.

I have never encountered the “green turtle” issue, and I have already gone through the Kicksecure documentation.

I may have overlooked something, but at this point I have no idea what the cause could be.

Does anyone have any suggestions?

1 Like
4

Black Screen

5

Thank you, Patrick.

I tried your suggestions, but unfortunately without success. For comparison, I also tested the latest Kicksecure, and I ran into the same results there as well.

In the end, I downgraded VirtualBox from version 7.2.10 to VirtualBox 6.1.50 r161033 (Qt 5.6.2).

To my surprise, both Whonix-Gateway and Whonix-Workstation are now booting on VirtualBox 6.1.50. On both systems, I completed the “Persistent Mode | SYSMAINT Session” for maintenance tasks. I also successfully completed “Check for Updates”, “Install Updates”, and “Set System Keymap” on both machines.

At this point, I can boot both VMs, and when I run the IP check in Tor Browser, I get the green message: “Congratulations. This browser is configured to use Tor.” Tor Browser is running fast and pages are rendered quickly.

However, during the boot process I see the following message:

[FAILED] Failed to start systemd-modules-load.service - Load Kernel Modules

In the GUI, a pop-up appears saying:

updatecheck
updatecheck: Software updates check failure
'leaprun system-ready-check' failed.
Debugging information: systemreadycheckoutput: 'degraded'
Please run systemcheck.

systemcheck then reports:

text

UNIT LOAD ACTIVE SUB DESCRIPTION
* systemd-modules-load.service loaded failed failed Load Kernel Modules

It also shows the following warning:

WARNING: tirdad - TCP ISN CPU Information Leak Protection:
Reason: kernel module 'tirdad' is NOT loaded.

Is my following assumption correct?

tirdad appears to be a hardening component that is not strictly required for normal operation. If so, can I still use Whonix safely in this state?

6

hey i have the same exact issue. VMs are booting to black screen. after multiple attempts it shows the [FAILED] Failed to start systemd-modules-load.service - Load Kernel Modules error. the VMs are starting up but system check gives multiple errors. very frustrating cause it seems to me the issues came out of nowhere

7

Are you sure? “Native Execution Mode” (as described by your post above) is the “green turtle” issue. The wiki does state…

If the VirtualBox green turtle indicator is not shown, and you’re still experiencing issues, then it’s a different issue.

…but it’s possible that this is incorrect and that VirtualBox might try to go through Hyper-V without showing the green turtle icon.

The main way I’ve been able to get Whonix VMs to boot while keeping VBS enabled is to only start one VM at once. If you start only Whonix-Gateway, then wait for it to boot all the way to a desktop, then start Whonix-Workstation, things seem to work well enough in my experience.

You probably have UEFI and Secure Boot enabled within the VM this is occurring on. If so, open the VM settings and disable Secure Boot (or better yet, switch to BIOS firmware). If you have to use UEFI but Secure Boot isn’t enabled, try enabling Secure Boot, then disabling it (just in case VirtualBox is mistakenly enabling it and not showing it for some reason).

EDIT: The module load issue is probably not a problem with Secure Boot at all. See:

2 Likes
8

When looking into the ‚tirdad‘ issue, can you also please check the VirtualBox topic? I followed your advice to only fire-up the Gateway alone and encountered the boot issue.

In my case, as described above, the ‚black-screen‘ boot-problem only occurs with VirtualBox 7.2.10, whereas both Whonix VMs (Gateway + Workstation) boot and run properly on VirtualBox 6.1.50 r161033 (Qt 5.6.2), except for the separate ‚tirdad‘ topic.

9

I’m not sure what more there is to look into. We’ve studied the incompatibility issues with VirtualBox + Linux + Virtualization Based Security, so far the only good workarounds we’ve found after working on it is starting one VM at a time, or disabling VBS. If you can’t disable VBS, and the “start one VM at a time” trick doesn’t work on your system, you’re out of options as far as our research goes. The only things I can think of that you could do at this point are:

  • Try to find a new workaround (you’ve already done some of this by using the arrow keys),
  • File a bug report against VirtualBox, providing lots of info and logs and potentially working with upstream to debug the issue, so that Oracle will fix it,
  • Figure out how to fix it yourself and either submit a patch or use your own custom build of VirtualBox,
  • Switch host operating systems,
  • Give up on WSL2, Windows Sandbox, and Docker Desktop, and disable VBS,
  • Use Whonix on a second computer that might have better luck with Windows + VirtualBox compatibility or that uses a different host OS, or
  • Try using a different hypervisor like VMware, Hyper-V, QEMU-for-Windows, etc. (but note that all of these are unsupported by us and will likely require substantial work to use).

If all of those options fail or are unsuitable, you probably won’t be able to use Whonix (or Debian in VirtualBox, which exhibited the same behavior in our testing). This issue is unspecific to Whonix.

1 Like
10

Thank you for the support and the time you have put into investigating this issue.

As I understand it, VBS is part of Windows’ security architecture, and disabling it may also reduce the protection provided by related security features such as virtualization-based isolation and, depending on the system configuration, Credential Guard or similar components.

From my perspective, that creates a difficult trade-off, because it would seem somewhat contrary to the general security goals of Whonix to reduce the security of the host system in order to run a security-focused guest environment. I also would prefer not to give up WSL2, Windows Sandbox, or Docker Desktop, since the resulting limitations would be too significant for my use case. Microsoft also documents that third-party virtualization apps can conflict with Hyper-V and related features.

For those reasons, I do not want to disable VBS on this machine.

On the other side: Whonix does start for me on VirtualBox 6.1.50 r161033, but no longer on VirtualBox 7.2.10. VirtualBox 6.1.50 was released as a maintenance release, and 7.2.10 is the newer release I am currently having trouble with.

I can also confirm that Debian 13.5 (“Trixie”), fails to boot with the same issue on my system, just like Whonix. That gives me some hope that this may eventually be improved on the Oracle VirtualBox side rather than being a Whonix-specific problem.

For now, I am hoping for improvements in VirtualBox itself, and in parallel I will continue experimenting with possible workarounds, such as the arrow-key workaround and similar approaches.

1 Like
11

I think 6.1.50 is pretty vulnerable. Did you try VirtualBox 7.2.8? That version worked for me. VirtualBox 7.2.10 gives my host BSOD when I start a VM.

Linux as host with Whonix on QEMU KVM is better choice

2 Likes
12

:grinning_face: :grinning_face: :grinning_face: :grinning_face: :grinning_face: :grinning_face: :grinning_face: :grinning_face: :grinning_face:

Thank you very much — I only got around to testing your suggestion of using VirtualBox 7.2.8 on Windows 11 today, but it appears to be working.

Many, many thanks; it works for Whonix Gateway, Whonix Workstation, and Kicksecure LXQt on Windows.

:waving_hand: :waving_hand: :waving_hand: :waving_hand: :waving_hand: :waving_hand: :waving_hand: :waving_hand: :waving_hand:

1 Like