Usb Class_ff%26subclass_00%26prot_00 Driver Windows 10
-->
USB CLASS00&SUBCLASS00&PROT00 drivers. Here is 1 driver compatible with USB CLASS00&SUBCLASS00&PROT00. This is Device ID of NetComm USB Port Driver. Here is only last drivers for this DeviceId. Almost all of them are compatible with your hardware. Anyway, you can try to use extended search exactly for your hardware. Dec 19, 2019 USB Class01&SubClass00&Prot20 USB Class01&SubClass01&Prot20 USB Class01&SubClass02&Prot20 USB Class01&SubClass03&Prot20 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.
Important
This topic is for programmers. If you are a customer experiencing USB problems, see Troubleshoot common USB problems
This topic lists the Microsoft-provided drivers for the supported USB device classes.
- Microsoft-provided drivers for USB-IF approved device classes.
- For composite devices, use USB Generic Parent Driver (Usbccgp.sys) that creates physical device objects (PDOs) for each function.
- For non-composite devices or a function of a composite device, use WinUSB (Winusb.sys).
If you are installing USB drivers: You do not need to download USB device class drivers. They are installed automatically. These drivers and their installation files are included in Windows. They are available in the WindowsSystem32DriverStoreFileRepository folder. The drivers are updated through Windows Update.
If you are writing a custom driver: Before writing a driver for your USB device, determine whether a Microsoft-provided driver meets the device requirements. If a Microsoft-provided driver is not available for the USB device class to which your device belongs, then consider using generic drivers, Winusb.sys or Usbccgp.sys. Write a driver only when necessary. More guidelines are included in Choosing a driver model for developing a USB client driver.
USB Device classes
USB Device classes are categories of devices with similar characteristics and that perform common functions. Those classes and their specifications are defined by the USB-IF. Each device class is identified by USB-IF approved class, subclass, and protocol codes, all of which are provided by the IHV in device descriptors in the firmware. Microsoft provides in-box drivers for several of those device classes, called USB device class drivers. If a device that belongs to a supported device class is connected to a system, Windows automatically loads the class driver, and the device functions with no additional driver required.
Hardware vendors should not write drivers for the supported device classes. Windows class drivers might not support all of the features that are described in a class specification. If some of the device's capabilities are not implemented by the class driver, vendors should provide supplementary drivers that work in conjunction with the class driver to support the entire range of functionality provided by the device.
For general information about USB-IF approved device classes see the USB Common Class Specification
The current list of USB class specifications and class codes is documented in the USB-IF Defined Class Code List.
Device setup classes
Windows categorizes devices by device setup classes, which indicate the functionality of the device.
Microsoft defines setup classes for most devices. IHVs and OEMs can define new device setup classes, but only if none of the existing classes apply. For more information, see System-Defined Device Setup Classes.
Two important device setup classes for USB devices are as follows:
USBDevice {88BAE032-5A81-49f0-BC3D-A4FF138216D6}: IHVs must use this class for custom devices that do not belong to another class. This class is not used for USB host controllers and hubs.
USB {36fc9e60-c465-11cf-8056-444553540000}: IHVs must not use this class for their custom devices. This is reserved for USB host controllers and USB hubs.
The device setup classes are different from USB device classes discussed earlier. For example, an audio device has a USB device class code of 01h in its descriptor. When connected to a system, Windows loads the Microsoft-provided class driver, Usbaudio.sys. In Device Manager, the device is shown under is Sound, video and game controllers, which indicates that the device setup class is Media.
Microsoft-provided USB device class drivers
| USB-IF class code | Device setup class | Microsoft-provided driver and INF | Windows support | Description |
|---|---|---|---|---|
| Audio (01h) | Media {4d36e96c-e325-11ce-bfc1-08002be10318} | Usbaudio.sys Wdma_usb.inf | Windows 10 for desktop editions (Home, Pro, Enterprise, and Education) Windows 10 Mobile Windows 8.1 Windows 8 Windows 7 Windows Server 2008 Windows Vista | Microsoft provides support for the USB audio device class by means of the Usbaudio.sys driver. For more information, see 'USBAudio Class System Driver' in Kernel-Mode WDM Audio Components. For more information about Windows audio support, see the Audio Device Technologies for Windows website. |
| Communications and CDC Control (02h) | ||||
| Ports {4D36E978-E325-11CE-BFC1-08002BE10318} | Usbser.sys Usbser.inf | Windows 10 for desktop editions Windows 10 Mobile | In Windows 10, a new INF, Usbser.inf, has been added that loads Usbser.sys automatically as the function driver. For more information, see USB serial driver (Usbser.sys) | |
| Modem {4D36E96D-E325-11CE-BFC1-08002BE10318} Note Supports Subclass 02h (ACM) | Usbser.sys Custom INF that references mdmcpq.inf | Windows 10 for desktop editions Windows 8.1 Windows 8 Windows 7 Windows Server 2008 Windows Vista | In Windows 8.1 and earlier versions, Usbser.sys is not automatically loaded. To load the driver, you need to write an INF that references the modem INF (mdmcpq.inf) and includes [Install] and [Needs] sections. Starting with Windows Vista, you can enable CDC and Wireless Mobile CDC (WMCDC) support by setting a registry value, as described in Support for the Wireless Mobile Communication Device Class. When CDC support is enabled, the USB Common Class Generic Parent Driver enumerates interface collections that correspond to CDC and WMCDC Control Models, and assigns physical device objects (PDO) to these collections. | |
| Net {4d36e972-e325-11ce-bfc1-08002be10318} Note Supports Subclass 0Dh (NCM) | UsbNcm.sys UsbNcm.inf | Windows 11 Windows Server 2022 | Microsoft provides the UsbNcm.sys driver to operate devices that comply with Usb NCM. The source code for this driver is available at NCM-Driver-for-Windows. | |
| Net {4d36e972-e325-11ce-bfc1-08002be10318} Note Supports Subclass 0Eh (MBIM) | wmbclass.sys Netwmbclass.inf | Windows 10 for desktop editions Windows 8.1 Windows 8 | Starting in Windows 8, Microsoft provides the wmbclass.sys driver, for mobile broadband devices. See, MB Interface Model. | |
| HID (Human Interface Device) (03h) | HIDClass {745a17a0-74d3-11d0-b6fe-00a0c90f57da} | Hidclass.sys Hidusb.sys Input.inf | Windows 10 for desktop editions Windows 10 Mobile Windows 8.1 Windows 8 Windows 7 Windows Server 2008 Windows Vista | Microsoft provides the HID class driver (Hidclass.sys) and the miniclass driver (Hidusb.sys) to operate devices that comply with the USB HID Standard. For more information, see HID Architecture and Minidrivers and the HID class driver. For further information about Windows support for input hardware, see the Input and HID - Architecture and Driver Support website. |
| Physical (05h) | - | - | - | Recommended driver: WinUSB (Winusb.sys) |
| Image (06h) | Image {6bdd1fc6-810f-11d0-bec7-08002be2092f} | Usbscan.sys Sti.inf | Windows 10 for desktop editions Windows 8.1 Windows 8 Windows 7 Windows Server 2008 Windows Vista | Microsoft provides the Usbscan.sys driver that manages USB digital cameras and scanners for Windows XP and later operating systems. This driver implements the USB component of the Windows Imaging Architecture (WIA). For more information about WIA, see Windows Image Acquisition Drivers and the Windows Imaging Component website. For a description of the role that Usbscan.sys plays in the WIA, see WIA Core Components. |
| Printer (07h) | USB Note Usbprint.sys enumerates printer devices under the device set up class: Printer {4d36e979-e325-11ce-bfc1-08002be10318}. | Usbprint.sys Usbprint.inf | Windows 10 for desktop editions Windows 8.1 Windows 8 Windows 7 Windows Server 2008 Windows Vista | Microsoft provides the Usbprint.sys class driver that manages USB printers. For information about implementation of the printer class in Windows, see the Printing - Architecture and Driver Support website. |
| Mass Storage (08h) | ||||
| USB | Usbstor.sys | Windows 10 for desktop editions Windows 10 Mobile Windows 8.1 Windows 8 Windows 7 Windows Server 2008 Windows Vista | Microsoft provides the Usbstor.sys port driver to manage USB mass storage devices with Microsoft's native storage class drivers. For an example device stack that is managed by this driver, see Device Object Example for a USB Mass Storage Device. For information about Windows storage support, see the Storage Technologies website. | |
| SCSIAdapter {4d36e97b-e325-11ce-bfc1-08002be10318} | SubClass (06) and Protocol (62) Uaspstor.sys Uaspstor.inf | Windows 10 for desktop editions Windows 10 Mobile Windows 8.1 Windows 8 | Uaspstor.sys is the class driver for SuperSpeed USB devices that support bulk stream endpoints. For more information see: | |
| Hub (09h) | USB {36fc9e60-c465-11cf-8056-444553540000} | |||
| Usbhub.sys Usb.inf | Windows 10 for desktop editions Windows 10 Mobile Windows 8.1 Windows 8 Windows 7 Windows Server 2008 Windows Vista | Microsoft provides the Usbhub.sys driver for managing USB hubs. For more information about the relationship between the hub class driver and the USB stack, see USB host-side drivers in Windows. | ||
| Usbhub3.sys Usbhub3.inf | Windows 10 for desktop editions Windows 8.1 Windows 8 | Microsoft provides the Usbhub3.sys driver for managing SuperSpeed (USB 3.0) USB hubs. The driver is loaded when a SuperSpeed hub is attached to an xHCI controller. See USB host-side drivers in Windows. | ||
| CDC-Data (0Ah) | - | - | - | Recommended driver: WinUSB (Winusb.sys) |
| Smart Card (0Bh) | SmartCardReader {50dd5230-ba8a-11d1-bf5d-0000f805f530} | |||
| Usbccid.sys (Obsolete) | Windows 10 for desktop editions Windows 7 Windows Server 2008 Windows Vista | Microsoft provides the Usbccid.sys mini-class driver to manage USB smart card readers. For more information about smart card drivers in Windows, see Smart Card Design Guide. Note that for Windows Server 2003, Windows XP, and Windows 2000, special instructions are required for loading this driver because it might have been released later than the operating system. Note Usbccid.sys driver has been replaced by UMDF driver, WUDFUsbccidDriver.dll. | ||
| WUDFUsbccidDriver.dll WUDFUsbccidDriver.inf | Windows 8.1 Windows 8 | WUDFUsbccidDriver.dll is a user-mode driver for USB CCID Smart Card Reader devices. | ||
| Content Security (0Dh) | - | - | - | Recommended driver: USB Generic Parent Driver (Usbccgp.sys). Some content security functionality is implemented in Usbccgp.sys. See Content Security Features in Usbccgp.sys. |
| Video (0Eh) | Image {6bdd1fc6-810f-11d0-bec7-08002be2092f} | Usbvideo.sys Usbvideo.inf | Windows 10 for desktop editions Windows Vista | Microsoft provides USB video class support by means of the Usbvideo.sys driver. For more information, see 'USB Video Class Driver' under AVStream Minidrivers. Note that for Windows XP, special instructions are required for loading this driver because it might have been released later than the operating system. |
| Personal Healthcare (0Fh) | - | - | - | Recommended driver: WinUSB (Winusb.sys) |
| Audio/Video Devices (10h) | - | - | - | - |
| Diagnostic Device (DCh) | - | - | - | Recommended driver: WinUSB (Winusb.sys) |
| Wireless Controller (E0h) Note Supports Subclass 01h and Protocol 01h | Bluetooth {e0cbf06c-cd8b-4647-bb8a-263b43f0f974} | Bthusb.sys Bth.inf | Windows 10 for desktop editions Windows 10 Mobile Windows 8.1 Windows 8 Windows 7 Windows Vista | Microsoft provides the Bthusb.sys miniport driver to manage USB Bluetooth radios. For more information, see Bluetooth Design Guide. |
| Miscellaneous (EFh) | Net {4d36e972-e325-11ce-bfc1-08002be10318} Note Supports SubClass 04h and Protocol 01h | Rndismp.sys Rndismp.inf | Windows 10 for desktop editions Windows 8.1 Windows 8 Windows 7 Windows Vista | Note Microsoft recommends that hardware vendors build USB NCM compatible devices instead. USB NCM is a public USB-IF protocol that offers better throughput performance. Prior to Windows Vista, support for CDC was limited to the RNDIS-specific implementation of the Abstract Control Model (ACM) with a vendor-unique protocol (bInterfaceProtocol) value of 0xFF. The RNDIS facility centers the management of all 802-style network cards in a single class driver, Rndismp.sys. For a detailed discussion of remote NDIS, see Overview of Remote NDIS. The mapping of remote NDIS to USB is implemented in the Usb8023.sys driver. For further information about networking support in Windows, see Networking and Wireless Technologies. |
| Application Specific (FEh) | - | - | - | Recommended driver: WinUSB (Winusb.sys) |
| Vendor Specific (FFh) | - | - | Windows 10 for desktop editions Windows 10 Mobile | Recommended driver: WinUSB (Winusb.sys) |
Related topics
-->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.
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:
| Format | Subslot size | Bit resolution |
|---|---|---|
| Type I PCM format: | 1 <= bSubslotSize <= 4 | 8 <= bBitResolution <= 32 |
| Type I PCM8 format: | bSubslotSize 1 | bBitResolution 8 |
| Type I IEEE_FLOAT format: | bSubslotSize 4 | bBitResolution 32 |
| Type III IEC61937 formats: | bSubslotSize 2 | bBitResolution 16 |
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.
| Entity | Control | GET CUR | SET CUR | GET RANGE | INTERRUPT |
|---|---|---|---|---|---|
| Clock Source | Sampling Frequency Control | x | x | x | |
| Clock Selector | Clock Selector Control | x | |||
| Clock Multiplier | Numerator Control | x | |||
| Denominator Control | x | ||||
| Terminal | Connector Control | x | x | ||
| Mixer Unit | Mixer Control | x | x | x | |
| Selector Unit | Selector Control | x | x | ||
| Feature Unit | Mute Control | x | x | x | |
| Volume Control | x | x | x | x | |
| Automatic Gain Control | x | x | |||
| Effect Unit | – | ||||
| Processing Unit | – | ||||
| Extension Unit | – |
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.
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:
- 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
Usb Vid_05ad&pid_0fba&rev_0300 Windows 10 Driver
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.
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
USB Driver Installation Windows 10
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.