Forum Discussion
Update 26220.8491: Win11 Update Freezes at 38% - Hypervisor Launch Failed (No VMX)
Title: Win11 Update Freezes at 38% - Hypervisor Launch Failed (No VMX)
Issue Description:
During the offline installation phase of the latest update, the process completely freezes at exactly 38 percent, requiring a hard reset to roll back. The system processor does not support hardware virtualization (no VMX support).
Diagnostic Signatures:
After the rollback completes, the System Event Log consistently shows Event ID 41 and 1001 from the hypervisor source, stating that the launch failed because virtualization features are not present or enabled in the system setup.
The Problem:
The offline installation engine seems to ignore host operating system configurations when it stages the update environment. Attempts to turn off the hypervisor launch type globally, disable virtualization security components, or change the driver startup parameters have no effect because the temporary update environment regenerates its own settings and tries to validate the hypervisor stack anyway. When it hits the missing hardware capability, it locks up.
Is there an official command-line deployment switch or an undocumented parameter for the update engine that forces it to completely skip the installation and migration of virtualization-dependent packages?
2 Replies
Use CPU-Z or Speccy to check if virtualization features (Intel VT-x or AMD-V) are supported. If the processor lacks support, the hypervisor-related errors are expected, and the update might not complete or function properly.
Hi sbrown51265, this is a sophisticated failure—you've correctly identified that the update engine is 'stubbornly' trying to initialize the hypervisor stack even when the host hardware doesn't support it (lack of VMX).
Since there is no 'official' documented switch to skip virtualization-dependent packages during the offline migration phase, here is how you can try to force the update through:
Option 1: The 'Bypass' Registry Method: Before launching the installer/update, use the Registry Editor to set HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity to Enabled=0. Sometimes this prevents the update engine from asserting the VBS requirement during the staging phase.
Option 2: The 'DISM' approach: Instead of using the Windows Update GUI, try downloading the .msu or .cab file for the update and deploying it via DISM from an elevated command prompt (dism /online /add-package /packagepath:C:\path\to\update.cab). DISM often handles the 'offline' migration logic more gracefully than the standard Update Orchestrator.
Option 3: The 'Virtualization' override: If you have access to the BIOS, even if your CPU lacks VMX, check if there is a 'Virtualization Technology' toggle. Sometimes flipping it to 'Enabled' (even if the CPU is incompatible) satisfies the installer's 'check'—it will crash later, but it might get you past the 38% update hurdle.
Given your diagnostic logs, I would focus on the DISM deployment method—it is the most likely way to bypass the 'pre-flight' checks that are locking you up.
