Device is busy and blocked from host, even if not set up to be captured (solution included)

[cpg]

Tested on host: Windows (XP - 7, both 32/64)

Plugging in a USB device while VB is started (not necessarily running a VM), causes the device to stall, even if VB is not set up to capture it. If the device was plugged in already, it keeps working after starting VB, but when trying to capture it, the device stalls, showing the error that the device is "busy with a previous request" and it stays in that state until VB is closed.

I have encountered this problem with multiple versions, but i finally decided to find the cause (with the latest version). In both VBoxUsbMon.sys and VBoxUsb.sys, Usb Request Blocks (URBs) are sent to get the vendor/product id and device strings while the device is initializing. However, the available languages for the strings aren't retrieved from the device first; instead language id 0 is used. Most devices seem to accept this, but my phone does not. I have verified this by overwriting the language field. The device could then be switched between my host and guest without issue. I imagine this could affect other host platforms (and USB devices) as well, but was unable to verify this.

The solution would be to first retrieve USB string index 0 to determine the available languages and set the language field to a supported value for any other indices.

[michaln]

Thanks for debugging this. Your device is probably broken and should fail the request instead of stalling. However, it's certainly true that VirtualBox should query and use the language IDs the device supports. Interestingly, most USB devices seem to ignore the language ID completely and simply return whatever strings they have. Some devices fail the request with zero language ID, but that's not a problem for VirtualBox because the string descriptors are optional anyway.

The problem is Windows host specific, but it is possible (even likely) that other USB devices have the same problem. The USB 2.0 spec is unfortunately very vague as to how devices should handle such invalid requests.

Does your USB device support more than one language? Which language(s) does it support? (Devices which support more than one language ID - US English - are pretty rare.)

[michaln]

This should be fixed now (by querying the language IDs and use a language from the list). I can't verify that it fixes your specific problem because I don't have any sufficiently broken device, but I no longer see string descriptor queries with language ID of zero.

[Frank Mehnert]

The fix will be included in the 3.2.6 release (expected soon).

[cpg]

It certainly surprised me as well to find the device doesn't just ignore a request like this, though if it would be broken, i would expect different errors than this (but it seems to work perfectly fine). As you stated, the USB specification isn't entirely clear, so the manufacturer might just not have spent any thought on this particular problem. The phone indeed only supports US English.

Regardless, thanks for the quick fix. I'm fairly confident the described changes will solve my problem. Browsing through the tickets, i have seen some similar issues; who knows if it might solve some of those.