Windows 11 ARM64 install hangs at "starting BootXXXX" on UTM 5.0.5 (M4 Max) — reproducible across GPU/storage/accel/TPM permutations

[zignd]

Environment

• UTM: 5.0.5 (Beta), installed via brew install --cask utm@beta
• macOS: 26.6.2 (Build 25G83)
• Hardware: Apple M4 Max (MacBook Pro)
• VM: QEMU, aarch64, virt machine (QEMU 10.0 ARM Virtual Machine, alias virt-10.0), gic-version=3
• Guest: Windows 11 ARM64, installer only (never reaches guest tools install)
• Windows ISO: 26100.4349.250607-1500.ge_release_svc_refresh_CLIENTCONSUMER_RET_A64FRE_en-us.iso — build 26100.4349, Consumer/Retail, ARM64 (A64FRE), en-us. Obtained via CrystalFetch (UUPdump-based), verified structurally valid (hdiutil imageinfo recognizes ISO9660/UDF hybrid; efi/boot/bootaa64.efi is a valid signed PE32+ (EFI application) Aarch64, for MS Windows, 2,647,480 bytes).

Issue

A fresh Windows 11 ARM64 VM created for testing the new DirectX/Neptune graphics support hangs indefinitely during boot, every time, regardless of VM configuration. The firmware (EDK2) successfully finds and loads the boot entry, then freezes solid the instant it tries to execute it. CPU usage stays pegged at ~270-290% (multi-core) indefinitely with zero further guest activity — confirmed via debug log that the guest produces no further SPICE/display output at all after the freeze (over 100+ seconds of complete silence in one test, 4+ minutes in another, until force-killed).

Steps to reproduce

1. Create a QEMU aarch64 VM: 8192 MB RAM, 6 cores, Hypervisor (HVF) enabled, UEFI boot enabled, TPM 2.0 device enabled (required for Windows 11 setup).
2. Attach the Windows 11 ARM64 ISO above as a boot drive.
3. Attach a blank system disk.
4. Start the VM and let it boot from the ISO.

Expected result

Firmware boot manager loads and executes the Windows Boot Manager (bootaa64.efi), proceeding to the Windows Setup screen.

Actual result

Boot manager log shows (verbatim, host console):

BdsDxe: loading Boot0001 "UEFI QEMU QEMU USB HARDDRIVE 1-0000:00:03.0-4.1" from PciRoot(0x0)/Pci(0x3,0x0)/USB(0x7,0x0)/USB(0x0,0x0)
BdsDxe: starting Boot0001 "UEFI QEMU QEMU USB HARDDRIVE 1-0000:00:03.0-4.1" from PciRoot(0x0)/Pci(0x3,0x0)/USB(0x7,0x0)/USB(0x0,0x0)

...and then the VM freezes on the TianoCore splash screen indefinitely (left running over 11 minutes on the first occurrence). This reproduces identically regardless of which boot-media interface is used (see isolation testing below) — the boot log text simply changes to match whichever boot option is attempted (e.g. Boot0003 "UEFI Misc Device 2" for a VirtIO-attached drive), but the hang always occurs immediately after the "starting BootXXXX" line, before any subsequent firmware or bootloader output appears.

Isolation testing performed

I methodically varied every VM-configuration axis I could think of; all combinations produce the identical hang at the same point ("starting BootXXXX", zero output after):

Variable	Values tested	Result
Display device	virtio-gpu-gl-pci (Neptune: venus=true,neptune=true) vs. plain virtio-gpu-pci (gl=off)	Hangs identically either way — rules out Neptune/GPU backend
Boot media interface	usb-storage (media=cdrom), virtio-scsi (scsi-cd), fixed non-removable virtio-blk-pci (ISO copied in as a plain disk image)	Hangs identically on all three (SCSI/VirtIO variants fail to even reach the same visible frame as long, appearing to freeze faster, but debug-log analysis confirms genuine silence, not progress)
CPU acceleration	-accel hvf (hardware) vs. -accel tcg (pure software emulation)	Hangs identically — rules out HVF/Hypervisor.framework specifically
TPM / Secure Boot	TPMDevice=true (uses edk2-aarch64-secure-code.fd) vs. TPMDevice=false (uses non-secure firmware)	Hangs identically — rules out Secure Boot / EFI-vars initialization

QEMU command line for the last (fixed VirtIO) test, for reference:

qemu-system-aarch64 -L .../Library/Caches/qemu -S -spice unix=on,...,gl=off ... -device virtio-gpu-pci ... -cpu host -smp cpus=6,sockets=1,cores=6,threads=1 -machine virt,gic-version=3 -accel hvf -drive if=pflash,format=raw,unit=0,file.filename=.../edk2-aarch64-secure-code.fd,file.locking=off,readonly=on -drive if=pflash,unit=1,file.filename=.../efi_vars.fd -m 8192 ... -device nvme,drive=drive834BDA47-...,bootindex=0 -drive if=none,media=disk,id=drive834BDA47-...,file.filename=.../834BDA47-....qcow2 -device virtio-blk-pci,drive=driveEE1E4F44-...,bootindex=1 -drive if=none,media=disk,id=driveEE1E4F44-...,file.filename=.../26100.4349.250607-1500.ge_release_svc_refresh_CLIENTCONSUMER_RET_A64FRE_en-us.iso ... -device tpm-crb-device,tpmdev=tpm0

Additional notes

• The main branch HEAD is identical to the v5.0.5 tag (b6f7475), so this is not something already fixed post-release.
• I did not find an existing issue matching this exact symptom (searched for boot hangs, BdsDxe, HVF freezes, M4-specific reports — found Apple M4: Missing CPU features in guest VM on MacOS host #6944 and macOS 9.2.1 installer hangs installing on M4Max MacBook Pro running Sequoia 15.2 #6936 which mention M4/M4 Max-specific behavior, but neither matches this symptom directly).
• Given the consistent freeze point across every backend permutation, I suspect this may be specific to either (a) this exact Windows 11 ARM64 build/bootloader on this UTM/QEMU version, or (b) something host-specific to Apple M4 Max under this beta's HVF/TCG paths — happy to help test further if there's a specific hypothesis you'd like checked (e.g., a different Windows build, a different QEMU virt machine version override, etc.).

[osy]

Please include both the VM config.plist and the debug.log as per the new issue template instructions

[notRemyM]

This is an actual problem, but this ISO is really old and ARM64 Windows changes a lot.

I have fresh 25H2 and 26H1 media, both work fine on 5.0.5

[liaaa444m]

I have the exact same issue right now whenever I try to setup a fresh machine with the newest media obtained from CrystalFetch on an M5 Air running Golden Gate