Managing Windows Device Drivers

Love ‘em or hate ‘em; there’s no getting away from the need for device drivers in Windows. Simply put, device drivers bridge the gap between hardware, the operating system (OS), and applications on Windows. Thus, they are absolutely necessary to make a PC work, especially for key input devices like mice and keyboards, and key output devices like your display.

A jaundiced look at the history of Windows could incline readers to think that it has been distancing applications from hardware ever since the earliest versions of the OS appeared in 1985. Starting with versions in the 1990s (particularly 3.0 and 3.1x), Microsoft has sought to get the OS between applications and hardware. Though conspiracy theorists might see malign forces at work, I believe Microsoft’s motives are entirely benign: the OS design seeks to emphasize simplicity, security, and broad capability. The forces at work have been deliberately designed to lower the burden on driver developers, and to let Microsoft carry as much of the load as possible in mediating between the OS and the hardware on which it runs.

A Basic Device Driver Definition

In its November 2022 Microsoft Learn article What is a driver? Microsoft asserts that “a driver is a software component that lets the operating system and a device communicate.” Note the emphasis on the OS part here: Microsoft puts the OS squarely between the hardware on one side of the communications chain and applications running inside the OS on the other side of that chain.

This blurs the distinction between OS tools and utilities (think of the Settings app or File Explorer, for example) and third-party applications (think of something like Discord, Chrome, Spotify or Netflix). This is a good thing because all of them need similar capabilities. That is, they need access to the display for output, keyboard and mouse for input, the Internet to interact with remote resources, and storage to read and write files, and so forth and so on.

Ultimately, device drivers are a terrific abstraction tool. That is, they let developers push the burden of device communications and interactions onto somebody else (mostly Microsoft, as it turns out) in exchange for working with OS-mediated tools to read inputs and write outputs in general. This does put limits on what developers can do. Also, it definitely prescribes how they must do things that are allowed. But this is a classic engineering trade-off that the Genie in Aladdin correctly but humorously described as “Phenomenal cosmic power! Itty bitty living space.” That is, developers can do incredible things (including with devices), but they must do them in precisely defined and narrowly circumscribed ways. That’s the “Genie trade-off” that drivers impose, in the interests of letting developers focus on their applications rather than all the other stuff – including device interactions – that happen along the way.

A More Nuanced Driver Definition

Even Microsoft admits that it’s hard to jump from the basic definition of device drivers to something more nuanced and accurate. In the What is…? item cited earlier, Microsoft talks about the basic definition as “oversimplified” for good reasons. In particular, it cites a “driver stack” of software components that works together to move communications between the OS and devices. It describes that stack (see Figure 1) by saying:

Some drivers in the stack change the request from one format to another. These drivers don't communicate directly with the device. Instead, they change the request and pass it to drivers that are lower in the stack.

As you can see in Figure 1, two intermediate drivers (labeled Driver 1 and Driver 2), called filter drivers, sit between the Windows OS and the bottom of the driver stack (Driver 3), called a function driver. The latter is the only driver in the stack that communicates directly with the device (bottom right). The filter drivers perform “auxiliary processing” that can include format or protocol conversion, I/O traffic monitoring, I/O staging and forwarding, and more. See the Microsoft Learn article Driver stacks for all the gory details: it shows how four device stacks—for USB host controllers, USB root hubs, USB mass storage devices, and a specific USB storage device—all play into moving I/O between Windows and a USB-attached flash drive, for example.

This is heady stuff. It also shows how drivers come in hierarchies, such as USB with its host controllers, root hubs, and so forth that can quickly grow the number of layers in the driver stack to surprising depths. In fact, a quick look at Windows devices through the lens of the built-in Device Manager tool in Figure 2 shows three categories for USB devices: devices, controllers, and connector managers, all at the top level of the device hierarchy.

Why Some Windows Drivers Bear This Date: 6/21/2006

