• Drivers Wiquest Usb Devices Adapter
• Drivers Wiquest Usb Devices Dongle
• Drivers Wiquest Usb Devices Pc Camera
• Drivers Wiquest Usb Devices Type C
• Drivers Wiquest Usb Devices Wireless Adapter
• Examples Of Usb Devices
• Drivers Wiquest Usb Devices Dongle

In this topic you'll use the USB User-Mode Driver template provided with Microsoft Visual Studio 2019 to write a user-mode driver framework (UMDF)-based client driver. After building and installing the client driver, you'll view the client driver in Device Manager and view the driver output in a debugger.

If you have to manually install a driver for the device — perhaps the driver is already installed on your system — you can use the Update Driver button in the device’s Properties window. If the device driver is already installed on your system, click the “Browse my computer for driver software” link and choose an installed driver. RE: How to download device drivers to a USB flash drive. The fastest way to download drivers is to your computer. You can copy them to a flash drive or other accessible storage device. Flash drives are normally much slower than HDDs or SSDs. You can run them from the external storage or copy them back to the new install and run from there.

UMDF (referred to as the framework in this topic) is based on the component object model (COM). Every framework object must implement IUnknown and its methods, QueryInterface, AddRef, and Release, by default. The AddRef and Release methods manage the object's lifetime, so the client driver does not need to maintain the reference count. The QueryInterface method enables the client driver to get interface pointers to other framework objects in the Windows Driver Frameworks (WDF) object model. Framework objects perform complicated driver tasks and interact with Windows. Certain framework objects expose interfaces that enable a client driver to interact with the framework.

A UMDF-based client driver is implemented as an in-process COM server (DLL), and C++ is the preferred language for writing a client driver for a USB device. Typically, the client driver implements several interfaces exposed by the framework. This topic refers to a client driver-defined class that implements framework interfaces as a callback class. After these classes are instantiated, the resulting callback objects are partnered with particular framework objects. This partnership gives the client driver the opportunity to respond to device or system-related events that are reported by the framework. Whenever Windows notifies the framework about certain events, the framework invokes the client driver's callback, if one is available. Otherwise the framework proceeds with the default processing of the event. The template code defines driver, device, and queue callback classes.

For an explanation about the source code generated by the template, see Understanding the UMDF template code for USB client driver.

Prerequisites

For developing, debugging, and installing a user-mode driver, you need two computers:

1. A UMDF-based client driver is implemented as an in-process COM server (DLL), and C is the preferred language for writing a client driver for a USB device. Typically, the client driver implements several interfaces exposed by the framework.
2. A UMDF-based client driver is implemented as an in-process COM server (DLL), and C is the preferred language for writing a client driver for a USB device. Typically, the client driver implements several interfaces exposed by the framework.

• A host computer running Windows 7 or a later version of the Windows operating system. The host computer is your development environment, where you write and debug your driver.
• A target computer running the version of the operating system that you want to test your driver on, for example, Windows 10, version 1903. The target computer has the user-mode driver that you want to debug and one of the debuggers.

In some cases, where the host and target computers are running the same version of Windows, you can have just one computer running Windows 7 or a later version of the Windows. This topic assumes that you are using two computers for developing, debugging, and installing your user mode driver.

Before you begin, make sure that you meet the following requirements:

Software requirements

• Your host computer has Visual Studio 2019.

• Your host computer has the latest Windows Driver Kit (WDK) for Windows 10, version 1903.

  The kit include headers, libraries, tools, documentation, and the debugging tools required to develop, build, and debug a USB client driver. You can get the latest version of the WDK from How to Get the WDK.

• Your host computer has the latest version of debugging tools for Windows. You can get the latest version from the WDK or you can Download and Install Debugging Tools for Windows.

• If you are using two computers, you must configure the host and target computers for user-mode debugging. For more information, see Setting Up User-Mode Debugging in Visual Studio.

Hardware requirements

Get a USB device for which you will be writing the client driver. In most cases, you are provided with a USB device and its hardware specification. The specification describes device capabilities and the supported vendor commands. Use the specification to determine the functionality of the USB driver and the related design decisions.

If you are new to USB driver development, use the OSR USB FX2 learning kit to study USB samples included with the WDK. It contains the USB FX2 device and all the required hardware specifications to implement a client driver.

