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.