[Bug] Windows 11 25H2 host: ~114-second VM stall under NEM/WHPX; not observed with native VT-x

[dafata39-rgb]

Version

7.2.16

Host OS Type

Windows

Host OS name + version

Windows 11 Pro 25H2, Build 26200.9168

Host Architecture

x86

Guest OS Type

Windows

Guest Architecture

x86

Guest OS name + version

Windows 10 22H2, Build 19045.6466

Component

VMM

What happened?

VirtualBox 7.2.16 on a Windows 11 25H2 host experienced a severe VM execution stall while using the Windows Hypervisor Platform/NEM execution path.

The affected Windows 10 guest became unresponsive for approximately 114 seconds. The VirtualBox log recorded:

TM: Giving up catch-up attempt at a 114 159 629 993 ns lag
VMMDev: vmmDevHeartbeatFlatlinedTimer: Guest seems to be unresponsive.
Last heartbeat received 114 seconds ago

At the time, VirtualBox could not access Intel VT-x directly because the Windows hypervisor/VBS stack was active, so the VM was running through NEM/WHPX.

After troubleshooting the Windows host, VBS, Secure Kernel and KeyGuard were no longer running after reboot. Without changing the VirtualBox version, VirtualBox 7.2.16 then obtained native VT-x directly:

HM: HMR3Init: VT-x w/ nested paging and unrestricted guest execution hw support

Two extended validation runs were then completed using native VT-x:

• VM_A: approximately 1 hour 39 minutes, with zero "Guest seems to be unresponsive" events and zero "Giving up catch-up attempt" events.
• VM_B: approximately 1 hour 14 minutes, also with zero equivalent events.

Both sessions ended normally.

Expected behavior:
The VM should remain responsive when VirtualBox operates through NEM/WHPX. A Windows host configuration that requires the WHPX/NEM backend should not result in multi-minute guest execution stalls.

This does not prove that NEM/WHPX alone caused every historical stall. However, it provides a strong A/B comparison using the same VirtualBox 7.2.16 build: the severe stall was observed while running through NEM/WHPX, while the same symptom was not observed during subsequent native VT-x validation sessions.

The related Windows-side VBS/Windows Hello/KeyGuard behavior has also been reported to Microsoft:

Microsoft Feedback Hub:
https://aka.ms/AA13bw95

Feedback ID:
80514edc-ae18-4971-8a70-b21657268d76

I would like Oracle/VirtualBox to investigate whether there is a robustness, scheduling, timing, or interoperability issue in the NEM/WHPX execution path that can produce very long guest stalls under Windows 11 25H2.

VM_A_BEFORE_NEM_FAIL_sanitized.log
VM_B_AFTER_VTX_PASS_sanitized.log
VM_A_AFTER_VTX_PASS_sanitized.log

Oracle_VirtualBox_Technical_Report_Windows11_25H2_NEM_WHPX_VTx.pdf

How can we reproduce this?

The issue was intermittent rather than deterministically reproducible on demand.

Environment in which the severe stall was observed:

1. Host: Windows 11 25H2, build 26200.9168, Intel x86-64 system.
2. VirtualBox: 7.2.16 r174877.
3. Guest: Windows 10 22H2, build 19045.6466.
4. VM configuration: 4 vCPUs, 6 GB RAM, SATA/AHCI VDI, NAT networking, 3D acceleration disabled.
5. Windows VBS, Secure Kernel and KeyGuard were active on the host.
6. The Windows hypervisor prevented VirtualBox from obtaining VT-x directly.
7. VirtualBox therefore executed the VM through NEM/WHPX.
8. Use the Windows guest normally for an extended period.

During one extended session the VM stalled for approximately 114 seconds, which was recorded directly in VBox.log.

A/B validation:

After VBS, Secure Kernel and KeyGuard were no longer running, rebooting the same host allowed the same VirtualBox 7.2.16 build to use native VT-x.

No equivalent stalls were recorded during subsequent native VT-x validation runs of approximately 99 minutes (VM_A) and 74 minutes (VM_B).

I have not deliberately re-enabled the problematic Windows security/hypervisor state because doing so affects Windows Hello sign-in and would return the workstation to the previously problematic configuration.

If Oracle needs a specific diagnostic trace or controlled reproduction under NEM/WHPX, I can perform one following developer instructions.

Did you upload all of your necessary log files, screenshots, etc.?

• Yes, I've uploaded all pertinent files to this issue.

[dafata39-rgb]

Additional validation update (native VT-x)

I completed a substantially longer follow-up validation run on the same Windows 11 Pro 25H2 host and VirtualBox 7.2.16 r174877.

Results:

• Execution backend: native Intel VT-x
• VirtualBox log: HM: HMR3Init: VT-x w/ nested paging and unrestricted guest execution hw support
• Session duration: approximately 9 hours 43 minutes
• Guest seems to be unresponsive: 0 occurrences
• Giving up catch-up attempt: 0 occurrences
• NEMR3Init: 0 occurrences
• WHvCapabilityCodeHypervisorPresent: 0 occurrences
• No equivalent long guest stall was observed
• The guest requested a normal shutdown and the VM reached PoweredOff

One runtime AHCI#0: Port 0 reset occurred at approximately 00:11:31, but there was no heartbeat loss or catch-up event around it, and the VM continued running normally for more than 9 additional hours.

The host had only about 4.6 GB of 23.7 GB RAM available when the VM started, so this clean run also occurred under noticeably higher host memory pressure than some of the earlier validation runs.

This does not establish that NEM/WHPX alone caused the original stalls, but it strengthens the A/B observation: the severe ~114-second stall was captured while VirtualBox was using NEM/WHPX, while multiple later runs using native VT-x — now including a ~9h43m session — did not reproduce it.

Sanitized full log attached: VM_B_9h43m_VTX_PASS_sanitized.log.

VM_B_9h43m_VTX_PASS_sanitized.log