How does USB device recognition work?

The USB bus is physically designed so that the act of inserting (and removing) a plug can be recognized by the host controller. When this "plug" event happens, the host controller informs its device driver which scans the bus and asks each device to identify itself.

All USB devices contain a collection of information about the device, called the descriptors. Device descriptors are retrieved from all devices with the same command. This allows a device driver for the USB bus itself to effectively ask a newly connected device what it is, and expect to get a reasonable response.

Of all the descriptors, only a few are directly used to match drivers to most devices. This is because USB defines classes of devices, and usually the system driver for each device class is sufficient to handle any devices that claim to be in that class.

All keyboards will claim to be in the HID (Human Interface) class, as will mice, tablets, and game controllers, for example. The HID class has several subclasses (keyboards, mice, etc.), so each gets handled in the expected way.

Most disk-like devices will claim to be in the Mass Storage class, and the system driver just works for those as well.

In addition to the class and subclass, the descriptors also include a vendor ID (VID), product ID (PID), and revision. The vendor IDs are assigned by the standards committee (mostly in order of issue but some companies got special requests: intel is 0x8086, for example). Product IDs are assigned by each vendor, and the combination of VID and PID must be unique to each released product.

When a device is first installed, the VID, PID, revision, class and subclass are used in a predictable way to choose the device driver that is loaded. Having vendor and product specific names makes it possible for a vendor to customize a device that might otherwise be handled (nearly) correctly by the stock system driver.

Another important descriptor is the device serial number. If a device has a serial number, then it can be recognized and treated the same when plugged in again even if a different physical USB port is used. This is important for storage devices so that they get the same drive letter assigned, and for devices like serial port adapters and modems so that they are given the same COM port designation.

This whole process is documented at MSDN, but the details are spread out among a variety of places.

Questions :

• Directories : Drivers are installed into 2 directories. The running part gets (in most cases) installed into %RootDir%\system32, the device information part gets installed into %RootDir%\inf. Under the inf dir, for a installed/registered driver an oem*.inf file is created. (* is a number). Under Vista the driver gets copied into the %RootDir%\system32\driverstore directory as a reference when installing not yet encountered devices.
• Registry : A driver gets installed as a kernel mode service. For this certain registry keys are created for the driver service. There is another place under the bus driver, where the corresponding devices get an individual device instance key. In this key, the device has a reference to the currently used driver for this device.
• Device 'arrival' : When the bus driver finds a new device on its bus, it creates a key registry under its own key which correspondents to a unique device instance id, which can be used to uniquely identify a device on the system. If this key already exists, the bus driver tries to load the device referenced by this node. When this node does not exist, or the driver does not load, the system tries to find a compatible driver for the device, by scanning the registered device drivers under %RootDir%\inf. The drivers that qualify for this device, get enumerated and sorted. The best driver is then selected and loaded for the device.
• Driver search : Drivers are searched first in the inf directory. When no driver is found, windows ask the user, if he can provide drivers or if it should look on the Microsoft server. Driver Manufacturers may submit their drivers for inclusion on the Microsoft device driver server.

Lunatik has the first part of the answer, how the so called bus driver finds the device.

I would like to recommend a good book about usb:

• USB Complete by Jan Axelson

I know that you did not ask for this, but it is good to know a little about the usb devices that are supposed to connect.