You are viewing documentation for version: 1.0 | Version History

Microsoft Windows OS USB Host

Microsoft offers class drivers for some standard USB classes. These drivers can also be called native drivers. A complete list of the native drivers can be found in the MSDN online documentation on the page titled USB class drivers included in Windows . If a connected device belongs to a class for which a native driver exists, Windows automatically loads the driver without any additional actions from you. If a vendor-specific driver is required for the device, a manufacturer’s INF file giving instructions to Windows for loading the vendor-specific driver is required. In some cases, a manufacturer’s INF file may also be required to load a native driver.

When the device has been recognized by Windows and is ready for communication, your application may need to use a Globally Unique IDentifier (GUID) to retrieve a device handle that allows your application to communicate with the device.

The following sections explain the use of INF files and GUIDs. The table below shows the USB classes to which the information in the following sub-sections applies.

Table - Classes Concerned by Windows USB Device Management

About INF Files

An INF file is a setup information file that contains information used by Windows to install software and drivers for one or more devices. The INF file also contains information to store in the Windows registry. Each of the drivers provided natively with the operating system has an associated INF file stored in C:\WINDOWS\inf. For instance, when an HID or MSC device is connected to the PC, Windows enumerates the device and implicitly finds an INF file associated to an HID or MSC class that permits loading the proper driver. INF files for native drivers are called system INF files. Any new INF files provided by manufacturers for vendor-specific devices are copied into the folder C:\WINDOWS\inf. These INF files can be called vendor-specific INF files. An INF file allows Windows to load one or more drivers for a device. A driver can be native or provided by the device manufacturer. The table below shows the Windows driver(s) loaded for each USB class

Table - Windows Drivers Loaded for each USB Class

When a device is first connected, Windows searches for a match between the information contained in system INF files and the information retrieved from device descriptors. If there is no match, Windows asks you to provide an INF file for the connected device.

An INF file is arranged in sections whose names are surrounded by square brackets []. Each section contains one or several entries. If the entry has a predefined keyword such as "Class", "Signature", etc, the entry is called a directive. Example - INF File Structure presents an example of an INF file structure.

Example - INF File Structure

; =================== Version section =====================
[Version]                                                                     (1)
Signature = "$Windows NT$"
Class     = Ports
ClassGuid = {4D36E978-E325-11CE-BFC1-08002BE10318}

Provider=%ProviderName%
DriverVer=01/01/2012,1.0.0.0

; ========== Manufacturer/Models sections =================

[Manufacturer]                                                                (2)
%ProviderName% = DeviceList, NTx86, NTamd64

[DeviceList.NTx86]                                                            (3)
%PROVIDER_CDC% = DriverInstall, USB\VID_fffe&PID_1234&MI_00
[DeviceList.NTamd64]                                                          (3)
%PROVIDER_CDC% = DriverInstall, USB\VID_fffe&PID_1234&MI_00

; ================ Installation sections ==================                   (4)

[DriverInstall]
include   = mdmcpq.inf
CopyFiles = FakeModemCopyFileSection
AddReg    = LowerFilterAddReg,SerialPropPageAddReg

[DriverInstall.Services]
include    = mdmcpq.inf
AddService = usbser, 0x00000002, LowerFilter_Service_Inst

[SerialPropPageAddReg]
HKR,,EnumPropPages32,,"MsPorts.dll,SerialPortPropPageProvider"

; ================== Strings section ======================
[Strings]                                                                     (5)
ProviderName = "Silicon Labs"
PROVIDER_CDC = "Silicon Labs CDC Device"

(1) The section [Version] is mandatory and informs Windows about the provider, the version and other descriptive information about the driver package.

(2) The section [Manufacturer] is mandatory. It identifies the device’s manufacturer.

(3) The following two sections are called Models sections and are defined on a per-manufacturer basis. They give more detailed instructions on the driver(s) to install for the device(s). A section name can use extensions to specify OSes and/or CPUs the entries apply to. In this example, .NTx86 and .NTamd64 indicate that the driver can be installed on an NT-based Windows (that is Windows 2000 and later), on x86- and x64-based PC respectively.

(4) The installation sections actually install the driver(s) for each device described in the Model section(s). The driver installation may involve reading existing information from the Windows registry, modifying existing entries of the registry or creating new entries into the registry.

(5) The section [Strings] is mandatory and it is used to define each string key token indicated by %string name% in the INF file.

Refer to the MSDN online documentation on this web page for more details about INF sections and directives.

You will be able to modify some sections in order to match the INF file to your device characteristics, such as Vendor ID, Product ID and human-readable strings describing the device. The sections are:

• Models section
• [Strings] section

To identify possible drivers for a device, Windows looks in the Models section for a device identification string that matches a string created from information in the device’s descriptors. Every USB device has a device ID, that is a hardware ID created by the Windows USB host stack from information contained in the Device descriptor. A device ID has the following form:

USB\Vid_xxxx&Pid_yyyy

xxxx, yyyy, represent the value of the Device descriptor fields "idVendor" and "idProduct" respectively (refer to the Universal Serial Bus Specification, revision 2.0, section 9.6.1 for more details about the Device descriptor fields). This string allows Windows to load a driver for the device. You can modify xxxx and yyyy to match your device’s Vendor and Product IDs.

Composite devices, formed of several functions, can specify a driver for each function. In this case, the device has a device ID for each interface that represents a function. A device ID for an interface has the following form:

USB\Vid_xxxx&Pid_yyyy&MI_ww

ww is equal to the "bInterfaceNumber" field in the Interface descriptor (refer to the Universal Serial Bus Specification, revision 2.0, section 9.6.5 for more details on the Interface descriptor fields). You can modify ww to match the position of the interface in the Configuration descriptor. If the interface has the position #2 in the Configuration descriptor, ww is equals to 02.

The [Strings] section contains a description of your device. In Example - INF File Structure , the strings define the name of the device driver package provider and the device name. You can see these device description strings in the Device Manager.

Using GUIDs

A Globally Unique IDentifier (GUID) is a 128-bit value that uniquely identifies a class or other entity. Windows uses GUIDs for identifying two types of device classes:

• Device setup class
• Device interface class

A device setup GUID encompasses devices that Windows installs in the same way and using the same class installer and co-installers. Class installers and co-installers are DLLs that provide functions related to device installation. There is a GUID associated with each device setup class. System-defined setup class GUIDs are defined in devguid.h. The device setup class GUID defines the ..\CurrentControlSet\Control\Class\ClassGuid registry key under which to create a new subkey for any particular device of a standard setup class. A complete list of system-defined device setup classes offered by Microsoft Windows® is available on MSDN online documentation .

A device interface class GUID provides a mechanism for applications to communicate with a driver assigned to devices in a class. A class or device driver can register one or more device interface classes to enable applications to learn about and communicate with devices that use the driver. Each device interface class has a device interface GUID. Upon a device’s first attachment to the PC, the Windows I/O manager associates the device and the device interface class GUID with a symbolic link name, also called a device path. The device path is stored in the Windows registry and persists across system reboot. An application can retrieve all the connected devices within a device interface class. If the application has gotten a device path for a connected device, this device path can be passed to a function that will return a handle. This handle is passed to other functions in order to communicate with the corresponding device.