Windows 8.1: USB MIDI Device Works on USB 2.0 Port, Doesn’t Work on USB 3.0 Port
Published Oct 12 2018 03:46 PM 3,487 Views
Occasional Visitor
First published on MSDN on Jan 21, 2014

Last update: September 2nd 2014

Note: A fix for this issue is included in August 2014 update rollup. Please apply the update using this link .  After the fix is applied, the timestamp on c:\windows\system32\drivers\usbhub3.sys should be 7/24/2014 or later.

Some USB MIDI devices have been found to not function correctly when plugged into a USB 3.0 port on Windows 8.1, but will work fine on USB 2.0 ports and also work fine on all USB ports on Windows 8.0.

The issue is that on Windows 8.1 the USB 3.0 hub driver will allow a request for a MS OS feature descriptor to be forwarded to a USB 1.1 device, whereas on Windows 8.0 it would not. A small subset of USB devices do not handle these requests correctly, and will end up getting confused after they receive such a request. Microsoft is currently investigating a fix for this issue.

It is possible that some non-MIDI devices are affected by this problem, but none are known so far.

How to Verify Your Device Is Affected By This Issue

Install Message Analyzer , which can be found here:

1. One-time step: After installing Message Analyzer, log out and then log back in to enable its tracing capabilities.

2. Start Message Analyzer.

3. Go to the File -> Capture / Trace page.

4. Scroll down and select USB 3.

5. Unplug the device you are troubleshooting (if it’s plugged in).

6. Click Start.

7. Plug in the device.

8. Wait for the device to appear in Windows.

9. Click Stop.

10. Add column UsbDevice (Home -> View Options -> Column Chooser, search for “UsbDevice” and double-click it).

11. Right-click the UsbDevice column and select Group.

12. Paste in the following filter to the Filter location in the ribbon (still in the Home tab). Click Apply Filter.

(*GetDeviceDescriptor.DeviceDescriptor.bcdUSB >= 0x0100 &&

*GetDeviceDescriptor.DeviceDescriptor.bcdUSB < 0x0200)


(*SetupPacket.bmRequestType== 0xc0 &&

*SetupPacket.bRequest == 0 &&

*SetupPacket.wValue == 0 &&

*SetupPacket.wIndex == 4 &&

*SetupPacket.wLength == 16)

13. Does a “Get Full Device Descriptor” and “Control In Transfer” show up under the same device?

If yes—you can apply this fix so that the “Control In Transfer” is no longer sent to the device, as it wasn’t in Windows 8.

If no—STOP. This fix does not apply.

14. Select a Get Full Device Descriptor event that is grouped with the Control In Transfer event.

15. In the Details pane, expand DeviceDescriptor.

16. Note down the hexadecimal values for idVendor, idProduct, and bcdDevice in order to construct the registry key location. In this example, idVendor=0x15CA, idProduct=0x0101, 0xF110. (Be sure you use the values with “0x” in front of them; the other number is in decimal and won’t work.)

Workaround Using the “osvc” Registry Override

There is a registry override that will prevent the MS OS feature descriptor request from being forwarded to the device, which is accomplished by setting the “osvc” registry value for the device to “00 00”. The “usbflags” registry key for a device is located under HKLM\System\CurrentControlSet\Control\usbflags, and is a concatenation of the idVendor, idProduct, and bcdDevice that are noted in step 16. For this example the key would be HKLM\System\CurrentControlSet\Control\usbflags\15CA0101F110.

Once the “osvc” registry value has been set, unplug and plug the device to see if the issue is resolved.

More information on the “osvc” registry value can be found here:

Known Devices

The following MIDI devices have been reported to have this problem:


· Medeli e-Drum (USB\VID_0A67&PID_1011&REV_0122)

Version history
Last update:
‎Oct 12 2018 03:46 PM
Updated by: