Windows 11 ARM guest: wired Amazon Luna Controller (1949:041A) hot-attached to a running guest gets no driver (osvc=0000); attached while Windows boots it works #61

What went wrong

A USB-C wired Amazon Luna Controller attached to a Windows 11 ARM64 VM through the menu bar's accessory list ("Use with Windows11 VM") shows up in the guest, but its gamepad interface stays at Device Manager Code 28 (no driver) and XInput reports no controller. The audio and serial interfaces of the same device work.

The same controller answers the Microsoft OS string request (string index 0xEE) correctly when it is read later in the guest. At attach time, Windows decides the device has no Microsoft OS descriptors, stores osvc = 00 00, and therefore never requests the compat ID that would bind the inbox Xbox 360 driver. With that cache value written by hand, everything works. When the same controller is already assigned while Windows boots (cold attach), Windows itself records osvc = 01 90, binds the Xbox 360 driver and everything works without any edit. Only the attach to a running guest fails.

Environment

• VMPal 0.86 (build 86), macOS 27 "Golden Gate" 27.0.1, Mac: Apple M4
• Guest: Windows 11 24H2 ARM64 (build 26100), VMPal Tools 0.56, virtual xHCI (PCI 1B36:000D)
• Device: Amazon Luna Controller, USB full speed, bcdUSB 2.00, wired with USB-C. Chrome on the Mac lists no HID/USB devices, so it is not holding the device.

Steps to reproduce

1. Connect the Luna Controller to the Mac with USB-C.
2. While the guest is running, choose "Use with Windows11 VM" in the menu bar accessory list.
3. In the guest, open Device Manager: the gamepad interface (USB\VID_1949&PID_041A&MI_00) has Code 28. XInputGetState returns "not connected" for all slots.
4. Check HKLM\SYSTEM\CurrentControlSet\Control\usbflags\1949041A0101: osvc = 00 00. Deleting that key and attaching again recreates it with 00 00 (3 fresh enumerations without a cached value, all giving 00 00; re-attaches while the value is cached do not query again and do not count).

Expected

The attach behaves like on a physical PC: Windows reads the OS string (MSFT100, vendor code 0x90), caches osvc = 01 90, requests the extended compat ID, gets USB\MS_COMP_XUSB10, and binds the inbox xusb22.inf.

Evidence (all taken inside the guest)

• Configuration descriptor, 316 bytes, 6 interfaces: interface 0 is vendor class FF/5D/01 (Xbox 360 protocol); interfaces 1-3 are USB audio; 4-5 are CDC ACM. No HID interface.
• A live read of string descriptor 0xEE through the hub IOCTL (IOCTL_USB_GET_DESCRIPTOR_FROM_NODE_CONNECTION) returns 12 03 4d 00 53 00 46 00 54 00 31 00 30 00 30 00 90 00 ("MSFT100", vendor code 0x90). 100 of 100 reads succeeded, each in about 0.1 ms.
• Windows's own record of the attach: osvc = 00 00. Microsoft documents 0x0000 as "the device didn't provide a valid response to the Microsoft OS string descriptor request" and 0x01xx as valid with vendor code xx.
• Guest ETW trace (USBHUB3 + USBXHCI), failing attach vs attach with osvc written by hand first (90 01, the reverse of what Windows writes itself):
  • Working: after configuration, control transfers of 16 and 40 bytes (extended compat ID) and 10 and 146 bytes (extended properties) are issued and succeed.
  • Failing: none of those four appears. The enumeration has one extra 18-byte control transfer, consistent with the OS string request (inferred from the length; the trace has no setup packets).
  • Identical in both: six "Descriptor Validation Warning" events (value 0x50) and a failed Language ID string request (0xC0000004). So these are not the cause.
  • Control transfers during enumeration are initiated 30 to 250 microseconds apart in both, much faster than a full-speed bus round trip, so the virtual device seems to answer from memory.
• Cold attach (controller assigned while Windows boots, same preconditions: cache key deleted, device node removed): Windows wrote osvc = 01 90 itself, USB\MS_COMP_XUSB10 appeared, xusb22 bound, XInput slot 0 connected. The device arrived 1 second after boot, with no later arrival.
• Linux treats the same VID/PID as an Xbox 360 pad (xpad, 0x1949:0x041a), and the Windows inbox driver binds when the compat ID is present, so the controller itself is fine.

Workaround that works

In an elevated PowerShell in the guest:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\usbflags\1949041A0101" /v osvc /t REG_BINARY /d 9001 /f
pnputil /remove-device "<instance id of USB\VID_1949&PID_041A\...>" /subtree

Then detach and attach the controller again. Result: USB\MS_COMP_XUSB10, xusb22 bound, problem code 0, XInput slot 0 connected, input confirmed. The value lives on the guest disk, so it is lost after a snapshot revert or in a new VM. Note: after a cold attach Windows itself writes the bytes 01 90 (01, then the vendor code). I verified the hand-written 90 01 above on a hot attach; I have not yet verified a hand-written 01 90 on a hot attach.

What I could not determine

• What the virtual device returned to the early 0xEE request, because the guest trace contains no payloads. I did not look into VMPal's code.
• Whether the request is forwarded to the physical device or answered from cached descriptors.
• Why only the hot-attach path fails (a descriptor cache that is not ready yet, a device reset on attach, or a different code path for hot-plug). None of these was tested.
• vmpal diagnostics shows usbDevices: ["Amazon Luna Controller"] but the VM log has no line about attaching, detaching or forwarding the accessory, and the macOS unified log has nothing for the VMPal process or USB sources at the attach times. A log line per attach and per failed control request would have made this easy to narrow down.

What I attach and what I send separately

• Attached: a zip with my notes on the traces and the cold-attach test, the read-only descriptor probe (C#) and the acceptance script (PowerShell) that checks the result.
• Not attached: the raw ETW traces (they contain the controller's serial number) and the VMPal diagnostics zip (it contains VM names, folder paths and the Mac user name). I am sending the diagnostics zip by email to nick@tableplus.com (the contact address from the EULA) and will reference this issue. The traces can follow privately on request.

Attachement: luna-usb-evidence.zip