Windows Installer triggers QEMU USB reset, aborting installation

[jensdepuydt]

When trying to install Windows 11 ARM version, during the second step of the installation (Getting files ready for installation), this randomly ends with error 0x800701B1 (Windows cannot install required files. Make sure all files required for installation are available.)

This seems to happen at random moments during this phase, somewhere between 0 and 100%. A single time, without any specific modifications to the settings, I managed to get things going to 100%. After that, the rest of the install worked as expected and so did the installed Windows version.

When trying to restart setup, without a VM restart, I noticed that the CD/DVD-drive is no longer readable. Changing the ISO does not seem to help.

Configuration

• UTM Version: 2.2.4 (36)
• OS Version: 11.6
• Intel or Apple Silicon? M1 Silicon (Macbook Air 2020)

Debug log
debug.log

[jensdepuydt]

Found out, after playing around a bit more that this also happens from the command prompt (from the installer).
I tried to copy all files to a separate partition, from the DVD drive and the issue occured.

As you can see in the output of wmic, the D: drive, which has the ISO drive, suddenly is gone:

Before copy:

After copy failed:

Another thing I noticed: When I link two virtual CD/DVD drives to the VM. Once this happens, both of them get disconnected.

[conath]

From the debug log these two lines stand out:

non queue head request in async schedule
processing error - resetting ehci HC

I don't know what causes this, but searching online reveals these are QEMU messages related to USB2 emulation. First line; second line

Could you try a different interface for the installer ISO? (not sure if this is possible with ARM system & the W11 installer)

From the log I can see UTM generates three different USB controllers. ICH9 UHCI and ICH9 EHCI are for USB redirect without USB3 checked; and QEMU XHCI is default for ARM system. To see if the EHCI reset from the error is related to the USB2 controller generated, you can try this:

You could set the installer ISO interface to none and add this line to the QEMU tab (scroll down where it says New...):

-device usb-storage,drive=drive1,removable=true,bootindex=1,bus=usb-bus.1

This connects the CD drive to the USB XHCI bus. Please test it and let us know if the problem persists, and whether the reset message is still in the log.

If the problem persists, I would suggest you set the USB sharing number in the Sharing tab to 0 and try again.

[jensdepuydt]

@conath thanks a lot for looking into this.
Just tested your suggestion but had to use the following:
-device usb-storage,drive=drive1,removable=true,bootindex=1,bus=usb-bus.0
Looks like there bus=usb-bus and bus=usb-bus.0, usb-bus.1 did not exist.

Just tried this once so far and immediately managed to get to the next phase of the install.
I also had the impression that performance (for that copy phase) was a lot better in comparison with the defaults.

Will try this a few more times to be sure it's not just a coincidence and will update here.

[conath]

Thank you for testing! It would seem we've discovered a QEMU bug.

However as you noted there is a speed benefit when we assign the USB controller manually. So I would suggest that the way the Drives configuration is interpreted needs to be changed. Any USB drives should be assigned to the XHCI bus, if available. @osy

This will have the side effect that it works around the bug.

[jensdepuydt]

Just gave this another try to be sure and this time, the install failed in the same way, using
usb-storage,drive=drive1,removable=true,bootindex=1,bus=usb-bus.0

I'm trying now with
usb-storage,drive=drive1,removable=true,bootindex=1,bus=usb-controller-0.0

edit:
first attempt was a success (but so was usb-bus.0 the first time).
speed was clearly slower in comparison with usb-bus.0

edit2:
second attempt with usb-controller-0.0 failed as well.
This is really strange as it clearly has a higher success-rate in comparison without specifying a bus, but still fails from time to time.

Need some more time to play around with this, will try to find some time tomorrow.

[conath]

Thanks again for testing and please export the logs after each test. Will need the debug log for failed attempts to tell if it's hitting the same issue or not.

[AwlsomeAlex]

@conath Here's what I captured: macOS 12.0.1, UTM 2.3.1, Windows 11 ISO (.1 build from UUP Dump on macOS)
usb-controller.log
usb-bus.log

ISO is fine, used it with success in Parallels.

[conath]

I can see the reset error occurs when using the usb-controller (USB2), but not when using usb-bus (USB3). I will make a PR that sets the cd drives to use USB3 for ARM VMs.