Recommended reading

• Developing Drivers with Windows Driver Foundation, written by Penny Orwick and Guy Smith. For more information, see Developing Drivers with WDF.

Instructions

Step 1: Generate the UMDF driver code by using the Visual Studio 2019 USB driver template

For instructions about generating UMDF driver code, see Writing a UMDF driver based on a template.

For USB-specific code, select the following options in Visual Studio 2019

1. In the New Project dialog box, in the search box at the top, type USB.
2. n the middle pane, select User Mode Driver, USB (UMDF V2).
3. lick Next.
4. Enter a project name, choose a save location, and click Create.

The following screen shots show the New Project dialog box for the USB User-Mode Driver template.

This topic assumes that the name of the project is 'MyUSBDriver_UMDF_'. It contains the following files:

Step 2: Modify the INF file to add information about your device

Before you build the driver, you must modify the template INF file with information about your device, specifically the hardware ID string.

To provide the hardware ID string

1. Attach your USB device to your host computer and let Windows enumerate the device.

2. Open Device Manager and open properties for your device.

3. On the Details tab, select Hardward Ids under Property.

   The hardware ID for the device is displayed in the list box. Select and hold (or right-click) and copy the hardware ID string.

4. In Solution Explorer, expand Driver Files, and open the INF.

5. Replace the following your hardware ID string.

   [Standard.NT$ARCH$]

   %DeviceName%=MyDevice_Install, USBVID_vvvv&PID_pppp

Notice the AddReg entries in the driver's information (INF) file.

[CoInstallers_AddReg] ;

HKR,CoInstallers32,0x00010008,'WudfCoinstaller.dll'

HKR,CoInstallers32,0x00010008,'WudfUpdate_01011.dll'

HKR,CoInstallers32,0x00010008,'WdfCoInstaller01011.dll,WdfCoInstaller'

HKR,CoInstallers32,0x00010008,'WinUsbCoinstaller2.dll'

