> Hmm, very odd. How are you testing this on the host side? We just attach the device and check the registry values created by OS for our device. As HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_XXXX&PID_YYYY&MI_NN\<device_instance>\Device Parameters. When it works our extended properties are created there. We check the communication using USB analyzer which clearly shows wValue bytes are in opposite order than documented. This is SETUP packet captured: Offset 0 1 2 3 4 5 6 7 0x000 C1 A1 02 00 05 00 0A 00 As you can see, this is interface request and out interface number was 2 which is in the low byte of wValue. > Could it be that you are running into the WinUSB bug described here: No. The mentioned bug is in wIndex and out problem is wValue. Also, MSOS descriptors are read before WinUsb is even run. Background: we have a composite device which uses MSOS descriptors with extended properties. It worked well on all tested Win10 and Win11 installations for two years until we applied your original fix which switches wValue bytes. Then extended properties stopped work. We looked for the culprit and found this. I understand MS documentation says interface number is in high byte of wValue but the real implementation uses low byte for it as was verified using USB analyzer. Question for you: > I had issues with getting Windows to accept the OS descriptors when > the function I wanted to use with WinUSB was not the first (= > interface 0) function in a composite device together with HID and > mass storage. What Windows version were you using and have you used USB analyzer to check the communication? Michal
