FAQ – USB Drivers and Devices

Why I can no longer sign Windows kernel-mode drivers with a vendor certificate (Windows 7)?

Signing kernel-mode drivers with a vendor certificate issued by one of the commercial CAs requires a cross certificate issued by Microsoft. As of July 1, 2021 Microsoft discontinuous cross signing. This affects Windows 7 and 8/8.1 as these systems require a cross-signed driver. Windows 10 and 11 are not affected as drivers are to be attestation signed.

Consequently, any kernel-mode driver released for Windows 7/8/8.1 after July 1, 2021 requires WHQL signing (aka HLK/HCK). Driver packages created and digitally signed before July 1, 2021 continue to work.

Why do I need a USB Vendor ID and USB Product ID?

Every shipping USB product is uniquely identified by a tuple of two 16-bit integer numbers: vendor ID (VID) and product ID (PID). Each number ranges from zero to 65536 (0x0000 to 0xFFFF). A USB device reports these numbers through its device descriptor in the fields idVendor and idProduct.

Operating systems (Windows, macOS, Linux) use the VID/PID tuple to locate the matching device driver, and to store device-specific configuration information (e.g. last volume set for a given device instance). Software applications such as configuration tools, firmware upgrade utilities, etc. typically rely on the VID/PID tuple to identify the device they have been designed for.

On Windows, any vendor-specific USB device driver will be loaded based on VID/PID identification. So a unique VID/PID tuple is essential for the operating system to locate the correct device driver.

If two different products share the same VID/PID tuple then an operating system will potentially load the wrong device driver, and another product's applications and utilities will possibly try to communicate with the device, perform a firmware update etc. This will lead to bad user experience and, in a worst-case scenario, can damage the device.

Hence it is mandatory to ensure that a unique VID/PID tuple is assigned to every distinct USB device type (model) that is shipping. Details on how VID and PID assignment is done in practice are given in the following sections.

Vendor ID (VID)

The Vendor ID is globally unique and typically identifies the manufacturer or distributor of the device. To ensure uniqueness globally, VIDs are managed and assigned by the USB Implementers Forum organization (http://www.usb.org). To receive a VID, you have to contact the USB Implementers Forum, see http://www.usb.org/developers/vendor/.

Any shipping product must use the official VID assigned by the USB Implementers Forum to the product's manufacturer.

In some cases it is possible to use the VID of a silicon vendor. However, this requires registration with the silicon manufacturer or distributor to receive a unique PID. Never re-use the VID/PID of an evaluation board or reference design!

Thesycon allows licensees to use the VID registered for Thesycon. This requires registration with Thesycon because Thesycon manages the PID range and needs to assign a unique PID.

Product ID (PID)

The owner of a VID manages the corresponding PID range. PIDs can be assigned arbitrarily but need to be chosen in such a way that every shipping USB product uses a unique VID/PID tuple. Make sure you choose a unique PID for each new device model and carefully keep records on PID assignments.

How to get unique VID and PID identifiers for a (planned) USB product?

There are several ways to receive a unique USB VID and PID:

1) Register with the USB Implementers Forum (http://www.usb.org) to receive a unique VID (charges apply), see http://www.usb.org/developers/vendor/. Then assign a unique PID for each product.

2) For licensees, Thesycon offers PIDs from Thesycon’s officially registered VID space. This service is free of charge.

3) Some silicon manufactures provide customers with unique PID assignments within their officially registered VID space.

Why do I have to customize a device driver provided by Thesycon?

Thesycon provides generic device drivers which cannot be used directly. Before the driver can be used with a specific USB device and shipped as part of a product, it needs to be customized. The customization procedure includes:

choosing unique file names for all driver files
creation of setup information (.inf files) for driver installation
creation of .cat files required for driver installation
digital code signing of .cat files

Note that the customization procedure does not modify the driver binary executable files (.sys, .dll) itself. The executable files are created and shipped by Thesycon and will not be modified afterwards.

