Winusb Drivers

[Holly Coffell]

Asan OEM or independent hardware vendor (IHV), you can build your device so that the Winusb.sys gets installed automatically on Windows 8 and later versions of the operating system. Such a device is called a WinUSB device and doesn't require you to write a custom INF file that references in-box Winusb.inf.

If Universal Serial Bus devices doesn't appear in the list of device classes, then you need to install the driver by using a custom INF.The preceding procedure doesn't add a device interface GUID for an app (UWP app or Windows desktop app) to access the device. You must add the GUID manually by following this procedure.

Under the Device Parameters key, add a String registry entry named DeviceInterfaceGUID or a Multi-String entry named DeviceInterfaceGUIDs. Set the value to the GUID you generated in step 2.

The following example .inf file shows WinUSB installation for most USB devices with some modifications, such as changing USB_Install in section names to an appropriate DDInstall value. You should also change the version, manufacturer, and model sections as necessary. For example, provide an appropriate manufacture's name, the name of your signed catalog file, the correct device class, and the vendor identifier (VID) and product identifier (PID) for the device. For info on creating a catalog file, see Creating a Catalog File for Test-Signing a Driver Package.

If you're installing WinUSB as the function driver for one of the functions in a USB composite device, you must provide the hardware ID that is associated with the function, in the INF. You can obtain the hardware ID for the function from the properties of the devnode in Device Manager. The hardware ID string format is USB\VID_vvvv&PID_pppp.

Starting in Windows 10, version 1709, the Windows Driver Kit provides InfVerif.exe that you can use to test a driver INF file to make sure there are no syntax issues and the INF file is universal. We recommend that you provide a universal INF. For more information, see Using a Universal INF File.

To install only a new custom device setup class, include a ClassInstall32 section in a device INF file. INF files for devices in an installed class, whether a system-supplied device setup class or a custom class, must not include a ClassInstall32 section.

Except for device-specific values and several issues that are noted in the following list, you can use these sections and directives to install WinUSB for any USB device. These list items describe the Includes and Directives in the preceding .inf file.

USB_Install.Services: The Include directive in the USB_Install.Services section includes the system-supplied .inf for WinUSB (Winusb.inf). The WinUSB coinstaller installs this .inf file if it isn't already on the target system. The Needs directive specifies the section within Winusb.inf that contains information required to install Winusb.sys as the device's function driver. You shouldn't modify these directives.

USB_Install.HW: This section is the key in the .inf file. It specifies the device interface globally unique identifier (GUID) for your device. The AddReg directive sets the specified interface GUID in a standard registry value. When Winusb.sys is loaded as the device's function driver, it reads the registry value DeviceInterfaceGUIDs key and uses the specified GUID to represent the device interface. You should replace the GUID in this example with one that you create specifically for your device. If the protocols for the device change, create a new device interface GUID.

User-mode software must call SetupDiGetClassDevs to enumerate the registered device interfaces that are associated with one of the device interface classes specified under the DeviceInterfaceGUIDs key. SetupDiGetClassDevs returns the device handle for the device that the user-mode software must then pass to the WinUsb_Initialize routine to obtain a WinUSB handle for the device interface. For more info about these routines, see How to Access a USB Device by Using WinUSB Functions.

USB_Install.CoInstallers: This section, which includes the referenced AddReg and CopyFiles sections, contains data and instructions to install the WinUSB and KMDF coinstallers and associate them with the device. Most USB devices can use these sections and directives without modification.

Each coinstaller has free and checked versions. Use the free version to install WinUSB on free builds of Windows, including all retail versions. To install WinUSB on checked builds of Windows, use the checked version (with the "_chk" suffix).

If you use the redistributable WinUSB package for Windows XP or Windows Server 2003, make sure that you don't uninstall WinUSB in your uninstall packages. Other USB devices might be using WinUSB, so its binaries must remain in the shared folder.