As shown in Figure 2, Windows (Windows 11, on the underlying PC) Device Manager divides devices up into categories by type or kind (in alphabetical order by category name). At the top you see audio stuff, followed by batteries, biometric devices, and so forth, all the way down to USB stuff and the WSD Print Provider (Web Services for Devices, a way to access networked printers and devices using the Internet Protocol, or IP).

If you click the right-caret symbol to the left of any category, it will expand, as shown in Figure 3, with the Bluetooth item expanded to show one physical Intel device and various virtual devices that serve as filter drivers in the Bluetooth part of the driver stack.

Three of the four devices shown within the Bluetooth category are virtual devices that Microsoft builds for Windows as part of its OS support for Bluetooth. These include the two items that start with Microsoft and the item that starts with Bluetooth Device. By right-clicking that entry, then selecting Properties from the drop-down menu that appears, you can see the Properties page for that device. It appears in Figure 4 with the Driver tab selected (second from left).

As you can see in Figure 4, the Driver Date value reads “6/21/2006” and the Driver Provider name is “Microsoft.” These are telling and useful bits of information. The date matches the release to manufacturing (RTM, or official release) for Windows Vista. The provider indicates that this driver comes from Microsoft, not a third party. (As I said earlier, it’s part of the Bluetooth support infrastructure that Microsoft supplies with Windows to benefit device makers, software developers, and users alike.)

When Microsoft supplies a driver for some non-Microsoft device, it uses this date. Because the driver matching algorithm that is used to update drivers includes the date and the version number as part of its driver selection process, using this date more or less guarantees that if a third-party alternative is available, it will also bear a newer date. Thus, the third-party alternative would be selected for installation and use. The idea is for Windows to install the best possible driver for any device it finds. In my experience, and based on my research, this approach works 99% of the time (or better).

The Microsoft Driver Footprint Is HUGE

As an experiment, I wrote a Windows PowerShell script (with some help from Microsoft Copilot) to count the total number of Windows drivers, and then to determine how many drivers carry the 6/21/2006 date. The results were remarkably consistent across Windows 10 and Windows 11 physical PCs and virtual machines (VMs). First, I’ll share the script (copiously annotated). Then I’ll provide and discuss the results I obtained on a modest sample of physical and virtual PCs.

# Get all the drivers from the online Windows image
$drivers = Get-WindowsDriver -Online -All

# Filter the drivers by the date of June 21, 2006
$drivers_2006 = $drivers | Where-Object {$_.Date -eq "6/21/2006"}

# Count the number of drivers with that date
$drivers_2006_count = $drivers_2006.Count

# Display the number of drivers and their names
Write-Output "There are $drivers_2006_count drivers dated 6/21/2006 in the online Windows image."
# Write-Output "The names of the drivers are:"
# $drivers_2006 | ForEach-Object {Write-Output $_.OriginalFileName}

# Create a variable for "all Windows drivers"
$alld = $drivers | Where-Object {$_.Inbox -eq "True"}
$alld_count = $alld.Count
Write-Output "There are $alld_count total drivers in the online Windows image."

The script takes advantage of the Get-WindowsDriver cmdlet to use Deployment Image Servicing and Management (DISM) for collecting information about the contents of the Windows DriverStore (usually in C:\Windows\System32\DriverStore\Filerepository). The script creates a variable named $drivers that contains a list of all the drivers in the online Windows image. It creates another variable ($drivers_2006_count) that includes only items with a date of 6/21/2006. It outputs the total count and the 2006 count. If you uncomment the lines at the end of the fourth block of text, it will also output a list of all the “original filenames” for each item in the driver store. To run the script, download a local copy and change the local permissions to read/write (or better), then run inside PowerShell.