Customization is a mandatory step. Any shipping driver package must be a fully customized driver package. Otherwise, there is a risk that name clashes, ambiguities or other conflicts occur when the driver is used in the field. This is because Thesycon’s drivers are shipped with many different products and there is a chance that an end user installs two (or more) of such products on the same Windows system. If every product uses a fully customized driver then multiple products can be installed and used in parallel without causing conflicts.

Why does Thesycon not allow using the licensed driver with USB VID/PID identifiers from a silicon manufacturer's evaluation board?

Our policy is not to license drivers for devices that reuse VID/PID identifiers from silicon manufacturers and which are typically used for microcontroller evaluation boards or similar. There are several reasons for this decision:

The driver (or its license data record) could be hijacked by other vendors which reuse the same identifiers from evaluation boards but do not own a driver license.
People could use the driver with evaluation boards while experimenting with firmware.
If the officially licensed driver is published via Windows Update servers (which is an optional step), Windows assigns it a higher priority than other drivers and will install it automatically when an evaluation board or another device with the same VID/PID is connected.

Any of these scenarios can cause unexpected behavior and create unwanted support efforts for Thesycon or the official licensee.

Conclusion: USB VID/PID identifiers must unambiguously identify a given device model. Reusing VID/PID identifiers from a silicon manufacturer's evaluation board creates ambiguity and a risk for bad user experience in the field. Also it makes unauthorized use of intellectual properties easier.

How to get an official USB VID, see section How to get unique VID and PID identifiers for a (planned) USB product?

Why should I use unique VID/PID identifiers for a Linux Gadget based product?

For a Linux based device, USB Gadget provides an easy way for implementing USB device functionality. The Gadget software stack comes with pre-configured VID and PID values. If a Gadget based USB device has to work with a vendor-specific device driver on Windows then the default values have to be replaced by unique VID/PID identifiers. This is because Windows locates vendor-specific drivers based on VID/PID identification. See also Why do I need a USB Vendor ID and USB Product ID?

Note that a USB device driver licensed from Thesycon, after customization, will be treated as a vendor-specific device driver by Windows.

Tip: You can check the VID/PID values implemented in your Gadget device by using: Thesycon’s USB descriptor dumper tool.

What is the difference between code signing and Windows Logo Signing (WHQL)?

Kernel Mode Code Signing Overview

The 64-bit (x64) variants of Windows require that any kernel-mode component contains a digital cryptographic signature created with a so called kernel-mode code signing certificate. If there is no such signature or the respective certificate is not valid, Windows will not load the driver. A code signing certificate is issued to a particular entity (enterprise or individual). So if a given driver package has a valid signature, an end user can be sure that this software has been released by that entity, and that the software was not altered since it was released. Basically, this is a good thing and therefore Thesycon recommends to digitally sign all driver files before they are released, irrespectively whether the driver is for use on x64 Windows or not.

Note that code signing is not to be confused with Windows Logo testing (sometimes also called WHQL, HLK, HCK, or Windows Hardware Certification). For code signing no specific logo testing is required and no test results need to be submitted to Microsoft. Code signing does not verify driver or device functionality in any way.

Depending on the target operating system (i.e. the system where the driver is to be installed by end users) there is one of two digital signature variants required:

Vendor signing: for Windows 7, 8 and 8.1
Attestation signing: for Windows 10 and Windows 11

Vendor Signing (Windows 7/8/8.1)

To create a vendor signature, you need to buy a code signing certificate from one of the established authorities. Please refer to the Microsoft article Get a code signing certificate.

While a standard code signing certificate is sufficient for kernel-mode drivers on Windows 7, Windows 8 and Windows 8.1, Thesycon recommends buying an extended validation (EV) code signing certificate. This is because an EV certificate is needed to perform Microsoft attestation signing as required for Windows 10 and Windows 11.

