Booting into EFI Shell instead of Windows 11 ARM64 Installer on UTM (Mac M3)

[huddmax]

Hi, I’m trying to set up a virtual machine in UTM to install Windows 11 ARM64 on my Mac M3. However, I’m facing an issue where the VM always boots into the EFI Shell instead of the Windows installer. I’ve followed several troubleshooting steps but haven’t been able to resolve the issue.

Context

•	Host Operating System: macOS (MacBook M3)
•	UTM Version: [Insert version, e.g., 4.x.x]
•	Windows Version: Windows 11 ARM64
•	ISO Source: Downloaded via CrystalFetch
•	ISO Architecture: ARM64

VM Configuration

•	RAM: 8 GB
•	CPU: 2 cores (I’ve also tested with 4 cores)
•	Virtual Disk: 64 GB (NVMe Drive)
•	ISO: Configured as CD/DVD (ISO) with USB interface
•	Additional Settings:
•	UEFI Boot: Enabled
•	Secure Boot: Enabled
•	TPM 2.0: Enabled

Steps Taken

1.	Downloaded the ARM64 ISO using CrystalFetch.
2.	Created the VM in UTM with the above configuration.
3.	Set the ISO as the primary bootable drive.
4.	Configured a 64 GB NVMe virtual drive.
5.	Enabled Reset UEFI Variables, but the issue persists.

Issue

When booting the VM, it always opens the EFI Shell, and I cannot access the Windows installer. Running map -r in the EFI Shell maps the drives, but I can’t find any drive containing bootx64.efi.

What I’ve tried:
• Listing all drives (FS0:, FS1:, etc.).
• Manually attempting to boot using bootx64.efi, but the correct drive isn’t found.
• Recreating the VM and ensuring the ISO is set as bootable.

Questions

1.	Is there something I might be misconfiguring in UTM?
2.	Could the ISO format or configuration be an issue, even though it was downloaded via CrystalFetch?
3.	Is there an additional step I need to take in the EFI Shell to force the boot?

Thank You

Thank you in advance for your help! Let me know if you need more information or specific adjustments to the configurations.

[huddmax]

Here’s the solution I used to resolve the boot issue in the EFI Shell and successfully install Windows 11 ARM64 on UTM (Mac M3):
1. Set ISO as Bootable Drive:
• I ensured the ISO was configured as a CD/DVD (ISO) in UTM with the interface set to USB.
• The ISO was ARM64-compatible (downloaded via CrystalFetch).
2. Manual Boot in EFI Shell:
• When the EFI Shell opened, I used the following commands to find and start the installer manually:

map -r
FS0:
dir
cd EFI
cd BOOT
BOOTAA64.EFI

3.	“Press Any Key” Prompt:
•	After loading the installer manually, I clicked inside the VM window to capture the keyboard and pressed a key to continue when the “Press any key to boot from CD or DVD” message appeared.
4.	Installation Process:
•	I selected the virtual NVMe drive (64 GB) as the installation location and followed the standard Windows setup process.

Everything worked fine after these steps, and Windows 11 ARM64 is now running smoothly. Thanks for the support, and I hope this helps others facing the same issue!

[mattjoy1234567890]

hello

[timi2506]

hello

Hi

[gavinnf]

What about running Windows in virualbox in MacBook Pro M4 max laptop ?

[taka-shirasu]

Having the Same Issue on Mac M4

I’m currently facing the same EFI Shell boot issue when trying to install Windows 11 ARM64 on UTM (MacBook Pro M4).

Here’s what I’ve encountered so far:

• Host: macOS (M4 MacBook Pro)

• UTM Version: latest (as of October 2025)

• Windows ISO: Win11_25H2_English_ARM64.iso (downloaded via CrystalFetch)

• Drives:

  • ISO: CD/DVD (USB interface)
  • Guest tools: CD/DVD (USB interface)
  • NVMe: 64GB virtual disk created with qemu-img create -f qcow2 ~/Documents/UTM/Windows11.qcow2 64G

Problem

Every time I boot, UTM goes straight into the EFI Interactive Shell instead of the Windows installer.
I’ve tried:

• Running map -r and manually locating the ISO (no BOOTAA64.EFI found)
• Recreating the VM multiple times
• Switching the disk interface between NVMe, USB, and SATA
• Using both CrystalFetch ISO and Microsoft’s direct ARM64 ISO

Strange Behavior

When I add the NVMe drive, UTM automatically resets its size to 196 KB after saving — even though it was created as a 64GB image via command line.
If I try using the .qcow2 file manually, I get this error:

“could not get blockdev size: Operation not supported by device”

Question

Is this a known issue on Apple Silicon M4 Macs with the latest UTM build?
It seems like the disk configuration is being overridden or corrupted after saving the VM.
Would appreciate any confirmation or workaround!

[KKatariah]

The file won't necessarily be called BOOTAA64.EFI. You need to check what the file is actually called in your instance.

You can do this by running ls and finding the file called something like BOOTXX64.EFI.