I was amazed to observe that around five of every seven drivers in the Driver Store bear the 2006 date. This ratio is quite constant: on a Windows 10 VM, those numbers were 494 and 663; on my lone remaining physical Windows 10 PC they are 511 and 672. On Windows 11 PCs, those numbers were 515 and 699 (P1 Gen6 ThinkPad Mobile Workstation); 517 and 701 (ThinkPad X380 Yoga); and 515 and 699 (ThinkPad X1 Extreme). A Windows 11 Development Environment VM downloaded from Microsoft in December 2023 came in at 513 (drivers dated 6/21/2006) and 698 (total drivers). This rough 5-to-7 proportion holds across all the PCs I checked, in fact. This tells me that Microsoft is more involved in Windows driver development and maintenance than any other party, including even motherboard makers. Good to know!

The Device Detection and Driver Handling Process

As Windows 10 or Windows 11 starts up, or when a new device is plugged into a Windows PC, a bus driver – such as PCI, USB, VME and so forth – reports a new device to the OS. Windows queries that bus driver to obtain the device’s hardware IDs and compatible IDs (other hardware IDs that identify the device by type and kind). This information, as described in Overview of Device Installation at Microsoft Learn, serves to identify the device and guide the OS in selecting a driver to bring it into the runtime environment.

Microsoft describes the process of finding and installing a driver package for a wireless LAN adapter (for example, Wi-Fi) plugged into a USB hub attached to a Windows PC. This occurs in these broad steps.

1. The USB hub driver detects the device and queries it to obtain its hardware IDs. If you look in Device Manager, you can find this value—or values—on the Details tab, associated with the Hardware IDs (as shown in Figure 5).
2. The USB hub driver informs the Plug and Play (PnP) manager about a new device detection. Thereupon the PnP manager asks that hub for hardware and compatible IDs. (This may require multiple exchanges when a device has multiple hardware IDs, as shown in Figure 5.)
3. Windows searches the Driver Store for a driver package whose hardware IDs match one of the values reported in from the USB hub, from the top down. If a match isn’t found, the OS looks for a package with a compatible ID match. Any such match will install a driver, if only temporarily.
4. Windows fires off another process to check Windows Update and the DevicePath to look for a better match. If it finds one, that driver is copied into the Driver Store. (A new folder will be instantiated in C:\Windows\Windows32\DriverStore\FileRepository, and all the associated files copied into that folder.) Then, the “better match” will be installed.
   
   Note: This behavior of staging all drivers into the Driver Store started with Windows Vista—it’s the “ultimate explanation” why Microsoft uses 6/21/2006 as the putative date for all device drivers it writes and maintains. Indeed, this applies to the vast majority of such drivers.

Windows goes through a major flurry of device activity when the OS is clean installed. It does something similar when a feature upgrade gets installed as well. Otherwise, detection of a new device is the typical trigger for device detection and driver installation. Based on my 30+ years of Windows experience, Windows 10 and Windows 11 do an outstanding job of detecting and installing device drivers that Windows needs. Only rarely will the OS report that it can’t find a driver for some device. When that happens, it’s up to the administrator to provide a suitable driver package. Normally, you can find such things on the manufacturer’s website, if physical media isn’t included with a new device.

Getting Drivers from Windows Update

As Microsoft works on its massive collection of device drivers (roughly 70% of all drivers originate in Redmond), it leaves the Driver Date alone; it stays at 6/21/2006. However, it does increment or add to the driver version number, which identifies the most current driver when multiple versions might be available. Indeed, Microsoft can make driver updates available through Windows Update (WU) or related services found in corporate or organizational settings. Those include Windows Server Update Services (WSUS) or Windows Update for Business—perhaps in tandem with Intune, Autopilot, or other automated deployment platforms.

There are lots of interesting pros and cons (and opinions to match) about leaning on Microsoft for driver updates. That will be the focus of a follow-on article: it will describe multiple methods for obtaining driver updates and compare and contrast them. For this general introduction to device drivers, however, it suffices to observe that Windows does a creditable job of handling drivers on its own, including updates. Whether an organization should rely on Microsoft for device driver updates needs further discussion.