Microsoft Attestation Signing (Windows 10 and 11)

Windows 10 requires that a kernel-mode driver is digitally signed by Microsoft using a code signing certificate that is owned by Microsoft.

Note that the attestation signing requirement is enforced only by Windows 10 version 1607 and later, and only under specific circumstances such as UEFI secure boot set to ON. For more details on attestation signing enforcement, you may refer to the article Driver Signing Policy.

Windows Logo Signing (WHQL)

As an alternative to code signing you can execute the Windows hardware and driver certification process. This requires that you run extensive driver tests using the Windows Hardware Lab Kit (HLK) and submit test results to Microsoft. If the driver and the device pass certification then Microsoft digitally signs the driver with a WHQL publisher certificate.

Note that Thesycon offers WHQL certification as a service. For more information or to request a quote, please contact Thesycon.

Why does Windows 7 not accept my signed driver?

In Windows 7 there are some issues with SHA-256 code signing certificates as described in the following subsections.

Windows 7 requires hotfix to accept SHA-256 code signature

Operating systems: Windows 7 32/64 bit

Problem description: By default, Windows 7 does not accept SHA-256 code signatures, it accepts SHA-1 signatures only. However, SHA-1 based certificates are deprecated and not available any longer. All recent code singing certificates use the SHA-256 algorithm.

Microsoft has released a hotfix that adds support for SHA-256 certificates on Windows 7. The hotfix KB3033929 can be found here: https://support.microsoft.com/en-us/kb/3033929

Note that KB3033929 is available through Windows update. So the easiest solution is to make sure this update is installed.

Additional information:This problem does not exist on Windows 8 and later. If the Thesycon driver installer (v1.12 and later) is used then setup.exe detects this problem during driver installation and shows an error message which references the KB3033929 patch.

Untrusted Publisher pop-up dialog appears on Windows 7

Operating systems: Windows 7 32/64 bit

Problem description: Normally, Thesycon’s driver installer suppresses the "Untrusted publisher" dialog box. However, if the driver that is installed is signed with a SHA-256 code signing certificate then Windows 7 may still show this dialog box. Although you selected the "Always trust" option, the dialog box may reappear during a subsequent driver installation.

This is an issue in Windows 7. For more information and a hotfix, check out KB2921916: https://support.microsoft.com/en-us/kb/2921916

Additional information: KB2921916 is not available through Windows update.

TUSBAudio DFU vs. TL-USBDFU - What's the difference?

Thesycon’s USB audio class driver TUSBAudio comes with integrated Device Firmware Upgrade (DFU) support. But it works on Windows only. If you are looking for a cross-platform DFU solution which works on Windows and macOS. Both DFU solutions support devices which implement the DFU v1.1 specification, and devices which are based on the XMOS firmware framework which uses some DFU protocol extensions.
If you are designing a new device which has to support Windows and macOS, Thesycon recommends that you follow the DFU v1.1 specification and use TL-USBDFU. For more information please contact Thesycon.

What's the purpose of the static COM port feature in the TL-USBCOM driver?

Some legacy applications are not able to handle COM ports which appear and disappear dynamically when the USB cable is plugged or unplugged. Such applications assume that a COM port is a static resource which is always available. To support such legacy applications, TL-USBCOM driver provides a special feature which emulates the behavior of a legacy static COM port.

It's important to understand that the static COM port feature is a work-around for legacy application behavior. It should be used only if all of the following conditions apply:

The application opens a handle for the COM port and keeps it open while it is running.
The application does not react on COM port removal/arrival notifications to close and reopen handles as required.
After a COM port disappears because the USB device has been unplugged, the entire application must be closed and restarted to make communication work again, but such an application restart is not acceptable in the given scenario.
The application cannot be modified to support dynamic COM port handling based on device removal/arrival events.

Static COM port behavior is optional and needs to be enabled via driver configuration settings. Contact Thesycon for more information.