-->
Select Let me pick from a list of device drivers on my computer. From the list of device classes, select Universal Serial Bus devices. The wizard displays WinUsb Device. Select it to load the driver. If Universal Serial Bus devices does not appear in the list of device classes, then you need to install the driver by using a custom INF.
The package provides the installation files for Synaptics PS/2 Port TouchPad Driver version 19.5.31.11. If the driver is already installed on your system, updating (overwrite-installing) may fix various issues, add new functions, or just upgrade to the available version. For a listing of video card drivers, see our video card drivers page. Other PCI device that Windows cannot identify. If you tried the above two steps and your Windows Device Manager still contains an Unknown PCI device, likely the device cannot be identified.
Summary
- Automated testing by using USB Type-C ConnEx
- USB Type-C interoperability test procedures in Windows 10: functional testing (FT) and stress testing (ST).
- Diagnostic procedures and tips to confirm scenarios, such as device addition and removal.
Applies to
- Windows 10
Specifications and procedures**
Note
Some information relates to pre-released product which may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here.
The MUTT Connection Exerciser Type-C (USB Type-C ConnEx) hardware board is a custom shield for the Arduino board. The shield provides a four-to-one switch to automate interoperability tests for USB Type-C scenarios.
This topic provides guidelines to automate the testing of systems, devices, docks with USB Type-C connectors and their interoperability with the Windows operating system. You can test hardware that belong to one of the following categories:
- System: Desktops, laptops, tablets, servers, or phones running a SKU of a version of the Windows operating system with an exposed USB Type-C port.
- Dock: Any USB Type-C device that exposes more than one port.
- Device: Any USB device with a Type-C port that can be attached to a system or dock. This category includes traditional USB devices as well as devices that support the accessory and alternate modes as defined in the USB Type-C specification.
Hardware requirements
To perform the USB Type-C interoperability test procedures by using USB Type-C ConnEx, you need:
System under test (SUT)
Desktops, laptops, tablets, servers, or phones with at least one exposed Type-C USB port.
Arduino Mega 2560 R3
Arduino Mega 2560 R3 is used as the microcontroller for the test setup.
Power adapter for the Arduino Mega 2560 R3 microcontroller.
USB Type-C ConnEx
The shield has one male USB Type-C port (labeled J1) to which the SUT is connected. The shield also has four other USB ports (labeled J2, J3, J4, J6) to which devices can be attached that act as peripherals to the SUT. The shield monitors amperage and voltage being drawn from the SUT. You can buy this board from MCCI or JJG Technologies.
USB A-to-B cable
You will use this cable to connect a PC to the microcontroller in order to update the firmware on the microcontroller to run tests.
Peripheral USB devices
Any USB device with a USB Type-C port that can be attached to the SUT. This category includes traditional USB devices and other devices that support the accessory and alternate modes as defined in the USB Type-C specification.
USB charger
USB Type-C that supports USB Type-C current requirements and optionally USB Power Delivery. You also need a USB Micro-B charger for J6.
Proxy controller
The USB Type-C ConnEx can be controlled by using a proxy for running the tests. The proxy controller can be one of these entities:
Secondary desktop PC or a laptop.
The proxy controller communicates with a mobile SUT, the microcontroller to load the firmware.
SUT by using a secondary USB port.
SUT by using a 3.5mm audio jack.
In this set up, you need:
DTMF shield to run tests on SUTs with a single USB Type-C port. DTMF provides the ability to control the shield from a single-port device with an audio jack after the initial flash of the firmware has been completed.
4-pin male-to-male audio cable used to connect the DTMF shield to the SUT. This allows the SUT to control the USB Type-C shield during testing.
Software requirements
Make sure you meet these requirements:
Your SUT must have the version of the Windows operating system with which you want to test interoperability.
The proxy controller must be running Windows 10.
and install the latest MUTT software package on the proxy controller.The package is a suite of tools used to run tests with USB Type-C ConnEx. It includes utilities to update the firmware, switch between the peripheral ports, and send requests to simulate test cases. It also contains test driver packages that test the functionality of the buses, its controller, and devices connected to the bus.
For UCSI based systems we strongly recommended testing with some additional settings to help discover UCSI firmware bugs. This setting will make UCSI firmware issues discoverable and is highly recommended for testing purposes only. Please see Debugging USCI firmware failures in this blog post.
Installation of the test tools requires an elevated command window.
To open an elevated command window, the user must be a member of the Administrators group on the proxy controller. To open an elevated Command Prompt window, create a desktop shortcut to Cmd.exe, select and hold (or right-click) the Cmd.exe shortcut, and select Run as administrator.
USB Type-C ConnEx tools
Here are the tools in MUTT software package that are specific to USB Type-C ConnEx
| Tool | Description |
|---|---|
| ConnExUtil.exe | Command line tool for exercising USB Type-C ConnEx features. |
| CxLoop.cmd | Connects and disconnects each port once. |
| CxStress.cmd | Randomized stress script. |
| CxPower.cmd | Captures power data (voltage and amperage) over a period of time and sends the output to a CSV file. |
For information about all other tools, see Tools in the MUTT software package.
Get started
Follow this procedure to set up your test environment.
The configuration should be similar to this image. Note that the USB Type-C port on the microcontroller provides control over USB Type-C ConnEx when connected to a PC.
In these steps, you will connect the hardware pieces, update the firmware on the microcontroller, and validate the installation. The DTMF shield provides control over USB Type-C ConnEx when connected to the audio port of a phone or tablet.
Connect the microcontroller to the USB Type-C shield.
If the USB Type-C ConnEx did not come assembled, then continue with step 1. If your USB Type-C ConnEx has been assembled, then proceed to step 2.
Caution
This step must be performed carefully because the pins bend easily.
Align the pins of the USB Type-C shield with the receptors on the microcontroller by making sure that the boards are level to each other.
Gently press the two boards together. Be careful not to bend the pins on the shield.
Your assembled unit should be similar to this image:
Power the USB Type-C ConnEx from the attached microcontroller by using either the USB Type-B (connected to the proxy controller) or from an external power adapter. The LCD display is similar to this image:
After five seconds, the LCD display shows the current and voltage.
If you do not the see display as shown in the previous image, make sure your have assembled the unit correctly.
Update the microcontroller with the USB Type-C ConnEx firmware.
Open an elevated Command Prompt window.
Navigate to the location of the MUTT software package, such as C:Program Files (x86)USBTest<arch>.
Run the following command:
MuttUtil.exe –UpdateTabFirmware
Plug in the SUT to the male USB Type-C port (labeled J1) on the shield.
Caution The J1 connector requires additional support when connecting the SUT. The connector is not sturdy enough to sustain the weight of a device or by itself.
Attach the peripherals to the USB ports labeled J2, J3, J4, J6.
Attach the proxy controller to the microcontroller.
- If the proxy controller is a desktop PC or laptop, establish connection over USB. Connect the USB Type-B port on the microcontroller to a USB port on the proxy controller, as shown in the preceding image.
- If the proxy controller is a mobile SUT, establish connection by using the audio port. For this connection, you need the DTMF shield.
Connect the DTMF shield to the assembled unit as shown in this image:
Connect the audio port of the shield to the audio port on the SUT by using a 4-pin male-to-male audio cable.
Your setup should be similar to this image:
Make sure USB Type-C ConnEx is recognized by Device Manager on the proxy controller.
Right-click the Start button in the task bar and select Device Manager.
Expand the Ports (COM & LPT) node and note the COM port that is used by the microcontroller. In this example, it is connected to COM 4.
ConnExUtil.exe
Here are the command line options that ConnExUtil.exe supports for controlling the USB Type-C ConnEx board.
| Use case | Option | Description |
|---|---|---|
| Device Discovery List all devices connected to USB Type-C ConnEx | /list | For USB connected devices, this option lists the device instance path. For audio connected devices it shows Audio. To view audio devices, use this in combination with the /all parameter. Lists with 1-based index that can be used for input to the /# parameter. |
| Device Selection Select all devices connected to USB Type-C ConnEx, including audio. | /all | Optional. Without this parameter, the utility addresses USB connected devices. Use this parameter only if an audio connected device is in use. Audio discovery is time consuming and disabled by default. |
| Device Selection Select a specific device connected to USB Type-C ConnEx ‘n’. | /#n | (Optional) Input n is a 1-based index of the available devices connected to USB Type-C ConnEx which can be viewed by using the /list parameter. Without this parameter, the default behavior is to run each command on all USB Type-C ConnEx boards. |
| Device Command | /setPortp | Switch to the specified port p. Connect a port either by specifying number (1 – 4) or by name (J2, J3, J4, J6). 0 disconnects all ports. |
| Device Command | /getPort | Read the currently connected port. |
| Device Command Read amperage/voltage information | /volts /amps /version | Read the current voltage. Read the current amperage. Read the device version. |
| Device Command Enable SuperSpeed | /SuperSpeedOn | Enables SuperSpeed globally for current and future connections until a /SuperSpeedOff command is sent. SuperSpeed is enabled by default. If SuperSpeed is disabled, and port 1 or 2 is connected, this command triggers a reconnect at SuperSpeed. |
| Device Command Disable SuperSpeed | /SuperSpeedOff | Disables SuperSpeed globally for current and future connections until a /SuperSpeedOn command is sent or the device is reset. If SuperSpeed is enabled and port 1 or 2 is connected, this command triggers a reconnect with SuperSpeed lines disabled. |
Set command delay | /setDelayt | Sets command delay t in seconds. Setting a command delay will cause the next /setPort or /SuperSpeed{On/Off} command to be delayed by t seconds where t ranges from 0 to 99. This is a one-time setting, only the next command is delayed. Sending multiple commands before the delay timer has expired is not supported. |
Set disconnect timeout in milliseconds | /setDisconnectTimeoutt | Set a disconnect timeout for the next non-zero /setPort command. On the next connect event, the port will only remain connected for t milliseconds before disconnecting. This is a one-time setting, only the next connect event will be automatically disconnected. Allowed range is from 0 – 9999 ms. |
Batch Command: Output power measurements to a .csv file. | /powercsv | Append the current power measurements and timestamp into power.csv The first run creates power.csv. On subsequent runs appends data to this file. Rename or delete the file to start fresh data capture. Each run appends a line with the following format: <index>,<time>,<volts>,<amps>. index is the device index given by /list, so multiple devices may be monitored simultaneously. time is the raw timestamp in seconds. volts and amps are recorded to two decimal places. This data may be captured over long periods of time and plotted in a spreadsheet application, see the cxpower.cmd script. |
Batch Command: Run unit test of major functionality | /test | Tests all the major functionality of the device. Use for basic validation of the functionality of the device. If this command fails, please power cycle the device and update the firmware. |
Batch Command: Basic demo of the port switching sequence. | /demo d | Loop through all ports one time, with d second delay on each port Writes the port number, volts and amps on each port into demoresult.txt. |
Sample Commands
Flowline Port Devices Driver Updater
Connect to a port
Alternatively use the port name as printed on the board:
Disconnect all ports
Loop through all ports
Scripts for controlling the USB Type-C ConnEx board
These scripts exercise the control interface supported by ConnExUtil.exe to run sequential and stress type tests with the USB Type-C ConnEx through the command line. All of these scripts support the optional command line parameter audio to indicate that the USB Type-C ConnEx board is connected over the 3.5 mm audio interface. By default they will only attempt to use USB connected boards.
Simple connect / disconnect sequence: CXLOOP.CMD
Connects and disconnects the SUT to and from each port (1-4) and pauses on each port prompting the tester to validate the connection on that port.
Random connect / disconnect loop: CXSTRESS.CMD
Connects and disconnects the SUT to and from each port at random for a random interval of 0.0-5.0 seconds in an infinite loop. When connecting to the USB Type-C ports it will randomly enable or disable SuperSpeed connection on that port, and will randomly instruct the board to disconnect quickly on that port at some random interval 0 – 999 ms.
The command line parameter C causes the script to only switch between the USB Type-C ports and the disconnected state. A numeric command line parameter resets the maximum random interval between switches from the default of 5.0 seconds to the input value in seconds. Parameters may be passed in any order.
Long running power measurement: CXPOWER.CMD
Saves the amperage and voltage reported by the USB Type-C ConnEx to output file power.csv at 2 second intervals. The data is formatted as comma-separated variables as follows:
index,time,volts,amps
index is the device index given by the ConnExUtil.exe /list command so multiple devices may be monitored simultaneously.
time is the raw timestamp in seconds.
volts and amps are recorded to 2 decimal places.
After capture is complete, this data may be post processed into charts showing power consumption over time, for example the power consumption for the duration of a battery charge cycle. A numeric command line parameter resets the default measurement interval of 2 seconds to the input value in seconds.
About test cases
The USB Type-C interoperability test procedures are divided into two sections: functional testing (FT) and stress testing (ST). Each test section describes the test case and identifies the category that applies to the test. The product must be tested against the entire applicable category. Certain test cases contain links to relevant hints and tips for additional information. This section is focused on USB Type-C functionality and experience. A USB Type-C solution may contains other USB components such as a USB hub or USB controller. Detailed testing of USB hubs and controllers is covered in both the USB-IF's xHCI interoperability test procedures and the Windows Hardware Certification Kit.
These test cases are based on the ConnExUtil commands and example scripts Scripts for controlling the USB Type-C ConnEx board. The test cases refer to the scripts. Customize the scripts as required for your test scenario.
Device Enumeration
Confirms that core aspects of device enumeration are functional.
Alternate Mode Negotiation
Confirms supported alternate modes.
Charging and power delivery (PD)
Confirms charging with USB Type-C.
Role Swap
Confirms role swap.
The stress testing section describes procedures for stress and edge case scenarios, which test device stability over a period of time. Stress testing does require a custom device (the SuperMUTT) for legacy USB validation (non USB Type-C). Additional testing and automation can be achieved with the upcoming USB Type-C test device.
Device Enumeration
Confirms that core aspects of device enumeration are functional.
Charging and power delivery (PD)
Confirms charging with USB Type-C.
FT Case 1: Device Enumeration
| Port | Device |
|---|---|
| J1 | SUT. |
| J2 | PC with USB Type-C port that is connected by using a USB Type-C cable. |
| J3 | USB Type-C charger. |
| J4 | USB Hub (SuperSpeed or high speed) with a mouse connected downstream. |
| J6 | PC with USB Type-A port cable connected by using a USB Type-A to USB Micro-B cable. |
- Power off the SUT.
- Connect the SUT to the port labeled as J1 on USB Type-C ConnEx.
- Connect the proxy controller to USB Type-C ConnEx.
- Connect peripherals to USB Type-C ConnEx.
- Power on the SUT and log on to Windows.
- At an elevated Command prompt, run the CXLOOP.CMD script. When script pauses, confirm the newly activated peripheral is operational.
- Reverse the orientation of USB Type-C cable and repeat step 5 - 7.
For configuration images related to step 2 -4, see Get started....
FT Case 2: Alternate Mode Negotiation
| Port | Device |
|---|---|
| J1 | SUT. |
| J2 | DisplayPort to USB Type-C dongle. |
| J3 | USB Type-C charger. |
| J4 | USB Hub (SuperSpeed or high speed) with a flash drive connected downstream. |
| J6 | PC with USB Type-A port cable connected by using a USB Type-A to USB Micro-B cable. |
- Power off the SUT.
- Connect the SUT to the port labeled as J1 on USB Type-C ConnEx.
- Connect the proxy controller to USB Type-C ConnEx.
- Connect peripherals to USB Type-C ConnEx.
- Power on the SUT and log on to Windows.
- At an elevated Command prompt, run the CXLOOP.CMD script. When script pauses, confirm the newly activated peripheral is operational.
- Reverse the orientation of USB Type-C cable and repeat step 5 - 7.
For configuration images related to step 2 -4, see Get started....
FT Case 3: Charging and power delivery (PD)
| Port | Device |
|---|---|
| J1 | SUT. |
| J2 | None. |
| J3 | USB Type-C charger. |
| J4 | USB mouse. |
| J6 | USB Micro-B charger. |
Power off the SUT.
Connect the SUT to the port labeled as J1 on USB Type-C ConnEx.
Connect the proxy controller to USB Type-C ConnEx.
Connect peripherals to USB Type-C ConnEx.
Power on the SUT and log on to Windows.
At an elevated Command prompt, run the CXLOOP.CMD script. When script pauses, confirm the newly activated peripheral is operational.
Reverse the orientation of USB Type-C cable and repeat step 5 - 7.
Connect USB Type-C ConnEx to port J2.
ConnExUtil.exe /setPort 2
If SUT contains more than one USB Type-C port, connect two USB Type-C ports on the same system with a USB Type-C cable.
Confirm that the SUT is not charging (itself).
Confirm that the LCD reading of power matches the expectations of the wall adapter.
Replace the USB Type-C charger connected to J3 with another USB Type-C charger from a different manufacturer.
Confirm the device is receiving current.
For configuration images related to step 2 -4, see Get started....
FT Case 4: Role Swap
| Port | Device |
|---|---|
| J1 | SUT. |
| J2 | PC with USB Type-C port that is connected by using a USB Type-C cable. |
| J3 | None. |
| J4 | USB flash drive. |
| J6 | PC with USB Type-A port cable connected by using a USB Type-A to USB Micro-B cable. |
Power off the SUT.
Connect the SUT to the port labeled as J1 on USB Type-C ConnEx.
Connect the proxy controller to USB Type-C ConnEx.
Connect peripherals to USB Type-C ConnEx.
Power on the SUT and log on to Windows.
At an elevated Command prompt, run the CXLOOP.CMD script. When script pauses, confirm the newly activated peripheral is operational.
Reverse the orientation of USB Type-C cable and repeat step 5 - 7.
Connect USB Type-C ConnEx to port J2.
Confirm role swap. The Amperage shown on the LCD screen indicates power roles. +ve if J1 is the power sink; -ve if J1 is the power source.
Perform necessary steps to swap data roles and confirm current roles of each system have changed.
For configuration images related to step 2 -4, see Get started....
ST Case 1: Device Enumeration
| Port | Device |
|---|---|
| J1 | SUT. |
| J2 | PC with USB Type-C port that is connected by using a USB Type-C cable. |
| J3 | USB Type-C charger. |
| J4 | USB Hub (SuperSpeed or high speed) with a mouse connected downstream. |
| J6 | PC with USB Type-A port cable connected by using a USB Type-A to USB Micro-B cable. |
Power off the SUT.
Connect the SUT to the port labeled as J1 on USB Type-C ConnEx.
Connect the proxy controller to USB Type-C ConnEx.
Connect peripherals to USB Type-C ConnEx.
Power on the SUT and log on to Windows.
At an elevated Command prompt, run the CXSTRESS.CMD for 12 hours.
Terminate the script by pressing Ctrl-C.
Perform the steps described in FT Case 1: Device Enumeration.
For configuration images related to step 2 -4, see Get started....
ST Case 2: Charging and power delivery (PD)
| Port | Device |
|---|---|
| J1 | SUT. |
| J2 | None. |
| J3 | USB Type-C charger. |
| J4 | USB mouse. |
| J6 | USB Micro-B charger. |
Power off the SUT.
Connect the SUT to the port labeled as J1 on USB Type-C ConnEx.
Connect the proxy controller to USB Type-C ConnEx.
Connect peripherals to USB Type-C ConnEx.
Power on the SUT and log on to Windows.
At an elevated Command prompt, run the CXSTRESS.CMD for 12 hours. .
Terminate the script by pressing Ctrl-C.
Perform the steps described in FT Case 3: Charging and power delivery (PD).
For configuration images related to step 2 -4, see Get started....
Additional test resources
The following functional tests can be adapted for USB Type-C to improve traditional USB scenarios.
| Test case | Description | Category |
|---|---|---|
| System Boot | Confirms that the product does not inhibit normal system boot. | System, Dock, Device |
| System Power Transitions | Tests whether the system's power transitions and wake-up capability from lower power states are not affected by the product. | System, Dock, Device |
| Selective Suspend | Confirms the selective suspend transitions. | Dock, Device |
The following stress tests can be adapted from the SuperMUTT test documentation to expand USB scenarios.
| Test case | Description | Category |
|---|---|---|
| System Power Transitions | Tests product reliability after repetitive system power events. | System, Dock, Device |
| Transfer Events | Generates multiple transfer and connection events. | System, Dock, Device |
| Plug and Play (PnP) | Generates various PnP sequences. | System, Dock, Device |
| Device Topology | Tests a range of devices and topologies with the product. | System, Dock, Device |
Validating success or failure of the tests
Confirming charging and power
The onboard LCD on the USB Type-C ConnEx displays power (volts, amps, and direction). Confirm that it matches expectations from power sources plugged in and actively enabled with the USB Type-C ConnEx .
Confirming device addition on desktops
- Identify the USB host controller to which your device is connected.
- Make sure that the new device appears under the correct node in Device Manager.
- For USB 3.0 hubs connected to a USB 3.0 port, expect to see two hub devices: one enumerated at SuperSpeed and another at high speed.
Confirm device removal on desktops
- Identify your device in Device Manager.
- Perform the test step to remove the device from the system.
- Confirm that the device is no longer present in Device Manager.
- For a USB 3.0 hub, check that both devices (SuperSpeed and companion hubs) are removed. Failure to remove a device in this case may be a device failure and should be investigated by all components involved to triage the appropriate root cause.
Confirm device functionality
- If the device is a USB hub, make sure that the devices that are downstream of the hub are functional. Verify that other devices can be connected to available ports on the hub.
- If the device is an HID device, test its functionality. Make sure that a USB keyboard types, a USB mouse moves the cursor, and a gaming device is functional in the game controller's control panel.
- A USB audio device must play and/or record sound.
- A storage device must be accessible and should be able to copy a file 200MB or more in size.
- If the device has multiple functions, such as scan & print, make sure to test both the scan and print functionality.
- If the device is a USB Type-C device, confirm that the applicable USB and alternate modes are functional.
Using ETW to log issues
See How to capture a USB event trace with Logman
Reporting test results
Provide these details:
- The list of tests (in order) that were performed before the failed test.
- The list must specify the tests that have failed or passed.
- Systems, devices, docks, or hubs that were used for the tests. Include make, model, and Web site so that we can get additional information, if needed.
For certain Universal Serial Bus (USB) devices, such as devices that are accessed by only a single application, you can install WinUSB (Winusb.sys) in the device's kernel-mode stack as the USB device's function driver instead of implementing a driver.
This topic contains these sections:
Automatic installation of WinUSB without an INF file
As an 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 does not require you to write a custom INF file that references in-box Winusb.inf.
When you connect a WinUSB device, the system reads device information and loads Winusb.sys automatically.
For more information, see WinUSB Device.
Installing WinUSB by specifying the system-provided device class
When you connect your device, you might notice that Windows loads Winusb.sys automatically (if the IHV has defined the device as a WinUSB Device). Otherwise follow these instructions to load the driver:
- Plug in your device to the host system.
- Open Device Manager and locate the device.
- Select and hold (or right-click) the device and select Update driver software... from the context menu.
- In the wizard, select Browse my computer for driver software.
- Select Let me pick from a list of device drivers on my computer.
- From the list of device classes, select Universal Serial Bus devices.
- The wizard displays WinUsb Device. Select it to load the driver.
If Universal Serial Bus devices does not appear in the list of device classes, then you need to install the driver by using a custom INF.The preceding procedure does not 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.
Load the driver as described in the preceding procedure.
Generate a device interface GUID for your device, by using a tool such as guidgen.exe.
Find the registry key for the device under this key:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetEnumUSB<VID_vvvv&PID_pppp>
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.
Disconnect the device from the system and reconnect it to the same physical port.Note If you change the physical port then you must repeat steps 1 through 4.
Writing a custom INF for WinUSB installation
As part of the driver package, you provide an .inf file that installs Winusb.sys as the function driver for the USB device.
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.
Also notice that the setup class is set to 'USBDevice'. Vendors can use the 'USBDevice' setup class for devices that do not belong to another class and are not USB host controllers or hubs.
If you are 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 'USBVID_vvvv&PID_pppp'.
Flowline Port Devices Driver Device
The following INF installs WinUSB as the OSR USB FX2 board's function driver on a x64-based system.
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 recommened that you provide a universal INF. For more information, see Using a Universal INF File.
Only include a ClassInstall32 section in a device INF file to install a new custom device setup class. 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: The Include and Needs directives in the USB_Install section are required for installing WinUSB. You should not modify these directives.
USB_Install.Services: The Include directive in the USB_Install.Services section includes the system-supplied .inf for WinUSB (WinUSB.inf). This .inf file is installed by the WinUSB co-installer 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 should not modify these directives.Note Because Windows XP doesn't provide WinUSB.inf, the file must either be copied to Windows XP systems by the co-installer, or you should provide a separate decorated section for Windows XP.
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.
Note 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.
The following INF installs WinUSB as the OSR USB FX2 board's function driver on a x64-based system. The example shows INF with WDF coinstallers.
USB_Install.CoInstallers: This section, which includes the referenced AddReg and CopyFiles sections, contains data and instructions to install the WinUSB and KMDF co-installers and associate them with the device. Most USB devices can use these sections and directives without modification.
The x86-based and x64-based versions of Windows have separate co-installers.
Note Each co-installer has free and checked versions. Use the free version to install WinUSB on free builds of Windows, including all retail versions. Use the checked version (with the '_chk' suffix) to install WinUSB on checked builds of Windows.
Each time Winusb.sys loads, it registers a device interface that has the device interface classes that are specified in the registry under the DeviceInterfaceGUIDs key.
Note 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.
How to create a driver package that installs Winusb.sys
To use WinUSB as the device's function driver, you create a driver package. The driver package must contain these files:
- WinUSB co-installer (Winusbcoinstaller.dll)
- KMDF co-installer (WdfcoinstallerXXX.dll)
- An .inf file that installs Winusb.sys as the device's function driver. For more information, see Writing an .Inf File for WinUSB Installation.
- A signed catalog file for the package. This file is required to install WinUSB on x64 versions of Windows starting with Vista.
Note Make sure that the driver package contents meet these requirements:
- The KMDF and WinUSB co-installer files must be obtained from the same version of the Windows Driver Kit (WDK).
- The co-installer files must be obtained from the latest version of the WDK, so that the driver supports all the latest Windows releases.
- The contents of the driver package must be digitally signed with a Winqual release signature. For more info about how to create and test signed catalog files, see Kernel-Mode Code Signing Walkthrough on the Windows Dev Center - Hardware site.
Download the Windows Driver Kit (WDK) and install it.
Create a driver package folder on the machine that the USB device is connected to. For example, c:UsbDevice.
Copy the WinUSB co-installer (WinusbcoinstallerX.dll) from the WinDDKBuildNumberredistwinusb folder to the driver package folder.
The WinUSB co-installer (Winusbcoinstaller.dll) installs WinUSB on the target system, if necessary. The WDK includes three versions of the co-installer depending on the system architecture: x86-based, x64-based, and Itanium-based systems. They are all named WinusbcoinstallerX.dll and are located in the appropriate subdirectory in the WinDDKBuildNumberredistwinusb folder.
Copy the KMDF co-installer (WdfcoinstallerXXX.dll) from the WinDDKBuildNumberredistwdf folder to the driver package folder.
The KMDF co-installer (WdfcoinstallerXXX.dll) installs the correct version of KMDF on the target system, if necessary. The version of WinUSB co-installer must match the KMDF co-installer 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 is installed by Wdfcoinstaller01009.dll. The x86 and x64 versions of WdfcoinstallerXXX.dll are included with the WDK under the WinDDKBuildNumberredistwdf folder. The following table shows the WinUSB co-installer and the associated KMDF co-installer to use on the target system.
Use this table to determine the WinUSB co-installer and the associated KMDF co-installer.
WinUSB co-installer KMDF library version KMDF co-installer Winusbcoinstaller.dll Requires KMDF version 1.5 or later Wdfcoinstaller01005.dll
Wdfcoinstaller01007.dll
Wdfcoinstaller01009.dll
Winusbcoinstaller2.dll Requires KMDF version 1.9 or later Wdfcoinstaller01009.dll Winusbcoinstaller2.dll Requires KMDF version 1.11 or later WdfCoInstaller01011.dll Write an .inf file that installs Winusb.sys as the function driver for the USB device.
Create a signed catalog file for the package. This file is required to install WinUSB on x64 versions of Windows.
Attach the USB device to your computer.
Open Device Manager to install the driver. Follow the instructions on the Update Driver Software wizard and choose manual installation. You will need to provide the location of the driver package folder to complete the installation.
Related topics
Flowline Port Devices Driver Adapter
WinUSB Architecture and Modules
Choosing a driver model for developing a USB client driver
How to Access a USB Device by Using WinUSB Functions
WinUSB Power Management
WinUSB Functions for Pipe Policy Modification
WinUSB Functions
WinUSB