There are class drivers and then there are class filter drivers

  • Article

This came up recently on the newsgroups. The term "class driver" can mean a couple
of different things, depending on the context.

First, there are class filter drivers. These drivers
are loaded based on the device's installed device class.
This is the same device class that you specify in your INF when you install the device. These
drivers are loaded by the registry value named "UpperFilters" or "LowerFilters". Each
class, as specified by a GUID, has its own set of these values. These classes can be found in
the registry HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Class.

Let's take the keyboard class as an example. In your INF which installs a keyboard,
you have the following:

 
    Class=Keyboard
    ClassGUID={4D36E96B-E325-11CE-BFC1-08002BE10318}

so the corresponding class key for the keyboard device class is
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E96B-E325-11CE-BFC1-08002BE10318}. Under this key we
see the following value:

 
    "UpperFilters" : REG_MULTI_SZ : "kbdclass"

From this, we can conclude that kbdclass is a class filter driver. Other examples
of class filter drivers are mouclass (for mice) and irenum (for infrared devices).

The other type of class driver is a driver which implements a certain class
specification for a particular type of device. This type of driver is usually
written by Microsoft and will be the default in box driver for the type of device
the driver controls. So in this case, class refers to the specification class
of the device, not the device's class as specified by an INF. Typically the class
driver is installed based off of a compatible ID for the device rather then a hardware ID.
Examples of class
drivers in Windows are hidusb (USB HID device), bthusb (Bluetooth HID device), usbstor (USB
mass storage), usbccid (USB smart card reader), i8042prt (for PS2 mice and keyboards), and serial (COM port). Also, just because a driver may be a class driver does not limit it to being only an FDO, it can also be a bus driver as well if it needs to be.

To tie it all together, let's look at a PS2 keyboard stack and see the class "role" for each device object in the stack

 
+----------+
| kbdclass |  <-- class filter driver
+----------+
     |
+----------+
| i8042prt | <-- class driver (also the FDO)
+----------+
     |
+----------+
|   PDO    |
+----------+

In conclusion, class filter drivers are loaded based on the installed device class (as specified by the INF).
A class driver is typically the FDO in a stack who implements an industry standard
interface to a particular type of device. The difference between the two names
only makes a difference when the device stack is built up. Once the device stack
has been built (e.g. every driver's AddDevice has been called), Windows treats all
devices in the stack the same way.