The WinUSB coinstaller (Winusbcoinstaller.dll) installs WinUSB on the target system, if necessary. The WDK includes three versions of the coinstaller depending on the system architecture: x86-based, x64-based, and Itanium-based systems. Each coinstaller is named WinusbcoinstallerX.dll and is located in the appropriate subdirectory in the WinDDK\\redist\winusb folder.

The KMDF coinstaller (WdfcoinstallerXXX.dll) installs the correct version of KMDF on the target system, if necessary. The version of WinUSB coinstaller must match the KMDF coinstaller because KMDF-based client drivers, such as Winusb.sys, require the corresponding version of the KMDF framework to be installed properly on the system. For example, Winusbcoinstaller2.dll requires KMDF version 1.9, which Wdfcoinstaller01009.dll installs. The x86 and x64 versions of WdfcoinstallerXXX.dll are included with the WDK under the WinDDK\\redist\wdf folder. The following table shows the WinUSB coinstaller and the associated KMDF coinstaller to use on the target system.

To install the driver, open Device Manager. Follow the instructions on the Update Driver Software wizard and choose manual installation. To complete the installation, provide the location of the driver package folder.

I need to communicate with a simple custom device directly through USB. I have full specifications for communication protocol. Unfortunately, the device vendor did not provide WinUSB driver for the device.

As I understand, it is looking for a signed .cat file. But in this case I have no any files to sign nor .cat file. I just want to install Windows own WinUSB driver for the device, and clearly Windows drivers should be signed by Microsoft.

If you only care about supporting Windows 8.1 and later, and you have the ability to change the device's firmware, you might consider using Microsoft OS 2.0 Descriptors. This will allow a Windows computer to recognize the device as a WinUSB device and automatically load the WinUSB driver.

Another option would be to use Zadig or the related library libwdi to install the driver for your device. I would only recommend this for small, temporary, or organization-internal installations since it is kind of a hack (it installs its own certificate into your Trusted Root Certification Authorities list).

If none of those options are going to work for you, then you need to look into buying a code-signing certificate from a certificate authority and signing your driver. Code signing for Windows is an ever-evolving field but my article Practical Windows Code and Driver Signing attempts to document what you need to know.

I have a system I am working on that communicates with some custom hardware via USB. I used the NI driver wizard to create some visa drives, and perform USB RAW writes and reads, and everything was working great. Unfortunately, I just found out that there is a whole other application written in C++ by someone else that also has to communicate with the same hardware on the same system. Their application uses WinUSB to communicate with the device, so currently the only way I know of to switch between the two applications is to uninstall the VISA drivers, and install the WinUSB drivers, or vice-versa, depending on which application one wants to use. This obviously isn't going to work long-term.

I'm not sure how to fix this so that we can use both application on the machine without having to constantly change the drivers back and forth. I thought about trying to call WinUSB.dll using LabVIEW, but I'm afraid that might get a little complication. I figured I can't be the first one to run into a problem like this before, so before I start down the WinUSB road, I thought I would check to see if anyone has any better ideas. I'm afraid trying to get at the source, or in anyway changing, the C++ application is not an option.

Technically it is not so much WinUSB which is the likely problem but probably something in the application installation which registers WinUSB as the driver handler for your USB device resource. Except for filter drivers, which are chained into the driver chain by Window and for which Windows has a configurablle maximum limit of active filter drivers in the system, Windows only allows one driver to register for a specific device resource. So it would be technically enough to just change that registration entry to point to the currently desired driver.

However this registration API (SetupDI API and its friends) is quite cumbersome and the whole process is rather brittle as it easily can break with every new driver update. Also it would never allow to run both application in parallel, even if you make sure that they do not communicate to the device at the same time.

So calling WinUSB in LabVIEW is probably your safest bet. It won't be trivial, the WinUSB API is somewhat involved but it is definitely doable. The most difficult part is the implementation of your device protocol anyhow which you seem to have tackled already for the VISA raw mode, so I do not see real road blocks ahead, just some botherings about correct Call Library Node configurations

3a8082e126