You created a virtual machine in Hyper-V on your Snapdragon laptop and it refuses to start — or it starts but runs so slowly it is unusable, or the Hyper-V Manager itself throws errors about the virtualization service. On Intel this was routine; on ARM the same clicks produce different failures.
Hyper-V on ARM64 is real Hyper-V, but the guest world is smaller: every VM must run an ARM64 operating system — Windows 11 ARM64, Ubuntu ARM64, Debian ARM64. There is no x64 guest support, no nesting an x64 world inside. Most failures come from that architecture mismatch, from firmware virtualization being off, or from the Hyper-V platform being incompletely enabled. Teams-heavy users sometimes notice virtualization-adjacent AI features misbehaving too — see Copilot Teams meeting recap not working and Paint Cocreator not working for the same “check the platform first” pattern applied to AI features.
This guide gives you six fixes in order: enable firmware virtualization and the Hyper-V platform, use ARM64 guest media, fix VM start failures, tune VM performance, repair the Hyper-V service, and resolve conflicts with other hypervisors. All commands run elevated.
Why this happens
- Virtualization disabled in firmware: The Hyper-V hypervisor cannot load without it. VMs fail to start with virtualization errors, and the Hyper-V Manager may report the service as unavailable.
- x64 guest OS on an ARM host: Hyper-V on ARM cannot emulate x64. An x64 ISO will fail to boot or install — this is the single most common “VM won’t start” cause on Snapdragon laptops.
- Hyper-V platform incompletely enabled: The Hyper-V Manager console can be installed without the underlying hypervisor platform, producing a manager that opens but cannot run anything.
- Hypervisor launch type disabled: Tweaking tools and some games set
hypervisorlaunchtypeto Off for marginal performance, silently breaking all Hyper-V functionality until reverted. - Under-provisioned VM resources: Default VM settings (2 GB RAM, 2 vCPUs) starve modern ARM64 guests, especially Windows 11 ARM64 — the VM boots but crawls.
- Conflicting third-party hypervisor: VirtualBox, VMware Workstation, and some security products install drivers that conflict with Hyper-V’s hypervisor on ARM.
- Corrupted Hyper-V configuration: Failed updates or interrupted VM operations can corrupt the Hyper-V service configuration, producing start failures with no clear error.
How to fix it
Work through these in order — diagnose first, then act.
Fix 1: Enable firmware virtualization and the Hyper-V platform
Nothing works without the hypervisor. Verify the firmware switch and the Windows features together.
- Open Task Manager (Ctrl + Shift + Esc), go to Performance > CPU, and confirm Virtualization reads Enabled.
- If Disabled, reboot into BIOS/UEFI and enable virtualization, then save and exit.
- Press Windows key + R, type
optionalfeatures, press Enter, and check Hyper-V (both Management Tools and Platform), Virtual Machine Platform, and Windows Hypervisor Platform. - Click OK and restart — the hypervisor activates at boot.
- After reboot, open an elevated PowerShell and run
Get-Service vmms— the Hyper-V Virtual Machine Management service should show Running.
Fix 2: Use ARM64 guest operating systems only
If your VM was built from an x64 ISO, no platform fix will save it. Rebuild with ARM64 media.
- Delete or discard the non-booting VM — an x64 guest on ARM Hyper-V will never work, regardless of settings.
- Download a Windows 11 ARM64 ISO (from Microsoft’s download page via a registered device) or an Ubuntu/Debian ARM64 ISO for Linux guests.
- In Hyper-V Manager, create a Generation 2 VM and attach the ARM64 ISO.
- During guest setup, confirm the installer boots — an ARM64 ISO on ARM Hyper-V boots normally; an x64 ISO fails immediately at boot.
- After installation, install the guest integration services (automatic for Windows ARM64 guests) to enable proper mouse, display, and networking.
Fix 3: Fix VM start failures and hypervisor launch type
The platform is enabled and the guest is ARM64, but the VM still will not start — check the hypervisor launch configuration.
- In an elevated PowerShell, run
bcdeditand findhypervisorlaunchtype— it must read Auto. - If it reads Off, run
bcdedit /set hypervisorlaunchtype autoand reboot. - Check Event Viewer > Applications and Services Logs > Microsoft > Windows > Hyper-V-VMMS for the specific start failure and its error code.
- If the error mentions saved state corruption, right-click the VM in Hyper-V Manager and choose Delete Saved State, then start fresh.
- For error 0x80070057 or similar, re-run
DISM /Online /Enable-Feature /All /FeatureName:Microsoft-Hyper-V-Allfrom an elevated prompt and reboot.
Fix 4: Tune the VM for usable performance
An ARM64 VM that boots but crawls is almost always under-provisioned. Give it real resources.
- Shut down the VM, right-click it in Hyper-V Manager, and open Settings.
- Under Memory, assign at least 4096 MB (8192 MB for a Windows 11 ARM64 guest used as a daily driver).
- Under Processor, assign at least 4 virtual processors — 2 vCPUs starves modern guests.
- Under Hard Drive, confirm the VHDX lives on the internal SSD, not a slow external drive or SD card.
- Start the VM and check Task Manager inside the guest — CPU should idle low; sustained 100% at idle means the guest OS is wrong-architecture or its drivers failed.
Fix 5: Repair the Hyper-V service and configuration
When the Hyper-V Manager itself errors or the vmms service will not stay running, the service configuration needs repair.
- In an elevated PowerShell, run
DISM /Online /Cleanup-Image /RestoreHealth, thensfc /scannow. - Restart the Hyper-V services:
Restart-Service vmms,Restart-Service vmcompute— both should return to Running without errors. - If vmms fails to start, check that no third-party antivirus is blocking hypervisor drivers, and temporarily disable its virtualization features to test.
- Re-register the Hyper-V platform: uncheck Hyper-V in
optionalfeatures, reboot, re-check it, reboot again. - After the re-enable cycle, recreate a small test VM with an ARM64 ISO to confirm the platform is healthy before rebuilding production VMs.
Fix 6: Resolve conflicts with other virtualization software
Two hypervisors cannot own the CPU. If another product is installed, it may be blocking Hyper-V.
- Uninstall VirtualBox, VMware Workstation, or any other desktop hypervisor you do not actively need — their kernel drivers can conflict on ARM.
- Check security software for hardware-assisted virtualization or hypervisor-protected features and disable them temporarily to test.
- Some Android emulators install their own hypervisor drivers — update them to versions that cooperate with Hyper-V, or uninstall them.
- After removing the conflicting product, reboot and verify
hypervisorlaunchtypeis still Auto, then retest your Hyper-V VM. - If you must keep the other product, check its documentation for a Hyper-V compatibility mode — many now run on top of the Windows hypervisor instead of fighting it.
Closing
Hyper-V on ARM laptops is production-capable with one non-negotiable rule: ARM64 guests only. Get firmware virtualization on, the platform fully enabled, and the guest architecture right, and the rest is standard VM administration — memory, vCPUs, fast storage. The honest limit is the guest ecosystem: if the OS or appliance you need exists only for x64, no Hyper-V setting on a Snapdragon laptop will run it. For platform-level questions, Microsoft’s Windows support hub documents the ARM64 Hyper-V requirements as they evolve.