• WudfCoinstaller.dll (configuration co-installer)
• WUDFUpdate_<version>.dll (redistributable co-installer)
• Wdfcoinstaller<version>.dll (co-installers for KMDF)
• Winusbcoinstaller2.dll ((co-installers for Winusb.sys)
• MyUSBDriver_UMDF_.dll (client driver module)

If your INF AddReg directive references the UMDF redistributable co-installer (WUDFUpdate_<version>.dll ), you must not make a reference to the configuration co-installer (WUDFCoInstaller.dll). Referencing both co-installers in the INF will lead to installation errors.

All UMDF-based USB client drivers require two Microsoft-provided drivers: the reflector and WinUSB.

• Reflector—If your driver gets loaded successfully, the reflector is loaded as the top-most driver in the kernel-mode stack. The reflector must be the top driver in the kernel mode stack. To meet this requirement, the template's INF file specifies the reflector as a service and WinUSB as a lower-filter driver in the INF:

  [MyDevice_Install.NT.Services]

  AddService=WUDFRd,0x000001fa,WUDFRD_ServiceInstall ; flag 0x2 sets this as the service for the device

  AddService=WinUsb,0x000001f8,WinUsb_ServiceInstall ; this service is installed because its a filter.

• WinUSB—The installation package must contain coinstallers for Winusb.sys because for the client driver, WinUSB is the gateway to the kernel-mode USB driver stack. Another component that gets loaded is a user-mode DLL, named WinUsb.dll, in the client driver's host process (Wudfhost.exe). Winusb.dll exposes WinUSB Functions that simplify the communication process between the client driver and WinUSB.

Drivers Wiquest Usb Devices Adapter

Step 3: Build the USB client driver code

To build your driver

1. Open the driver project or solution in Visual Studio 2019.
2. Right-click the solution in the Solution Explorer and select Configuration Manager.
3. From the Configuration Manager, select your Active Solution Configuration (for example, Debug or Release) and your Active Solution Platform (for example, Win32) that correspond to the type of build you are interested in.
4. Verify that your device interface GUID is accurate throughout the project.
   • The device interface GUID is defined in Trace.h and is referenced from MyUSBDriverUMDFCreateDevice in Device.c. When you create your project with the name 'MyUSBDriver_UMDF_', Visual Studio 2019 defines the device interface GUID with the name GUID_DEVINTERFACE_MyUSBDriver_UMDF_ but calls WdfDeviceCreateDeviceInterface with the incorrect parameter 'GUID_DEVINTERFACE_MyUSBDriverUMDF'. Replace the incorrect parameter with the name defined in Trace.h to ensure that the driver builds properly.
5. From the Build menu, click Build Solution.

For more information, see Building a Driver.

Step 4: Configure a computer for testing and debugging

To test and debug a driver, you run the debugger on the host computer and the driver on the target computer. So far, you have used Visual Studio on the host computer to build a driver. Next you need to configure a target computer. To configure a target computer, follow the instructions in Provision a computer for driver deployment and testing.

Step 5: Enable tracing for kernel debugging

The template code contains several trace messages (TraceEvents) that can help you track function calls. All functions in the source code contain trace messages that mark the entry and exit of a routine. For errors, the trace message contains the error code and a meaningful string. Because WPP tracing is enabled for your driver project, the PDB symbol file created during the build process contains trace message formatting instructions. If you configure the host and target computers for WPP tracing, your driver can send trace messages to a file or the debugger.

To configure your host computer for WPP tracing

1. Create trace message format (TMF) files by extracting trace message formatting instructions from the PDB symbol file.

   You can use Tracepdb.exe to create TMF files. The tool is located in the <install folder>Windows Kits10bin<architecture> folder of the WDK. The following command creates TMF files for the driver project.

   tracepdb -f [PDBFiles] -p [TMFDirectory]

   The -f option specifies the location and the name of the PDB symbol file. The -p option specifies the location for the TMF files that are created by Tracepdb. For more information, see Tracepdb Commands.

   At the specified location you'll see three files (one per .c file in the project). They are given GUID file names.

2. In the debugger, type the following commands:

These commands:

• Load the Wmitrace.dll extension.
• Verfies that the debugger extension is loaded.
• Adds the location of the TMF files to the debugger extension's search path.

The output resembles this:

To configure your target computer for WPP tracing

1. Make sure you have the Tracelog tool on your target computer. The tool is located in the <install_folder>Windows Kits10Tools<arch> folder of the WDK. For more information, see Tracelog Command Syntax.
2. Open a Command Window and run as administrator.
3. Type the following command:

The command starts a trace session named MyTrace.

The guid argument specifies the GUID of the trace provider, which is the client driver. You can get the GUID from Trace.h in the Visual Studio 2019 project. As another option, you can type the following command and specify the GUID in a .guid file. The file contains the GUID in hyphen format:

You can stop the trace session by typing the following command:

Drivers Wiquest Usb Devices Dongle

Step 6: Deploy the driver on the target computer

1. In the Solution Explorer window, select and hold (or right-click) the <project name>Package , and choose Properties.
2. In the left pane, navigate to Configuration Properties > Driver Install > Deployment.
3. Check Enable deployment, and check Import into driver store.
4. For Remote Computer Name, specify the name of the target computer.
5. Select Install and Verify.
6. Select Ok.
7. On the Debug menu, choose Start Debugging, or press F5 on the keyboard.

Note

Do not specify the hardware ID of your device under Hardware ID Driver Update. The hardware ID must be specified only in your driver's information (INF) file.

Step 7: View the driver in Device Manager

1. Enter the following command to open Device Manager.

   devmgmt

2. Verify that Device Manager shows the following node.

   USB Device

   MyUSBDriver_UMDF_Device

Step 8: View the output in the debugger

Verify that trace messages appear in the Debugger Immediate Window on the host computer.

The output should be similar to the following:

Remarks

Let’s take a look at how the framework and the client driver work together to interact with Windows and handle requests sent to the USB device. This illustration shows the modules loaded in the system for a UMDF -based USB client driver.

The purpose of each module is described here:

• Application—a user-mode process that issues I/O requests to communicate with the USB device.
• I/O Manager—a Windows component that creates I/O request packets (IRPs) to represent the received application requests, and forwards them to the top of the kernel-mode device stack for the target device.
• Reflector—a Microsoft-provided kernel-mode driver installed at the top of the kernel-mode device stack (WUDFRd.sys). The reflector redirects IRPs received from the I/O manager to the client driver host process. Upon receiving the request, the framework and the client driver handle the request.
• Host process —the process in which the user-mode driver runs (Wudfhost.exe). It also hosts the framework and the I/O dispatcher.
• Client driver—the user-mode function driver for the USB device.
• UMDF—the framework module that handles most interactions with Windows on the behalf of the client driver. It exposes the user-mode device driver interfaces (DDIs) that the client driver can use to perform common driver tasks.
• Dispatcher—mechanism that runs in the host process; determines how to forward a request to the kernel mode after it has been processed by user-mode drivers and has reached the bottom of the user-mode stack. In the illustration, the dispatcher forwards the request to the user-mode DLL, Winusb.dll.
• Winusb.dll—a Microsoft-provided user-mode DLL that exposes WinUSB Functions that simplify the communication process between the client driver and WinUSB (Winusb.sys, loaded in kernel mode).
• Winusb.sys—a Microsoft-provided driver that is required by all UMDF client drivers for USB devices. The driver must be installed below the reflector and acts as the gateway to the USB driver stack in the kernel-mode. For more information, see WinUSB.
• USB driver stack—a set of drivers, provided by Microsoft, that handle protocol-level communication with the USB device. For more information, see USB host-side drivers in Windows.

Whenever an application makes a request for the USB driver stack, the Windows I/O manager sends the request to the reflector, which directs it to client driver in user mode. The client driver handles the request by calling specific UMDF methods, which internally call WinUSB Functions to send the request to WinUSB. Upon receiving the request, WinUSB either processes the request or forwards it to the USB driver stack.

Related topics

Understanding the UMDF template code for USB client driver
How to enable USB selective suspend and system wake in the UMDF driver for a USB device
Getting started with USB client driver development

Starting with Windows 10, release 1703, a USB Audio 2.0 driver is shipped with Windows. It is designed to support the USB Audio 2.0 device class. The driver is a WaveRT audio port class miniport. For more information about the USB Audio 2.0 device class, see https://www.usb.org/documents?search=&type%5B0%5D=55&items_per_page=50.

The driver is named: usbaudio2.sys and the associated inf file is usbaudio2.inf.

The driver will identify in device manager as 'USB Audio Class 2 Device'. This name will be overwritten with a USB Product string, if it is available.

The driver is automatically enabled when a compatible device is attached to the system. However, if a third-party driver exists on the system or Windows Update, that driver will be installed and override the class driver.

Architecture

usbaudio2.sys fits within the wider architecture of Windows USB Audio as shown.

Related USB specifications

The following USB specifications define USB Audio and are referenced in this topic.

• USB-2 refers to the Universal Serial Bus Specification, Revision 2.0
• ADC-2 refers to the USB Device Class Definition for Audio Devices, Release 2.0.
• FMT-2 refers to the Audio Data Formats specification, Release 2.0.

The USB-IF is a special interest group that maintains the Official USB Specification, test specifications and tools.

Audio formats

The driver supports the formats listed below. An alternate setting which specifies another format defined in FMT-2, or an unknown format, will be ignored.

Type I formats (FMT-2 2.3.1):

• PCM Format with 8..32 bits per sample (FMT-2 2.3.1.7.1)
• PCM8 Format (FMT-2 2.3.1.7.2)
• IEEE_FLOAT Format (FMT-2 2.3.1.7.3)

Type III formats (FMT-2 2.3.3 and A.2.3):

• IEC61937_AC-3
• IEC61937_MPEG-2_AAC_ADTS
• IEC61937_DTS-I
• IEC61937_DTS-II
• IEC61937_DTS-III
• TYPE_III_WMA

Feature descriptions

This section describes the features of the USB Audio 2.0 driver.

Audio function topology

The driver supports all entity types defined in ADC-2 3.13.

Each Terminal Entity must have a valid clock connection in compatible USB Audio 2.0 hardware. The clock path may optionally include Clock Multiplier and Clock Selector units and must end in a Clock Source Entity.

The driver supports one single clock source only. If a device implements multiple clock source entities and a clock selector, then the driver will use the clock source that is selected by default and will not modify the clock selector’s position.

A Processing Unit (ADC-2 3.13.9) with more than one input pin is not supported.

An Extension Unit (ADC-2 3.13.10) with more than one input pin is not supported.

Cyclic paths in the topology are not allowed.

Audio streaming

The driver supports the following endpoint synchronization types (USB-2 5.12.4.1):

• Asynchronous IN and OUT
• Synchronous IN and OUT
• Adaptive IN and OUT

For the asynchronous OUT case the driver supports explicit feedback only. A feedback endpoint must be implemented in the respective alternate setting of the AS interface. The driver does not support implicit feedback.

There is currently limited support for devices using a shared clock for multiple endpoints.

For the Adaptive IN case the driver does not support a feedforward endpoint. If such an endpoint is present in the alternate setting, it will be ignored. The driver handles the Adaptive IN stream in the same way as an Asynchronous IN stream.

The size of isochronous packets created by the device must be within the limits specified in FMT-2.0 section 2.3.1.1. This means that the deviation of actual packet size from nominal size must not exceed +/- one audio slot (audio slot = channel count samples).

Descriptors

An audio function must implement exactly one AudioControl Interface Descriptor (ADC-2 4.7) and one or more AudioStreaming Interface Descriptors (ADC-2 4.9). A function with an audio control interface but no streaming interface is not supported.

The driver supports all descriptor types defined in ADC-2, section 4. The following subsections provide comments on some specific descriptor types.

Class-Specific AS interface descriptor

For details on this specification, refer to ADC-2 4.9.2.

Drivers Wiquest Usb Devices Pc Camera

An AS interface descriptor must start with alternate setting zero with no endpoint (no bandwidth consumption) and further alternate settings must be specified in ascending order in compatible USB Audio 2.0 hardware.

An alternate setting with a format that is not supported by the driver will be ignored.

Each non-zero alternate setting must specify an isochronous data endpoint, and optionally a feedback endpoint. A non-zero alternate setting without any endpoint is not supported.

The bTerminalLink field must refer to a Terminal Entity in the topology and its value must be identical in all alternate settings of an AS interface.

The bFormatType field in the AS interface descriptor must be identical to bFormatType specified in the Format Type Descriptor (FMT-2 2.3.1.6).

For Type I formats, exactly one bit must be set to one in the bmFormats field of the AS interface descriptor. Otherwise, the format will be ignored by the driver.

To save bus bandwidth, one AS interface can implement multiple alternate settings with the same format (in terms of bNrChannels and AS Format Type Descriptor) but different wMaxPacketSize values in the isochronous data endpoint descriptor. For a given sample rate, the driver selects the alternate setting with the smallest wMaxPacketSize that can fulfill the data rate requirements.

Type I format type descriptor

For details on this specification, refer to FMT-2 2.3.1.6.

The following restrictions apply:

Class-Specific AS isochronous audio data endpoint descriptor

For details on this specification, refer to ADC-2 4.10.1.2.

The MaxPacketsOnly flag in the bmAttributes field is not supported and will be ignored.

The fields bmControls, bLockDelayUnits and wLockDelay will be ignored.

Class requests and interrupt data messages

The driver supports a subset of the control requests defined in ADC-2, section 5.2, and supports interrupt data messages (ADC-2 6.1) for some controls. The following table shows the subset that is implemented in the driver.

Additional information on the controls and requests is available in the following subsections.

Clock source entity

For details on this specification, refer to ADC-2 5.2.5.1.

At a minimum, a Clock Source Entity must implement Sampling Frequency Control GET RANGE and GET CUR requests (ADC-2 5.2.5.1.1) in compatible USB Audio 2.0 hardware.

The Sampling Frequency Control GET RANGE request returns a list of subranges (ADC-2 5.2.1). Each subrange describes a discrete frequency, or a frequency range. A discrete sampling frequency must be expressed by setting MIN and MAX fields to the respective frequency and RES to zero. Individual subranges must not overlap. If a subrange overlaps a previous one, it will be ignored by the driver.

A Clock Source Entity which implements one single fixed frequency only does not need to implement Sampling Frequency Control SET CUR. It implements GET CUR which returns the fixed frequency, and it implements GET RANGE which reports one single discrete frequency.

Clock selector entity

For details on this specification, refer to ADC-2 5.2.5.2

The USB Audio 2.0 driver does not support clock selection. The driver uses the Clock Source Entity which is selected by default and never issues a Clock Selector Control SET CUR request. The Clock Selector Control GET CUR request (ADC-2 5.2.5.2.1) must be implemented in compatible USB Audio 2.0 hardware.

Feature unit

For details on this specification, refer to ADC-2 5.2.5.7.

The driver supports one single volume range only. If the Volume Control GET RANGE request returns more than one range, then subsequent ranges will be ignored.

The volume interval expressed by the MIN and MAX fields should be an integer multiple of the step size specified in the RES field.

If a feature unit implements single channel controls as well as a master control for Mute or Volume, then the driver uses the single channel controls and ignores the master control.

Additional Information for OEM and IHVs

OEMs and IHVs should test their existing and new devices against the supplied in-box driver.

There is not any specific partner customization that is associated with the in-box USB Audio 2.0 driver.

This INF file entry (provided in a update to Windows Release 1703), is used to identify that the in-box driver is a generic device driver.

The in-box driver registers for the following compatible IDs with usbaudio2.inf.

See the USB audio 2.0 specification for subclass types.

USB Audio 2.0 Devices with MIDI (subclass 0x03 above) will enumerate the MIDI function as a separate multi-function device with usbaudio.sys (USB Audio 1.0 driver) loaded.

Drivers Wiquest Usb Devices Type C

The USB Audio 1.0 class driver registers this compatible ID with wdma_usb.inf.

And has these exclusions:

An arbitrary number of channels (greater than eight) are not supported in shared mode due to a limitation of the Windows audio stack.

IHV USB Audio 2.0 drivers and updates

For IHV provided third party driver USB Audio 2.0 drivers, those drivers will continue to be preferred for their devices over our in-box driver unless they update their driver to explicitly override this behavior and use the in-box driver.

Audio Jack Registry Descriptions

Starting in Windows 10 release 1703, IHVs that create USB Audio Class 2.0 devices having one or more jacks have the capability to describe these jacks to the in-box Audio Class 2.0 driver. The in-box driver uses the supplied jack information when handling the KSPROPERTY_JACK_DESCRIPTION for this device.

Jack information is stored in the registry in the device instance key (HW key).

The following describes the audio jack information settings in the registry:

<tid> = terminal ID (As defined in the descriptor)

<n> = Jack number (1 ~ n).

Convention for <tid> and <n> is:

Drivers Wiquest Usb Devices Wireless Adapter

• Base 10 (8, 9, 10 rather than 8, 9, a)
• No leading zeros
• n is 1-based (first jack is jack 1 rather than jack 0)

For example:

T1_NrJacks, T1_J2_ChannelMapping, T1_J2_ConnectorType

For additional audio jack information, see KSJACK_DESCRIPTION structure.

These registry values can be set in various ways:

• By using custom INFs which wrap the in-box INF for the purpose to set these values.

• Directly by the h/w device via a Microsoft OS Descriptors for USB devices (see example below). For more information about creating these descriptors, see Microsoft OS Descriptors for USB Devices.

Microsoft OS Descriptors for USB Example

The following Microsoft OS Descriptors for USB example contains the channel mapping and color for one jack. The example is for a non-composite device with single feature descriptor.

The IHV vendor should extend it to contain any other information for the jack description.

Troubleshooting

If the driver does not start, the system event log should be checked. The driver logs events which indicate the reason for the failure. Similarly, audio logs can be manually collected following the steps described in this blog entry. If the failure may indicate a driver problem, please report it using the Feedback Hub described below, and include the logs.

Examples Of Usb Devices

For information on how to read logs for the USB Audio 2.0 class driver using supplemental TMF files, see this blog entry. For general information on working with TMF files, see Displaying a Trace Log with a TMF File.

For information on 'Audio services not responding' error and USB audio device does not work in Windows 10 version 1703 see, USB Audio Not Playing

Feedback Hub

Drivers Wiquest Usb Devices Dongle

If you run into a problem with this driver, collect audio logs and then follow steps outlined in this blog entry to bring it to our attention via the Feedback Hub.

Driver development

This USB Audio 2.0 class driver was developed by Thesycon and is supported by Microsoft.

See also