Enumerating USB device with invalid configuration descriptor

Hello,

I’m trying to write a USB function driver for an old USB device that is non-compliant (it’s a low-speed device with a bulk endpoint) while not having control of the firmware. I’ve discovered that on USB 2 ports, the bus driver will successfully enumerate a PDO with the correct VID and PIDs for the device. My function driver can then read the configuration descriptor, modify it to use an interrupt endpoint instead, and select the new configuration (which works just fine). On a USB 3 port however, the bus driver seemingly attempts to parse the configuration descriptor, fails, and creates a PDO with the device ID USB\CONFIGURATION_DESCRIPTOR_VALIDATION_FAILURE. This PDO fails device descriptor request URBs and calls to WdfUsbTargetDeviceCreateWithParameters with STATUS_NO_SUCH_DEVICE, so I suspect my function driver can’t convince the bus to re-select a valid configuration descriptor.

Is there any way to get the USB 3 bus driver to not read the configuration descriptors, similarly to how the USB 2 bus driver does it? Or am I going to have to write a bus filter driver to fix up the configuration descriptor requests on the fly?

Thanks,
Arseney

I assume the usb2 version of the driver is not as strict as the usb3 version of the driver. Have you captured a usb etw log trace for the usb3 case and looked in the log to see what specifically failed?

Bent from my phone


From: arseneyr
Sent: Tuesday, October 9, 2018 6:42 PM
To: Doron Holan
Subject: [NTDEV] Enumerating USB device with invalid configuration descriptor

OSR https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcommunity.osr.com%2F&data=02|01|doron.holan%40microsoft.com|de6ce16625994ab0049e08d62e51a1c0|72f988bf86f141af91ab2d7cd011db47|1|0|636747325500792583&sdata=nFdaLJYzUQRx%2BFVWVA%2BEqBQZb6STdZNB5dMzwZCN3v8%3D&reserved=0
arseneyr started a new discussion: Enumerating USB device with invalid configuration descriptor

Hello,

I’m trying to write a USB function driver for an old USB device that is non-compliant (it’s a low-speed device with a bulk endpoint) while not having control of the firmware. I’ve discovered that on USB 2 ports, the bus driver will successfully enumerate a PDO with the correct VID and PIDs for the device. My function driver can then read the configuration descriptor, modify it to use an interrupt endpoint instead, and select the new configuration (which works just fine). On a USB 3 port however, the bus driver seemingly attempts to parse the configuration descriptor, fails, and creates a PDO with the device ID USB\CONFIGURATION_DESCRIPTOR_VALIDATION_FAILURE. This PDO fails device descriptor request URBs and calls to WdfUsbTargetDeviceCreateWithParameters with STATUS_NO_SUCH_DEVICE, so I suspect my function driver can’t convince the bus to re-select a valid configuration descriptor.

Is there any way to get the USB 3 bus driver to not read the configuration descriptors, similarly to how the USB 2 bus driver does it? Or am I going to have to write a bus filter driver to fix up the configuration descriptor requests on the fly?

Thanks,

Arseney

The hub reports the start of device enumeration, three instances of “Validation Failure of Configuration Descriptor”, followed by “Maximum Enumeration Retry Count Reached” and “Device reported problems causing enumeration failure”. The last message has the device descriptor in the payload, but no indication of what failed to validate. However, I’m pretty sure it’s because of the bulk endpoint in a low-speed device. The USB compliance tool flagged it and the USB 2 function driver only worked when I edited the configuration descriptor to remove the bulk endpoint. I was just wondering if there was any way of making the USB 3 stack more lenient in device validation so it can at least enumerate a PDO.

Your Mixman DM2 driver works! Do the lights do anything once it’s calibrated? We’d like them to receive MIDI…do they?
Got a spec sheet on the thing? (didn’t see it on GitHub)
Thanks so much for resurrecting this cheap old piece of junk for us. We were about to scrap it.