Updating Windows Device Drivers

March 21, 2024
7 min read

Check the Introduction for Driver Basics

See the previous story in this series Managing Windows Device Drivers for a basic and more detailed definitions of the term “device driver.” That story also explains why and how driver dates can be important, plus how Window decides which drivers to install. It also provides an analysis of Microsoft’s own contributions to the overall device driver population.

Windows Update Gets Involved

Occasionally, Windows Update (WU) will offer a new device driver to Windows for one or more devices already present. Understanding how WU handles such updates is essential to understanding why some devices will be updated automatically (if prevailing policies or GPOs permit) and why some such updates simply show up in Settings/Windows Update/Advanced Options/Optional Updates/Driver Updates, as shown in Figure 1.

Screenshot: for this ThinkPad P16, Windows Update offers 4 optional driver updates.
Figure 1: Driver Updates reside deep within the Settings/Windows Update hierarchy. |  | Image used with permission from Microsoft.

The PC that produced the image for Figure 1 is a Lenovo ThinkPad P16 Mobile Workstation. As you can see, it shows four different items (three of which are labeled “Firmware,” the fourth “System”). It turns out to be important that these drivers come under this “Optional updates” heading within the Windows Update (WU) hierarchy. This means that the OEM – Lenovo, in this case – has designated these drivers as Manual updates rather than Dynamic or Automatic. Let me explain what this means…

The Windows Driver Delivery Process

As explained in the MS Learn article Understanding Windows Update rules for driver distribution, driver developers must select one of two “Driver Delivery Options” when they submit a driver to Microsoft for publication via Windows Update as shown in Figure 2. These two options are labeled Automatic and Manual.

Screenshot of Driver Delivery Options: When the Automatic radio button is selected, the two options below are also selected by default.
Figure 2: By Default, an “Automatic” driver gets installed with the OS and with feature upgrades. | Image used with permission from Microsoft.

Automatic status on a submission means the driver writer asserts that this particular driver should be installed. Its two options for delivery cover (1) a feature upgrade (labeled as “Windows Upgrades” in Figure 2) and (2) during OS install or via WU delivery at any time (labeled as “all applicable systems”).

As Microsoft’s afore-cited driver distribution story says further about Automatic or Dynamic Update items, “Windows automatically preloads drivers in this category when upgrading the OS.” As for “all applicable systems” it says, “installed automatically … once it is released.” Indeed, every Automatic driver must go through a Microsoft evaluation as part of the company’s Driver Flighting process. This multi-step maneuver requires filing a Support Ticket and working through the submission, testing and bugfix processes to meet Microsoft’s QA requirements for Automatic drivers.

What This Means for Manual Drivers

The drivers that show up under the Settings/Windows Update/Advanced Options/Optional Updates/Driver Updates heading are those for which the driver developer is NOT willing to go through ticketing and the other steps involved. Ultimately, this is what makes the driver optional – even its developer chooses not to insist on its selection and distribution, backed up by staff time and effort to shepherd the driver through the Driver Flighting process.

That Driver Flighting process (for Automatic Drivers) is designed to make sure that drivers work as well as possible once they’re distributed. This doesn’t mean such drivers work 100% of the time in all situations and on all PCs: it just makes such a positive experience more likely. Because Manual drivers do not involve such rigorous testing (rollout of Automatic drivers often includes Insider distribution for broad exposure before wholesale distribution in official, stable releases later on) they get relegated to optional status.

What does this really mean? Take another look at the introductory text in Figure 1 above. It reads: “If you have a specific problem, one of these drivers might help. Otherwise, automatic updates will keep your drivers up to date.” In other words, one should only install an optional driver if it’s related to a device that’s experiencing difficulties or misbehaving.

I’ll summarize this approach to optional drivers as, “If it ain’t broke, don’t fix it.” In researching this story, I took a handful of test systems and installed anywhere from two to five optional drivers on each one (i.e. whichever optional drivers WU made available). None of these caused any problems, nor generated any warnings or errors in Reliability Monitor or Event Viewer. That observed, I’ll follow by saying that third-party sources (check this Google Search for its many results) unanimously echo Microsoft’s advice in the preceding paragraph. Again, that goes something like this: Don’t install an optional update unless the related device has issues.

Getting Drivers from Windows Update

Automatic drivers get installed on Windows systems during OS install and feature upgrades. For most curated images – including those used in large-scale deployment scenarios – that means drivers should be selected and tested in the lab (and perhaps also in limited pilot tests by “real users” through the Insider program) before they ever go into distribution.

When preparing and testing images prior to deployment, it may be necessary or advisable to update one or more device drivers. The driver roster should be set and frozen prior to your next deployment window. Thus, only test machines will typically get Automatic drivers, or be subject to a driver update from another source. IMO, only automatic drivers should be allowed into test images without extensive checking in lab and possibly also pilot deployments for possible device issues or software conflicts, issues and so forth. For production deployment, you can always integrate drivers into a target image using the DISM /add-driver… command.

And where “other sources” for drivers are concerned, prevailing wisdom dictates that such drivers come direct from the manufacturer’s or OEM’s download pages. Indeed, for up to three years after initial release, most such sources will not only post such updates to their sites, they’ll also let you sign up for notifications via email, text message, and so forth when and if driver updates are required. This approach is particularly important and widely followed for graphics (for integrated graphics chipsets and standalone GPUs) and network drivers (for all kinds of wireless and wired technologies).

One more thing: where the major PC and laptop vendors are concerned (e.g. Lenovo, HP, Dell, Apple, Asus and Microsoft itself) all of them routinely provide update pages for integrated and included devices by PC make and model for at least three years after initial release. Most also offer scanning tools (e.g. Lenovo Vantage, HP Support Assistant, Dell Command Update, and so forth) that will scan and update drivers, UEFI, and firmware on still-covered PCs and laptops. Here again, though, you’ll want to use them on test machines in the lab for review and analysis before even thinking about additional steps (pilot test and/or deployment). Because a bad driver can lead to bad user experiences, that possibility should be eliminated before it ever gets near deployment and production use. Please bear this in mind as you refine your “golden master” Windows images for the next deployment window.

End Notes/Meta-Data

The Windows OS is surprisingly adept at recognizing PC devices, and supplying usable device drivers for use on the PCs where they attach. That said, monitoring updates for drivers is important for delivering stable Windows images that deliver positive user experiences. Understanding how MS qualifies drivers as Automatic and Manual will help you decide when an update might be needed, as will a keen appreciation of processes for testing and vetting device drivers worthy of deployment.

Ed Tittel is a long-time computing industry writer, consultant and occasional expert witness. He’s the author of over 100 computer trade books, and countless articles and other stuff. He’s also a Windows Insider MVP (2018-2023). For more info, please visit https://edtittel.com.

Ed Tittel

Ed Tittel

Ed Tittel is a long-time computing industry writer, consultant, and occasional expert witness. He’s the author of over 100 computer trade books, countless articles, and other stuff. For more info, please visit https://edtittel.com.