How to install WinUSB.sys without a custom INF?

Authored by Eliyas Yakub [MSFT] and Qiang Qiu [MSFT]

WinUSB is a Microsoft-provided kernel-mode client driver for USB devices. If you are developing a USB device for which Windows doesn’t include an in-box class driver, you can use Winusb.sys as the device driver instead of writing your own driver. In this blog, we’ll explain how you can build your device so that the Winusb.sys gets installed automatically on Windows 8 and earlier versions of the operating system.

Prior to Windows 8 if you choose Winusb.sys as the function driver for your device, you have to write a custom INF (see Writing an .Inf File for WinUSB Installation, and then install the driver on the target machine. The custom INF must specify your device specific hardware ID and also include sections from the inbox Winusb.inf. Those sections are required for instantiating the service, copying inbox binaries, and registering DeviceInterfaceGUID that is required by applications to find the device and talk to it.

In Windows 8, the in-box Winusb.inf file has been updated. The INF includes an install section that references a compatible ID called USB\MS_COMP_WINUSB. It also includes a newly defined setup class called “USBDevice”.

The compatible ID and USBDevice definitions are shown here:



In order to match the compatible ID, the device must provide the ID by using Microsoft OS Descriptors. By building a device that reports the MS_COMP_WINUSB compatible ID, you can avoid writing a custom INF. The ability to provide compatible IDs through Microsoft OS descriptors has existed for several OS releases and has been widely used by other classes of devices, such as MTP, RNDIS, and Bluetooth.

The new USBDevice class is used for USB devices that do not conform to a USB-specific class specification. We will talk about need for defining this new USBDevice class later in this document.

Here are the steps for installing your device automatically using WinUSB.INF:

  1. The device must provide a compatible-ID using the extended MS OS feature descriptor as described in WinUSB Device. This is sufficient to match the in-box Winusb.inf and load the WinUSB driver module.
  2. However, to find the device from your application, configure the device, and perform I/O operations, you need to register its DeviceInterfaceGUID. In previous versions of Windows, that registration was done through the custom INF. Starting in Windows 8, your device should report the interface GUID by using extended properties OS feature descriptor as described in the WinUSB Device.
  3. There are several device registry settings, that control the behavior of WinUSB, such as selective suspend, power policy ownership, idle timeout, wake settings. Those properties can also be provided by including one or more extended properties feature descriptors on the device.

WinUSB compatible ID support on earlier versions of Windows

As stated earlier, the ability to provide compatible and sub-compatible IDs through Microsoft OS Descriptors has existed since Windows XP SP3, and has been widely used by other classes of devices such as MTP, RNDIS, and Bluetooth. To enable the use of compatible ID for WinUSB devices, a new certified INF is now available on Windows update for down-level operating systems. If your computer is configured to get driver update automatically, the WinUSB driver will get installed without any user intervention by using the new INF package.

For some reason, if you have to provide an INF then there is no point in building your device with compatible-ID because you cannot certify the INF with a compatible-ID match. You must use device specific hardware-ID in your INF.

USBDevice Class

For years, development community has misused the “USB” setup class by using it for their unclassified devices instead of defining a custom class. The USB controller class is strictly used for installing controllers, hubs, and composite devices. For instance, if you use “USB” class for a class filter driver for a device, the filter gets applied to other USB stack drivers which are also part of that class. Misusing the “USB” class has led to reliability and performance issues.

To prevent that scenario, we have defined a new class, “USBDevice” for devices that do not belong to any other class.


When a device is installed by using WinUSB.INF on Windows 8, it automatically installs the device under the “USBDevice” class. This class is system-defined on Windows 8. On down-level OS versions, this class is defined by the new INF available through Windows Update. Note that this class is not limited to WinUSB. If you have a custom driver for your device, you can use the “USBDevice” setup class in the INF.

For some reason, if you have to install the device under a custom class then you do need to write your own INF. If you do write your INF then there is no point in building the device to report compatible-ID because you cannot certify your INF with a compatible-ID match. You have to use most device specific hardware-ID in your INF.

Showing a meaningful device description in Device Manager

Typically the description of the device that is shown in Device Manager is derived from the INF file. One drawback of using a generic in-box INF to install the driver is that all devices installed through that INF get the same device description, which is “WinUsb Device”. This is not ideal.

To uniquely identify and differentiate the device in Device Manager, Windows 8 provides a new property on a device class that instructs the system to give precedence to the device description reported by the device (iProduct string descriptor) over the description that comes from the INF. The USBDevice class defined in Windows 8 has this property. In other words, when a device is installed under USBDevice class, system queries the device for a device description and sets the Device Manager string to whatever is retrieved in the query. The device description provided in the INF is ignored.

The new class property is not supported on earlier versions of Windows. So if you really care about having a customized description for your device on earlier version of Windows, you have to write your own custom INF.

In the Device Manager images shown in this blog post, notice the device description strings: “MUTT”, “FX3”, and “SuperMUTT”. Those strings are provided by the USB device in its product string descriptor.


We built couple of test devices using MUTT to demonstrate how this feature works. We have below snapshots of device manager and registry settings to show what the compat-id and device description looks.

Example 1: Single Interface Device

This picture is for a single interface MUTT device that provides “WINUSB” as the compatibleID and as a result Winusb.sys gets loaded as the function driver for the device.


Example 2: Composite Device

This image shows how a composite device appears that provides WINUSB compatible-ID for each of the functions in Device Manager.




Example 3: Providing selective suspend and system wake settings

Until now, in order to configure power management features of WinUSB, you had to write registry entry values in the HW.AddReg section of your custom INF. The details can be found in WinUSB Power Management.

Now you can configure the behavior of Winusb.sys through the device itself. You can report registry values through the extended properties OS feature descriptor that enable or disable features in WinUSB for that device. In this example, we updated the single interface MUTT device to configure selective suspend and system wake capabilities of the device..

Selective suspend allows the device to enter low-power state when it is idle. System wake refers to the ability to a device to wake up a system when the system is in low-power state.

For selective suspend and system wake, these registry entries are required.

Registry Key



This value is set to 1 to indicate that the device can power down when idle (selective suspend).


This value is set to 1 to indicate that the device can be suspended when idle by default.


This value is set to 5000 in milliseconds to indicate the amount of time in milliseconds to wait before determining that a device is idle.


This value is set to 1 to allow the user to control the ability of the device to enable or disable USB selective suspend. A check box Allow the computer to turn off this device to save power on the device Power Management property page and the user can check or uncheck the box to enable or disable USB selective suspend.


This value is set to 1 to allow the user to control the ability of the device to wake the system from a low-power state. A check box Allow this device to wake the computer shows up in the device power management property page and the user can check or uncheck the box to enable or disable USB system wake.

After the device is enumerated and initialized, these registry entries get written under the Device Parameters section of the hardware key. The picture below shows the registry entries for the customer properties that are reported by the device using extended properties OS feature descriptor.


This image shows device’s Power Management Properties page:



We explored in this article how you can build a device by using Microsoft OS descriptors to provide compatible ID and configuration information so that Winusb.sys is installed automatically as a function driver. This feature is available on Windows 8 and earlier versions up to Windows XP SP3. We hope that by reading this post you will understand best practices for using the new USBDevice class.

-Eliyas Yakub and Qiang Qiu

Comments (18)

  1. dsmtoday says:

    In your summary, you write "This feature is available on Windows 8 and earlier versions up to Windows XP SP3".  Is that true?  Windows 7 will use these new descriptors and install a device without an INF file?

    Also, it would be very useful it you would post something like a bus traffic trace of the negotiation that occurs at device power on when the special descriptor is asked for.  I have read several of the documents for Microsoft OS descriptors, but still haven't quite figured out how to implement them.  A bus traffic trace example would clear up all ambiguity in the documentation.


  2. dsmtoday says:

    Since you aren't replying on your blog, I had to figure this one out myself.  The WinUSB.inf file in Windows 7 is missing the additional lines that Windows 8 has.  Therefore, your Summary is wrong.  This feature is ONLY available in Windows 8.

  3. Yes, Windows 7 will use these new descriptors and install a device without an INF file. However, for that to happen, the Windows 7 system should have access to the internet and should have the policy to get updates from Windows Update because the system needs a new INF from Windows Update that has a compat-id match.

    Essentially, you don't need to write an INF because we have written one that can be used by everybody.

  4. dsmtoday says:

    Okay, I got this working under Windows 7 to some degree.  It indeed auto-downloads the updated winusb compat-id inf driver.  But I found a very strange behavior under Win7 when plugging a device in for the first time when connected to a USB 3.0 port.  Examining a USB capture trace of enumeration shows that Win7 fetches the Compat ID information (wIndex == 4) as expected, but does not ask for the Extended Property information (wIndex == 5), so my device does not get its DeviceInterfaceGUID set.  The strange thing is that the updated winusb driver is downloaded and installed, and the device shows up in the device manager saying it is working properly without a yellow warning sign on it.

    When I try a similar test plugging into a plain old USB 2.0 on the same computer, Win7 does asks for the Extended Property information, and the DeviceInterfaceGUID information ends up in the Device Parameters section of the registry.  Note that in between each switching of my device from a USB 2.0 port to a USB 3.0 port and back, I do change the Product ID of the device so that Win7 will go through the entire enumeration process as if it had never seen the device.

    My device is a USB 2.0 device.  I've updated the USB 3.0 drivers (ASMedia XHCI Controller) to the latest I can find.  I've had no problem using this device plugged into the same USB 3.0 ports if I use the INF files I've written.

    I've tried debugging what could possibly be wrong for some time and examined a lot of USB trace captures, even down to the byte level.  Not sure why Win7 is not making a GET_MS_DESCRIPTOR request with wIndex == 5 when plugged into a USB 3.0 port.

  5. dsmtoday says:

    Just thought I'd add that the same problem occurs using the new IvyBridge Intel chipsets that offer USB 3.0.  No Extended Property enumeration when plugged into a super-speed (3.0) port, even though Compatible ID enumeration is done and new winusbcompat drivers are autodownloaded and installed.

    As before, full expected enumeration occurs when using a USB 2.0 port.

  6. dsmtoday says:

    In the document about OS descriptors called "OS_Desc_Ext_Prop.Doc", there is an example for a simple USB joystick that allows you to override the Icon and the Label using Extended Property IDs.  These are faithfully copied to the Device Parameters section of the registry, as is the DeviceInterfaceGUID I am using.  Since I can access my device using the DeviceInterfaceGUID, I am sure I'm doing the right thing for the Extended Property IDs.  However, neither the Icon nor the Label seem to have any effect in Win7 *OR* Win8.

    Also, under Win8, my device always shows up as WinUsb Device.  Is the problem that I'm running Win8 Evaluation Build 8400?

  7. Maciej says:

    I am running W8 build 9200 and icon/label do not work. Interface GUID works like a charm.

    Any suggestions?

  8. Georg Krebelder says:

    Is the WinUSB.inf Windows update with compatible ID support for WinXP – Windows 7 already available? If so could you please provide the KB article, so I can include the update in my installer.

  9. USB Blog says:

    To test the icon and label, please try with a USB 2.0 host controller first. For the request that retrieves the extended properties OS descriptor, does your device handle a bmRequestType targeting an interface recipient (0xC1) rather than device recipient?

    Other things to try: Use a vendor request code other than 0; Add an extended compat ID OS feature descriptor.

  10. What is the preferred way to handle connecting a device that uses the new OS descriptors to and older version of the OS that hasn't been updated with the new WinUSB.INI file?  Would you supply the WinUSB.INI yourself, or fallback to using a custom INI for your device?

  11. Pete Batard says:

    If it helps, you can also find an in-depth explanation of how to set your devices for automated WinUSB driver installation at…/WCID-Devices

  12. Ian Walters (Alcolizer) says:

    Has anyone confirmed this working with any configuration of windows XP yet?

  13. Eliyas Yakub [MSFT] says:

    Ability to auto install winusb with compat-id will not work on XP. Winusb driver and INF is not inbox on XP. You can install the driver using winusbcoinstaller.dll distributed in WDK, but then you have to write your own INF to match against the VID/PID to get the driver loaded for your device.

  14. Hannes Preishuber says:

    sorry guys- that really hard to do

    any help for eg PROLIFIC usb 2 Serial? (Windows 8.1)

  15. USB Blog says:

    What's hard to do? Have you contacted prolific? They may be able to give you a firmware update.

  16. Henk says:

    Why does windows update not update my winusb.inf on windows 7

  17. David Grayson says:

    You wrote that "Windows 8 provides a new property on a device class that instructs the system to give precedence to the device description reported by the device over the description that comes from the INF."  I tried looking for that property but I could not find it.  Could you please tell us what the name of that property is and where in the registry it can be found?

  18. kahnbln says:

    What have u do ? The driverhell is for small Companys not understodable, we must make Drivers für xp(in next 25 yeras) for W7/8/10
    all works on W32 but on 64 Bit not.. the Driver hell kill the usement of Windows.

    In Linux u can use fopen fclose fwrite fread.. HAS U NOT LEARN 1975 FILES AND DRIVER ARE THE SAME THING ??????

    tons of descriptors documents and different Contents, no possible line available Million of hits to the Thema USB Driver Windows.. what u want to do ? Menas that is acceptable for the Future ?

    the concept is wrong and it the secure Options As Admin or not Open with Edit and will Save (NO U ARE NOT ADMIN KILL YOUR EDIT)

    omg it give not a secure.. they are virtual without useable.