[conath]

Just tested this myself and I can reproduce the "Windows install aborted" issue still, just like @AwlsomeAlex. I have the identical debug log like this as well (by which I mean no USB reset error is logged - because I'm using the USB3 controller).

After trying a second time after closing and re-opening the VM window, it worked. 🤪

In conclusion, the Windows 11 install is flaky and the PR #3216 increases the speed greatly, so it's still relevant.

[AwlsomeAlex]

Still hitting this occasionally @osy (will try to grab a QEMU log if it happens)

[jwhitehead74]

I'm encountering this issue on 2.4.1. Not seeing any error in the debug log but attached if you want to review..

Windows 11 22499.1000 / UTM 2.4.1 / MacOS 12.0.1 / M1 Pro 10-core MBP

debug3.log

[conath]

I have also been able to reproduce this today using UTM 2.4.1 and Windows 11 ARM Insider Preview 22509.1011 ISO. I tried installing normally twice (with the GUI) and once using dism. Gui gets stuck at "Getting Files ready for installation" and dism stops working at 69% (not nice) and in both cases the USB bus is gone after the error until the VM is powered off and back on again.

Edit: same error as in the original issue at the top of the page.

[kad-kroont]

Having this issue too. Wondering what QEMU parameters I could add to make it work?

UTM 2.4.1 (40)

22523.1000_arm64_en-us_multi_522e8c27_convert_virtual

[conath]

@kad-kroont Here is an idea I have not tested: you could convert the installer ISO to QCOW2 and import into UTM as a disk drive. Set disk interface to NVMe and install from that.

[jwhitehead74]

@conath if you can provide steps/detail, I'll give it a try.

[spikespaz]

I have tried the suggestion of converting the ISO to a QCOW2. This doesn't work, I think because the ISO is multiple partitions, one is EFI, and the other contains install data. Not sure, just a guess. I don't think it maps to a normal NVMe drive with GPT partitions. The Windows installer tells me that files are missing, and asks me to browse to the location of the necessary drivers. This isn't the exact error message but it's something along those lines. I wonder, if there is a way to put the ISO inside of a QCOW2, convert the ISO to QCOW2, mount both of them to the VM, and read the install data from the ISO inside of the QCOW2 after booting the converted ISO. I'm gonna try that tomorrow.

[jesshub]

I had to use
-device
usb-storage,drive=drive0,removable=true,bootindex=1,bus=usb-bus.1
And it took me 8 attempts lol, just have to keep trying until it gets past 100% copying the files.

[brandonros]

I downloaded 22000.1_arm64_en-us_multi_a1b78728_convert from https://uupdump.net/

then I had to do the regedit.exe workaround to be able to get past "This PC can't run Windows 11" secure boot check.

then I get this error after attaching the CD/DVD (ISO) Image the default "Import drive" way. It says interface is "USB"

qemu-system-aarch64
 -L /Applications/UTM.app/Contents/Resources/qemu
 -S
 -qmp tcp:127.0.0.1:4444,server,nowait
 -nodefaults
 -vga none
 -spice "unix=on,addr=/Users/brandonros/Library/Group Containers/WDNLXAD4W8.com.utmapp.UTM/EB1C7DE1-027D-4A35-A1F6-AD4B41536A01.spice,disable-ticketing=on,image-compression=off,playback-compression=off,streaming-video=off,gl=on"
 -device virtio-ramfb-gl
 -cpu cortex-a72
 -smp cpus=4,sockets=1,cores=4,threads=1
 -machine virt,highmem=off
 -accel hvf
 -accel tcg,tb-size=1024
 -drive if=pflash,format=raw,unit=0,file=/Applications/UTM.app/Contents/Resources/qemu/edk2-aarch64-code.fd,readonly=on
 -drive "if=pflash,format=raw,unit=1,file=/Users/brandonros/Library/Containers/com.utmapp.UTM/Data/Documents/Windows 11.utm/Images/efi_vars.fd"
 -boot menu=on
 -m 4096
 -device intel-hda
 -device hda-duplex
 -name "Windows 11"
 -device qemu-xhci,id=usb-bus
 -device usb-tablet,bus=usb-bus.0
 -device usb-mouse,bus=usb-bus.0
 -device usb-kbd,bus=usb-bus.0
 -device ich9-usb-ehci1,id=usb-controller-0
 -device ich9-usb-uhci1,masterbus=usb-controller-0.0,firstport=0,multifunction=on
 -device ich9-usb-uhci2,masterbus=usb-controller-0.0,firstport=2,multifunction=on
 -device ich9-usb-uhci3,masterbus=usb-controller-0.0,firstport=4,multifunction=on
 -chardev spicevmc,name=usbredir,id=usbredirchardev0
 -device usb-redir,chardev=usbredirchardev0,id=usbredirdev0,bus=usb-controller-0.0
 -chardev spicevmc,name=usbredir,id=usbredirchardev1
 -device usb-redir,chardev=usbredirchardev1,id=usbredirdev1,bus=usb-controller-0.0
 -chardev spicevmc,name=usbredir,id=usbredirchardev2
 -device usb-redir,chardev=usbredirchardev2,id=usbredirdev2,bus=usb-controller-0.0
 -device usb-storage,drive=drive0,removable=true,bootindex=0,bus=usb-bus.0
 -drive "if=none,media=cdrom,id=drive0,file=/Users/brandonros/Library/Containers/com.utmapp.UTM/Data/Documents/Windows 11.utm/Images/22000.1_MULTI_ARM64_EN-US.ISO,cache=writethrough"
 -device nvme,drive=drive1,serial=drive1,bootindex=1
 -drive "if=none,media=disk,id=drive1,file=/Users/brandonros/Library/Containers/com.utmapp.UTM/Data/Documents/Windows 11.utm/Images/disk-0.qcow2,cache=writethrough"
 -device virtio-net-pci,mac=5A:DA:4F:C4:DA:1D,netdev=net0
 -netdev vmnet-macos,mode=shared,id=net0
 -device virtio-serial
 -device virtserialport,chardev=vdagent,name=com.redhat.spice.0
 -chardev spicevmc,id=vdagent,debug=0,name=vdagent
 -uuid EB1C7DE1-027D-4A35-A1F6-AD4B41536A01
 -rtc base=localtime

[conath]

@jensdepuydt On your website you include a section about adding the QEMU parameter to bypass this issue. Is this still up to date?

[osy]

I have also been able to reproduce this today using UTM 2.4.1 and Windows 11 ARM Insider Preview 22509.1011 ISO. I tried installing normally twice (with the GUI) and once using dism. Gui gets stuck at "Getting Files ready for installation" and dism stops working at 69% (not nice) and in both cases the USB bus is gone after the error until the VM is powered off and back on again.

Edit: same error as in the original issue at the top of the page.

@conath Do you see the same error message in the debug log after the USB bus argument change?

[conath]

I have also been able to reproduce this today using UTM 2.4.1 and Windows 11 ARM Insider Preview 22509.1011 ISO. I tried installing normally twice (with the GUI) and once using dism. Gui gets stuck at "Getting Files ready for installation" and dism stops working at 69% (not nice) and in both cases the USB bus is gone after the error until the VM is powered off and back on again.
Edit: same error as in the original issue at the top of the page.

@conath Do you see the same error message in the debug log after the USB bus argument change?

@osy No, I saw the same Windows Installer error. The debug log error was not present. Interestingly, in a more recent test I noticed parts of or the entire USB bus seemed to stop working when the install fails this way.

[osy]

I've been able to trigger this but not consistently. If someone can find a way to more consistently trigger it and/or with QEMU unmodified, we can better debug it.

[remixer-dec]

I faced the same issue every time I tried to install something from a USB/CD Drive on a working Windows VM, the drive just becomes unavailable at some point. Tried adding the drive file after boot, ejecting it, changing the file. Same problem every time. Converting to qcow2 and switching USB3 / shared device count has no effect on it. Nothing related to USB in the logs. Setting -device usb-storage,drive=drive1,removable=true,bootindex=1,bus=usb-controller-0.0 in qemu tab worked.
UPD: nvm, i just got lucky, the issue still appears even with that line, but with some luck its avoidable

[osy]

I tested ~20 installs without issue using the latest commit.

[brandonros]

I tested ~20 installs without issue using the latest commit.

@osy thank you so much. Could you cut a binary release please so users do not need to download that commit + build the app?

[osy]

Patience