Windows device driver installation applications: best practices and mitigations 21
Windows device driver installation applications: best practices and mitigations
November 2015
version 1.0
Copyright
This document is provided "as-is." Information and views expressed in this document, including URL and other Internet Web site references, may change without notice.
Some examples depicted herein are provided for illustration only and are fictitious. No real association or connection is intended or should be inferred.
This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes. This document is confidential and proprietary to Microsoft. It is disclosed and can be used only pursuant to a non-disclosure agreement.
© 2015 Microsoft. All rights reserved.
Please refer to Microsoft Trademarks for a list of trademarked products.
All other trademarks are property of their respective owners.
Contents
Overview 5
Choose driver packages over setup.exe’s 5
Driver packages 6
Driver distribution 7
Windows Update 7
Updater applications 7
User-based Web downloads 8
Driver importation 8
Online importation 8
Offline importation 9
Driver installation 9
Reasons to avoid installation applications 9
Mitigations for driver installation applications 11
Distributing setup.exe rather than raw INF files 11
Mitigation 12
Driver dependencies 12
Mitigation 12
Ordering installation of drivers 13
Mitigation 13
Removing drivers 14
Mitigation 14
Registering COM servers and other components 14
Mitigation 15
Installing (value add) applications with a driver 16
Mitigation 16
Driver settings 18
Mitigation 18
Synchronizing driver version with application version 19
Mitigation 19
Adding software device nodes (devnodes) 19
Mitigation 20
Adding SCM services 20
Mitigation 21
Adding driver settings as Windows registry keys and values 21
Mitigation 21
Using text-based configuration files 21
Mitigation 22
Copying files 22
Mitigation 22
Processor-specific configurations 22
Mitigation 22
Support files for inbox drivers 23
Mitigation 23
Best practices 24
Avoid co-installers 24
Finish install actions (FIA) 25
Driver settings 25
Store all settings in the registry 25
Document History 25
© 2015 Microsoft. All rights reserved. 21
Windows device driver installation applications: best practices and mitigations 21
Overview
There are several different methods for distributing and installing a device driver onto a Windows system. Generally these are broken down into two categories:
· Hardware-first installation
Hardware-First Installation is also known as the Missing Driver scenario, in which Windows sees the hardware before it has a driver. In this scenario, the hardware comes first, and, there is no driver available on the system. This typically triggers a request to Windows Update to locate, download, and install the required driver.
Hardware-first installation is described on MSDN here:
https://msdn.microsoft.com/library/windows/hardware/ff546139.aspx
· Software-first installation
Unlike the hardware-first installation category, software-first installation relies on a person running a software installation tool to preinstall a driver for hardware that is not yet present.
Typically this category is used by hardware vendors that preinstall drivers for their computer systems on the factory floor during manufacturing. They use tools or software packages (like a hardware driver setup.exe program) that import the necessary driver into the Plug-and-Play driver database so that it is available when the hardware is plugged in.
Software-first installation is described on MSDN here:
https://msdn.microsoft.com/library/windows/hardware/ff552293.aspx
This paper focuses on the second category: software-first installation. Software-first installation applications are no longer just installing a driver. This growth has led driver developers to take dependencies on the installation application to setup the driver’s environment. This dependency can cause problems with driver servicing, execution, and other events.
This paper identifies:
· How to consolidate driver installation into INF-based driver packages, which are properly supported by Windows.
· How to make software-first installation applications as minimal as possible, in order to address the issues found during servicing events.
Choose driver packages over setup.exe’s
All devices connected to a Windows system must communicate through a driver. For many device classes Windows comes preinstalled with class drivers. These generalized drivers are designed to work with standardized technologies (such as PCI, USB, HID, and so on) that hardware vendors rely on. Many device manufacturers can create hardware without ever having to distribute their own custom drivers. Vendors of mice and keyboards, for example, take advantage of the built in class drivers in Windows.
Vendors can, if they choose, decide to develop and distribute their own custom drivers. This may provide additional value-add functionality above the standard built-in Windows support.
Any custom driver must be distributed to a Windows system, imported into the PnP driver database, and then installed on the particular hardware for it to be used. Microsoft provides built in PnP and Windows Update support as well as various tools (such as Windows Driver Framework [WDF], Hardware Lab Kit [HLK], and the SysDev Portal [account required]) to develop, test and validate, and sign and distribute their drivers for all Windows customers.
Windows drivers should be distributed, imported (also known as pre-installed), and then installed. Even though there are several ways to distribute driver packages (see the Driver Distribution section in this document), all importation and installation tools require raw INF driver packages (no setup applications or archived formats).
Ultimately, any attempt to import or install a driver into a Windows computer goes through PnP. For the Windows end-to-end user experience, how the driver is distributed is very important. For PnP, strictly speaking, how the driver is distributed doesn’t matter as long as it provides the driver package (the INF plus the files the INF points to). But if a hardware vendor only provides driver installation applications, then the user experience is compromised in at least the following scenarios:
· OEMs cannot efficiently create or update manufacturing images.
· System administrators are unable to create offline network book images.
· Windows Update cannot be used to distribute and install new or updated drivers.
· Windows recovery services such as Push Button Reset (PBR) will be unable to reliably recover drivers fully.
· Flattening and reinstalling Windows will yield broken devices (missing drivers and/or mis-configured drivers).
Additionally, driver installation applications often make driver installation decisions at run time. This offloads decision making logic from the driver and its INF file and moves it into the installation application. This type of issue can be a problem for several reasons:
· IT Administrators (in the enterprise space) often create system images with all needed drivers and line of business (LOB) applications that are applied to multiple types of PCs, each with different processors.
· Network boot images (PXE, WDS, and so on) differentiate based on processor architecture (x86, x64, ARM, and so on), not based on processor family or specifics.
· Windows To Go scenarios (one USB drive used to boot Windows on different PCs) use one image across a variety of devices.
In each of these scenarios, drivers need to be added to the PnP driver database without running a driver installation application. Also, because drivers are picked based on their installation targeting (in particular the component’s hardware ID), the driver itself must best perform for any given hardware ID.
Driver packages
In Windows, driver packages are a loose collection of files (.sys, .dll, security catalog, and so on) that are organized using the driver’s manifest file (the INF file). The manifest file is what links all of these files together. Even though the collection of these files is called a driver package, there is no real packaging involved; it is neither zipped, cabbed, or tarred. It is just a directory on a hard drive with all of the necessary files.
All drivers must have an INF file. This manifest file provides the list of other files that make up the driver. If a file is distributed with a driver but it is not listed in the driver’s INF file then it is simply ignored by PnP. In addition to listing the driver’s files, the INF also describes what actions must be taken when the driver is installed: what path to copy files to, what registry settings to modify, how to setup the driver’s service, any co-installers to execute, how to install on different versions of the OS, and more. Think of the INF as the central hub of a driver package.
Driver distribution
Driver packages must be distributed to a Windows computer. The only exceptions for this are drivers built into Windows. There several ways in which distribution can occur. Windows Update is the preferred method, but OEM updater applications, web site downloads, and users emailing drivers to each other are possible.
Software-first installation apps install drivers by exposing the driver package (INF + other files) to a PnP API. The application has to put the driver package into a storage location and then make the PnP API call.
The important point here is that regardless of how the package is distributed (.zip file, software installation application, OEM updater app, Windows Update, and so on), PnP needs to consume the raw INF driver package.
There is no official driver packaging format. A hardware vendor can choose to use ZIP, CAB, TAR, or others to bundle the files together for distribution. The only requirement is that once the driver package has been distributed, it is unarchived and placed in a location that the PnP APIs can access.
Note that in general, driver distribution requires that drivers are somehow bundled up together as a single file (ZIP, CAB, TAR, and so on). This guarantees that no matter which distribution method used (web download, email, floppy disk), that method does not accidentally omit a part of the driver package.
Windows Update
Windows Update manages drivers on behalf of both hardware vendors and end users. Windows Update will only distribute driver packages. It does not facilitate distributing installation applications. Hardware partners publish drivers to Windows Update by using the same process they use to sign drivers: The Windows Dev Center (https://sysdev.microsoft.com/).
Updater applications
IHV and OEM updater applications make the process easier for the end user, but still runs into the distribution problem. It can either download a driver and all into PnP APIs, or it can download an .exe which, when launched, calls into the PnP APIs.
User-based Web downloads
Many hardware vendors provide access to their drivers by placing them on a web server. Users are expected to determine which driver to download for their needs. Some websites provide guidance such as wizards or lookup lists to help the user determine which driver to fetch from the multitude of options.
Such web downloads provide the user with either a driver archive (ZIP file, say) or an executable. The former is acceptable for system image builders (like IT administrators and OEMs), but can be problematic for end users. It requires that the user have tools to unarchive the driver and knows how to use tools such as Device Manager or pnputil.exe.
Driver importation
Before Windows can do anything with a driver it must first import the driver package into the PnP driver database (sometimes referred to as the driver store). PnP will only install and load drivers that are already imported into this driver database.
PnP provides the DriverPackagePreinstall function to import drivers into the PnP driver database. PnP also provides the DiInstallDriver function, which does the importing (pre-installation) immediately followed by an installation. DriverPackagePreinstall looks for an INF file in a path that the calling application provides. It doesn’t matter how the files were distributed, only that the driver’s INF and files are available in a storage location.
Typically a driver package is distributed, and then stored in a directory on a storage device. The directory will contain the INF and all of its files. Thus, the INF’s references to files are relative to the current directory in which the INF is located. This is how Windows Update works. The Windows Update client API downloads a driver package and places its contents into a cached location. It then calls a PnP API to import the driver into the PnP driver database. The API opens the driver’s INF file to determine what other files are associated with the driver. PnP then imports the INF as well as the files it references into the driver database.
There are two different ways to import drivers: online and offline.
Windows ships with several tools to invoke these PnP APIs. The first is PnP itself. On discovering new hardware for which a driver is not already present in the driver database, PnP calls into the Windows Update Client API to download the driver from Windows Update, where the driver is stored as a CAB file. That client code then un-archives the downloaded driver and calls into the PnP APIs.
The Device Manager app also offers the ability for a user to manually import or update a driver. The user selects the directory to find the driver in (in particular the INF file), then Device Manager calls the PnP APIs pointing to the INF. Other tools that support this driver importation include pnputil.exe and DISM.exe.
Online importation
Online importation is what most users observe. This is where Windows is running and the driver is imported (and usually installed) while the user is interacting with the system. For example, if you plug in a new printer USB cable, the printer just works. This is because PnP discovered the new hardware, fetched the driver from the driver database, and installed it. If the driver was not already present in the PnP driver database (maybe it is brand new printer) then PnP requests the driver from Windows Update. Upon downloading the driver, PnP imports it into the database then installed. All of this happens online.
Offline importation
Offline importation occurs when Windows is not running and a user, administrator, or OEM uses tools to inject a driver into the Windows image. Examples include:
· An OEM building a Windows image for manufacturing. The image is created offline, meaning that the OEM is using offline servicing tools like DISM.exe to import (some think of this as injecting) drivers into a Windows image file. The file is then installed onto machines on the factory floor during manufacturing.
· Enterprise IT administrators build Windows images customized with their LOB applications and business hardware specific drivers. They build these images offline, importing drivers and applications into the image file. Then the image file is placed on network installation servers for network boot scenarios such as PXE (Preboot Execution Environment) and Windows Deployment Services (WDS).