We create a Windows XP distribution kit with a selected set of drivers

Every computer user will sooner or later be faced with the issue of finding, installing and uninstalling drivers. This will be caused by purchasing a new device, reinstalling operating system, the desire to increase performance or improve other characteristics of the system - it doesn’t matter. In this article I want to provide some theoretical information about drivers, and also discuss some of the subtleties and techniques for handling them.

What it is
Driver - set utilities, allowing the operating system (OS) to work with a particular computer device. Its task is to process requests coming from application and system programs, translate them into a language understandable by the physical device, manage the processes of its initialization, setting parameters, data exchange, switching from one state to another, etc. The driver allows the operating system to communicate with specific device through common interface, which does not take into account the features of this device. In other words, the driver translates requests high level to low-level requests machine language, directly accessing the computer's hardware resources.

Not every device requires a driver. If there is a strict standard that describes the set of commands, the sequence and timing of operations, and other features of working with a given class of devices, a driver may not be needed, since the operating system already includes all the procedures necessary for this. In principle, this can be called a built-in driver. Examples - keyboard, timer, communication ports, modem (external). But if the device can be replaced with another one that is different in its functionality, then the driver for it will need to be installed.

The driver may also be included in the operating system distribution. Then the question of searching for it disappears in itself. However, devices that appeared after the official release of the OS will require installation separate driver developed by the manufacturer. In addition, the set of drivers included with the OS is small and only covers a small part the most common or completely standard devices.

Drivers and windows
In operating rooms microsoft systems A windows driver consists of several files, usually stored in the system, system32 directories and their subdirectories. The driver core is stored in files with the extensions .vxd, .drv, .sys and some others, and additional procedures are collected in dynamic libraries.dll. In addition, the driver may include help files, utilities, uninstallation modules, etc.

The sequence of operations for installing and uninstalling the driver is stored in a special information file.inf. With him using windows determines the type, manufacturer, model of the device, driver class, necessary resources and files. This file also describes the operations of unpacking, running, copying, deleting, renaming files, adding and removing keys in the registry, etc. All .inf files are stored in the inf directory, and installed drivers of non-Microsoft origin (not supplied with the OS) are stored in a separate subdirectory inf/other.

Windows can automatically find a driver for a device. To do this, it uses plug&play technology, or more precisely, the part of it that is responsible for device self-identification. In particular, PCI devices are detected by bios and listed in a special area escd (extended system configuration data). windows can use it, or it can independently poll the pci bus and find out from each device the codes of its manufacturer, model and version, necessary resources and other information. Next, the database (files drvdata.bin and drvidx.bin) is checked for all known devices and the necessary .inf file is found. If there are new files in the .inf directory, they will be automatically indexed and entered into the database.

It should also be remembered that the operating systems windows 98 se and windows 2000, as well as their descendants, support new model drivers, called wdm ( windows driver model). This is an attempt to implement full support plug&play and acpi, that is, make it possible to load and unload drivers “on the go”, without rebooting the system, connect them in the form of filter extensions to standard drivers microsoft, more flexibly manage energy saving and device configuration, etc. wdm drivers are stored in the system32/drivers directory. In particular, the new generation usb and ieee-1394 (firewire) interfaces work only under the control of wdm drivers.

“Reference” or “branded”?
Typically, the functionality of each computer device is determined by its controllers. The controllers look like integrated circuits installed on printed circuit board. The interaction of the device with other system components is reduced to the exchange of data and commands between the device controller and central processor(or another controller, for example, a bus arbiter, a dma controller, etc.). We can say that a driver is a program that allows the processor to “talk” to the controller.

Very often, chip developers (the so-called chipset) themselves write drivers for the device that their controller will control. Typically, such drivers are called “reference” drivers. They can either be publicly available and posted on the Internet on the developer’s website, or provided exclusively to equipment manufacturers for modification and adaptation. Obviously, in the first case, you can and should install reference drivers for the device, which are updated much more often than “branded” ones and contain bug fixes and new features. However, you may lose access to some device-specific features.

The “proprietary” drivers of the equipment manufacturer may be quite outdated, but at the same time take into account some features of the device that the chipset developers are not aware of. In any case, it always makes sense to try the “reference” driver first (if it is available for download), and if for some reason it does not work, return to the “branded” ones.

Driver versions
Like any other software, drivers have their own versions. The version format is free - each developer decides for himself how many digits he needs for numbering and in what sequence they should appear. In some cases, there is still a system: Windows drivers for the most interesting devices from our point of view, such as gaming video and sound cards, supporting directx, are numbered in a certain way. The first digit is the version number of the Windows operating system. 4 = win9x/winnt, 5 = win2000. Next after the dot comes directx version. 12 = dx7, 13 = dx8. The last digits are the version number of the driver itself. For example, the driver shown in the screenshot for nvidia video cards has version 4.13.01.1241, which means designed for win9x and directx8, its version is 1241.

To find out the driver version, unpack it into separate .vxd and .dll files. Next, you need to click on any of the files in Explorer (preferably with the extension .vxd) right click mouse, select “Properties”, then the “Version” tab (see screenshot). The driver version will be highlighted in color.

Sometimes manufacturers accompany the driver with their own installer (setup.exe, install.exe, etc.). Then it is not possible to see the driver files. Look for a readme.txt, version.txt, release.txt, or something similar, as they often also list the versions of the files or the entire package.

It is also worth mentioning the so-called beta drivers. Developers of chipsets and devices often try to stimulate interest in themselves by posting experimental drivers on their websites. Another well-known technique is the provision of drivers to owners of various thematic Internet sites under the guise of stolen ones or accidentally left on internal corporate pages (so-called “leaked” drivers). Of course, the developers disown them in advance and do not promise technical support in case of problems, but it seems to me that they still analyze the flow of letters from users and thereby save on the process of finding faults and debugging.

To prevent system crashes due to beta drivers, Microsoft has introduced a special certification. Drivers are tested in the microsoft windows hardware quality lab (whql), and after successfully completing all procedures they receive a certificate. It takes the form of a “security catalog” file (extension .cat), which lists all certified driver components. If such a file is not included in the driver package, then there is a very high probability that this is a beta version.

By the way, check the .cat files by running them double click mice, since they can be dummy (empty).

How to determine the manufacturer and model of a device
Of course, it is better to buy components from well-known manufacturers, fortunately today there is such an opportunity. Then the question of which driver to look for will not arise. But sometimes the user has no idea about the model or even the manufacturer of the device - for example, if the computer is not very new and someone else assembled it. Before you start searching, you will have to determine the exact name of the device or its chipset.

It will be easier to find the manufacturer of the device itself. First, all the necessary information must be inked on the printed circuit board. Even if you haven’t found the name, there is a chance to identify it by its fcc number. Look for the line “fcc id:”, which will indicate registration code, assigned to the device manufacturer. After this, you need to go to the fcc website and enter the code in the search bar.

Secondly, somewhere there will definitely be a device model written down, using which you can try to find the manufacturer’s website on the Internet.

Thirdly, if the device is installed in pci slot or agp, then using utilities you can determine the manufacturer code of this device or chipset. I can recommend sandra, powerstrip. The principle underlying identification is based on the analysis of information produced by a PCI device. At a minimum, you can get manufacturer (vendor id) and model (device id) codes, which can be deciphered using tables. In particular, the sandra table contains more than 6 thousand codes for various devices.

Where to get the driver
Of course, you don’t have to worry and install all the drivers directly from the CD that comes with the device. This decision is quite justified, but only for the first time. Drivers (especially for internal devices) tend to be updated frequently, so it is useful to occasionally search the Internet for new versions. Otherwise, there is a high probability that the device will be incompatible with new software or other components.

If you know for sure Domain name manufacturer's website (or guess what - www.manufacturer.com, www.manufacturer.com.tw), then you can start searching. On title page look for the “download”, “drivers”, “support” or similar button. Next, you need to select from the list exactly the device that you have. It is quite possible that you will see several devices with the same names, the differences of which will only be in suffixes or even revision numbers. Pay attention to this, otherwise the driver may not work. Next, if possible, download drivers not only for the operating system that you have installed, but also for other operating systems: during installation new windows It will be unpleasant to discover that the necessary driver is missing.

If you can’t find the site you need, contact specialized driver sites (http://www.windrivers.com/, http://www.driverhq.com/, http://www.drv.ru/, etc.) d.). You can download driver files directly from there only in one case: the developer company has already ceased to exist and its website is not physically on the Internet. It is much better to use the search not for the driver, but on the manufacturer’s website or its technical support page.

How to install
Installing the driver is as follows: Windows detects the .inf file, searches for plug&play device identification strings in it, and if they match the information issued by the device itself, the system performs the prescribed actions to copy files, add entries to the registry, etc. You must provide the location of the file when prompted by the Hardware Update Wizard. The wizard starts either automatically after a message about a found device appears, or manually. In the latter case, go to “System Properties” (press I+pause), select the “Device Management” tab, then properties desired device, “Driver” tab, “Update driver”.

If the driver comes with its own installer, then it is better to use it. To do this, after the message about a found device appears, press “esc”, load Windows without a driver and run the installer. It will copy all driver files to the windowsinfother folder, where the driver will be found after a reboot. In addition, it will be installed additional programs, included in the kit. It is also important that in most cases the installer can correctly remove the driver without leaving traces of its presence (Control Panel/Add or Remove Programs).

How to remove manually
If the driver you installed does not cope with its functions and even causes errors and crashes, you need to remove it. Just press “del” in the list of devices, and then wait for a message about a new device?.. Sometimes this helps, sometimes it doesn’t. The fact is that next time Windows may not ask you for a driver, but simply inform you about the device it has found and immediately return everything to its place. To delete information about the driver, you will also need to exit to dos, go to the windows/inf directory and find there the .inf file of the required (or rather, unnecessary) driver and delete it. Following this, you can send .vxd files, which are usually located in windows/system, but here you need to be careful, as you can overdo it. Now after reboot windows will update its database and will not find the old driver, which means you can install a new one or return the old one, which worked well before you started repairing what was not broken.

The first thing the user has to do after Windows installations- this is to search for drivers. Most often, the set that comes with Windows XP is not enough, since many years have passed since the release of this operating system, and during this time manufacturers computer equipment We have managed to update our products many times. Therefore, you have to search for and install drivers for each device separately.

The question of how to get a set of drivers for your computer worries many people, because the presence of such a set would significantly reduce the time needed to install the system. Here are some options:

• download finished assembly Windows XP, which already includes drivers for many common equipment;
• download a separate set of drivers, fortunately, there are a lot of them on the Internet (it’s better to get them from the websites of equipment manufacturers).
• make your own Windows assembly with the drivers that are already on your PC, and use it during subsequent installations.

Ready-made assemblies are convenient for inexperienced users, but they may not include all existing drivers. Therefore, it is best to learn how to add to Windows distribution everything you need on your own. This is what we will do.

So, we need:

• any utility for backing up Windows drivers;
• nLite program.

Owners of laptops with pre-installed Windows XP can add drivers to the assembly, which are stored in a hidden partition hard recovery disk.

Preparing a set of drivers for your computer

Back up drivers, that is, save copies of them in separate folder or archive is needed when all the equipment on your computer is installed, correctly recognized and working stably. We will perform this operation using the utility Driver Genius Professional. For our purposes, the trial version is quite enough.

Update

The first thing you need to do before making a reservation is to update the drivers for Windows XP. Driver Genius will help you determine what needs updating, and download and install required driver we can do it ourselves (the update function in Driver Genius is only available in the registered version).

• Install and launch Driver Genius, select “Update Drivers” and your operating system (Windows XP) from the menu, click “Next”.

• The program will scan everything Windows partitions, where the drivers are stored, and will identify those that are out of date. All we have to do is download and install new versions.

Reservation

• Select the “Back Up Drivers” option from the menu. In the “Select the drivers you want to back up” section of the window, check what you want to back up (you can choose between custom and Windows-owned drivers).

• If you have a laptop with hidden section recovery, in order for the program to gain access to it, you must assign a letter to this volume in Disk Management. You can get to “Disk Management” through the control panel - “Administration” - “Computer Management”.

• Next in Driver Genius, in the “Backup Type” section and Backup Location", select the storage type (folder, zip archive, self-extracting archive or automatic installation archive).
• Specify where the backup set of drivers will be saved. By default, copies are stored in the Driver Genius folder, but you can choose any other location.

• By clicking on the “Next” button, start the reservation process. After this, you will receive a complete set of Windows XP drivers suitable for your computer.

Driver integration into Windows XP distribution

To make an installation Windows disk XP with its own set of drivers will be needed free program nLite, which can be downloaded from the official website, and a Windows distribution (on disk or as an ISO image)

Procedure

• Download and install nLite on your computer.
• Place the Windows disk in the drive or mount its image to virtual drive using emulators ( Ultra ISO, Alcohol 120%, etc.).

• Launch nLite. Select the location of the Windows distribution (physical or virtual drive).
• Select the location where they will be extracted Windows files, subject to change (it is better to create a new folder).

• After copying, the distribution disk is no longer needed. By clicking the “Next” button, the nLite preset window will open. If you are using the program for the first time, this window will be empty, so let's skip it and move on.

• In the next window, from the list of tasks, select “Integrate” and “Drivers”.

• Next, by clicking the “Add” button, you need to select necessary drivers(as you remember, they are stored in the folder created by Driver Genius). The program will prompt you to add a single driver or folder. To add one driver, you need to specify the path to its .inf file (these files contain installation data).

• Having selected the drivers folder, just point to it in Explorer.

• The adding operation can be repeated several times. After checking everything you need, click “Next”. NLite will begin the process of integrating your chosen data into the distribution.

• Now the distribution package with your set of drivers can be burned to disk or an installation ISO image can be created. Place a blank DVD in the drive, select it in the "Devices" list of the next nLite window, install required parameters burn the disc and click the “Record” button.
• If you plan to add something else to the created distribution later, click “Next”. This way you can, for example, update the drivers in the installation kit at any time.

After all these steps, you will receive a Windows XP build with the set of drivers you need. At any time, you can add other drivers to it, which you first download from the Internet.

Obviously, each user personal computer, from time to time, there is a need to connect some device to your computer. The reason why this happens is not of much interest to us now; it could be an upgrade that is well known to many in order to increase the performance of individual nodes, and as a result overall performance system, this could simply be adding new equipment to expand the functionality of an existing configuration, as, for example, in the case of connecting a new game controller, this may also be the need to use data from a flash drive. Regardless of exactly how we connect a new device, the Windows operating system is forced to respond to the appearance of new hardware by performing some manipulations to ensure support for the new hardware on program level. On many operating systems, to provide software interaction devices use an interface between the hardware and a software layer called driver, so the operating system tries by all means available to it to install a driver for the new device in order to provide it for access to user-mode programs and kernel-mode code, because without this very notorious driver, the equipment in the system will work he simply can't.

Driver - software with which the operating system and those working within it software modules, gain access to the hardware.

But who can be surprised by installing drivers now? This process is already so familiar to all PC users from many years of practice that some, I am sure, can do this with eyes closed:) But have you thought about the details of this process, have you ever thought about driver installation algorithm? Have you ever wondered what actions the operating system performs when connecting a new device and installing drivers?

Agree that from the user's point of view, the process of installing a driver in Windows, in most cases, looks quite prosaic. The usual animated installation wizard icon appears in the system tray, and after a while the system may issue a report on the successful or unsuccessful completion of the installation procedure for a new device driver in the system. Moreover, often the installation wizard, apart from this very icon in the tray, does not provide any visual confirmation of attempts to install a new device, while “quietly” adding new equipment to the list of devices and marking it with a special icon in the device manager, offering the user manual mode continue configuring the equipment. All these external processes, already well known to both you and me, have been present in one form or another in all versions of Windows operating systems almost since the appearance of this operating system, differing slightly from each other only in details. They became so familiar and habitual that I never even thought about what was happening “on the other side of the screen,” in the depths of the operating system, what was hidden under this seeming triviality? As you will see below, installation Windows drivers for a physical or logical device hides quite interesting and complex processes. Driver installation algorithm in Windows can be broken down into the following key global tasks:

• Copying the driver binary file to the appropriate directory on the system;
• Registering the driver in Windows system indicating the loading method;
• Addition necessary information to the system registry;
• Copy/install related supporting components from the driver package;

In addition to the main tasks performed as part of the driver installation algorithm in Windows, it would be nice to classify the conditions under which the Windows driver installation process starts:

• The user installs a new device into a switched off computer. In this case, the process of detecting a new device and installing the driver begins already at the stage of loading the operating system.
• A user with local administrator rights, using the Device Manager snap-in, initiates the installation or update of a driver for an already installed device.
• The user “on the go” connects a new device to a running computer. In this case we're talking about about a certain category of devices that can connect on the fly, such as devices with external eSata interface, USB, etc. After all, you won’t install an internal video card when power is supplied to the PCIe slots? I personally haven't done this yet :)
• The user independently launches the driver package installation program from under account with local administrator rights. This method can be used both to install drivers for physical devices that support the Plug and Play standard, and to install non-PnP (legacy) drivers that cannot be automatically detected by the system and which cannot be installed except in manual mode. A typical example would be antiviruses or virtual machines who install their drivers logical devices into the system.
• The user right-clicks the .inf file in the driver directory and selects Install from an account with local administrator rights.

But what is the driver package itself? After all, as we have seen more than once, this is a whole set of files with completely different, at first glance, purposes. Without a more in-depth review of the structure of the driver installation package, it will be difficult for us to understand the driver installation algorithm itself, so we will present the general components:

• .inf file(s). A file describing the driver installation process. Key component of the driver installation package. inf file consists of instructions that tell Windows exactly how to install the driver: describing the device to be installed, the source and destination locations of all driver components, various changes that must be made to the registry when installing the Windows driver, information about driver dependencies, and so on. .inf files link physical device with driver controlling this device.
• Driver binary file(s). The package, at a minimum, must contain a .sys or .dll file of the driver core.
• Installation executable files. Usually these are already well-known installation utilities, which have the names setup.exe, install.exe and some others.
• Removal executables. These are usually uninstallation utilities that are named uninstall.exe.
• File(s) additional procedures and libraries. Usually these are auxiliary libraries in .dll format, co-installers.
• .cat file(s). Digitally signed catalog file. These files contain digital directory signatures and act as a signature for package files, with which the user can determine the origin of the package and verify the integrity of the driver package files. Required in 64-bit Windows versions, starting with Vista and later and recommended for everyone else.
• User mode control modules. Typically these are various command applets that run in user mode, such as ATI Catalist Control Center, VIA HD Audio Desk, Realtek HD Audio Control Panel and similar.
• Help files. Where would we be without them?

Terms and Definitions

In this article I will describe only one installation method, which, in any case, describes almost all stages of the driver installation algorithm in Windows, which are also applicable to other methods. And now we will talk about the situation when the user inserts new equipment, for example a video card, into the internal connector of a switched off computer. But first, let’s introduce some definitions that we need in the process of studying the driver installation algorithm.
Manager (dispatcher) Plug and Play (PnP Manager, PnP Manager)- a cloud of kernel mode and user mode code, responsible for adding, recognizing, removing devices in the system. The kernel mode block interacts with the rest of the system during the boot/installation process software necessary to service the devices available in the system. User mode block ( %Windir%\System32\umpnpmgr.dll, runs in the main context system process svchost.exe) is responsible for user interaction in situations that require installing new drivers or adjusting operating parameters in already installed ones. Responsible for the assignment and subsequent allocation of hardware resources such as interrupts (IRQs), I/O ports, direct memory access (DMA) channels, and memory addresses. Has the functionality of determining the driver required to support specific device and download/install functionality of this driver. Able to recognize new devices, respond to their connection and disconnection. Is part of the executive code Windows subsystems.

Enumeration of devices

There is no point in describing the entire loading stage from the very beginning, and we will start with only the stage of interest to us, at which the Winload(.efi) module loads the kernel of the Windows 7 operating system from the file ntoskrnl.exe. The kernel is launched by the PnP manager, which is part of the executive subsystem. The PnP manager starts the process of enumerating devices from the root device, a virtual bus driver called ROOT, which represents the entire system and is a bus driver for all PnP and non-PnP devices, as well as the HAL (hardware level abstractions). HAL at this stage functions as a bus driver that enumerates the devices directly connected to motherboard. However, the HAL, instead of actually listing it, relies on the hardware description already present in the registry. HAL's goal is at this stage- detect primary buses such as PCI. Driver primary PCI buses, in turn, lists the devices connected to this bus, finds other buses for which the PnP manager immediately loads drivers. These bus drivers, in turn, detect devices on their buses. This recursive process of enumeration, loading drivers, and then enumerating continues until all devices on the system have been discovered and configured. During the enumeration process, the PnP manager builds a device tree that uniquely describes the relationships between all devices in the system. The nodes in this tree, called devnodes (short for device nodes), contain information about a device object, which in turn describes the device in detail.
Records of all devices that have been detected since the installation of the system are stored in the registry hive HKLM\SYSTEM\CurrentControlSet\Enum. The plugins of this hive describe the devices in following format:

HKLM\SYSTEM\CurrentControlSet\Enum\Enumerator\DeviceID\InstanceID

• Enumerator - name of the bus driver. Can take values: ACPI, DISPLAY, HDAUDIO, HID, HDTREE, IDE, PCI, PCIIDE, Root, STORAGE, SW, UMB, USB, USBSTOR and others;
• DeviceID - unique identifier for of this type devices;
• InstanceID - a unique identifier for different instances of the same device.

The fact is that the driver of the bus to which the device is connected asks the device various parameters(identifier of the manufacturer, device, revision, etc.) and forms the so-called hardware identifier (HardwareID), which uniquely describes the device and is a string of parameters separated by & signs and consisting of the following parts:

• A prefix describing the bus to which the device is connected.
• Device ID. Consists of several parts, such as manufacturer identifier, product (model) identifier, device revision.

HardwareID is an identification string that depends on the device parameters (manufacturer, model, revision, version, etc.) that Windows uses to match the device with the driver .inf file.

Typical HardwareID structure:

PCI\VEN_10DE&DEV_1341&SUBSYS_2281103C&REV_A2

In addition to the HardwareID , the device is assigned the CompatibleID parameter(s), which has a similar format, but contains only more general values ​​that do not contain device-specific parameters (some device identifiers) and is necessary to initialize a wider range of compatible devices.

The HardwareID and CompatibleID are used by Windows executive code to find a device driver.

Driver detection

If, during the device enumeration and driver loading phase, the kernel mode PnP manager encounters a device that does not have a driver associated with it, it queries the driver of the bus on which the new device is connected and obtains the HardwareID and, optionally, the CompatibleID of the device. The kernel mode PnP manager informs the user mode PnP manager with a special event that this device requires installation, passing it the received identifiers. The user mode PnP manager first tries to install the device automatically without user intervention. To do this, the user-mode PnP manager runs the rundll32.exe utility to launch the Device Driver Installation Wizard (%Windir%\System32\Newdev.dll).

The Device Driver Installation Wizard initiates a search for a suitable driver for the device using information from all system inf files located in the following trusted system locations:

• Driver repository;
• Windows Update;
• System directory of INF files;

For the above purposes of searching and installing the driver, the functions of the setupapi.dll (installation support functions) and cfgmgr32.dll (configuration manager) libraries are used. During the search process, those already obtained are used. this moment HardwareID and (optional) CompatibleID identifiers, the values ​​of which describe everything possible options hardware identification in the driver installation file, that is, the inf file. The identifier values ​​of the installed device are compared with those described in the Models sections of the inf files registered in the system. The lists of identifiers are ordered so that more specific hardware descriptors are presented first in the lists. If ID matches were found in multiple inf files, the more exact match is considered preferable to the lesser match. exact match, signed inf files are preferred to unsigned ones, and later signed inf files are preferred to earlier signed ones. If a match based on HardwareID is not found, then CompatibleID is used, if available, of course. If a match is not found based on CompatibleID, the Add Hardware Wizard may prompt you to specify a location fresh driver equipment. Let's take a closer look at all of these sources of information about drivers.

Driver repository

The Driver Installation Wizard tries to locate a suitable inf file in the system driver store, located in the %Windir%\System32\DriverStore directory, which contains all, without exception, system drivers included in the Windows distribution, obtained through the "service" Windows Update", or installed into the system by the user.

Driver repository is a secure system location, a directory designed to store all driver packages that have ever been installed on the system.

The Driver Store was first introduced in Windows Vista. Before installing any driver on the system, first specialized code checks the digital signature of the driver, then the syntax of the driver inf files, then the privileges current user, only then puts all driver components into the system driver store. But then the driver located in the driver repository can be used to install devices on the system. Since the procedure for placing a driver in the repository is quite sophisticated, the driver repository is the most trusted source of information about drivers.

System directory of INF files

In parallel, the system searches for the driver in the system location described by the value of the DevicePath parameter located in the registry branch HKLM\Software\Microsoft\Windows\CurrentVersion. Typically the value is %SystemRoot%\inf , which on most systems is equivalent to the location C:\Windows\inf .

INF File

I would like to make a small digression and talk separately about information files driver package. inf file is one of the key components of the driver kit. It stores the sequence of operations for installing and uninstalling the driver, described by special directives indicating the location of the functional driver files. The file contains commands that add information to the registry responsible for listing (Enum) the driver and its class (Class), and may contain instructions for the Hardware Installation Wizard to launch the so-called main installers (Class Installer) and additional installers (CoInstaller , Co-installer) for the device class and the device itself. Additionally, the inf file determines the type, manufacturer, model of the device, driver class, necessary files and resources.

Co-installer (a regular DLL in structure) is an additional installer called at the installation stage, which performs installation steps specific to the subclass or device, such as preparing the infrastructure for the driver to work in the system (for example, installing the NET.Framework package), outputting configuration dialog boxes, which allow the user to specify settings for a specific device.

An important feature of co-installers is that, if necessary, they bind instances of a new device to the protocols required for operation. This, for example, may concern various types of communication devices, which require various protocols and transports to operate, such as ndis, pppoe, tcpip, tcpip6, smb, netbt.
The .inf file additionally describes the operations of unpacking, copying, running, renaming files, adding and deleting keys in the registry, and much more.
However, let's return to the main algorithm for installing a driver in Windows. If the device driver installer does not find suitable drivers in the locations listed above, the system marks the device as unidentified.

In this case, the user is asked to continue installing the device through the applet. device Manager. After the user independently selects the device and indicates the location of the driver files, the driver installation algorithm continues its work and the next step starts checking digital signature drivers.

Verifying driver digital signature

The fact is that the driver, as part of the kernel mode code, is a fairly critical component of the operating system, and any errors made by the developer in the driver code can easily lead to serious failures (BSOD) in the system. For some time now, Microsoft has been quite sensitive to the quality of driver code, and in connection with this, mechanisms such as driver digital signature and system driver signature policy have been introduced into Windows operating systems.

A driver's digital signature is a variable-length string of data that provides some assurance that the driver code was created by a trusted source and has not been subject to unauthorized modifications.

The next step is the user-mode portion of the PnP manager code, which checks the system driver signing policy. If system policy instructs kernel code to block or warn about installation unsigned drivers, then the PnP manager parses the driver inf file for the presence of a CatalogFile directive pointing to a catalog file (a file with a .cat extension) containing the digital signature of the driver package.

Catalog file (.cat) - special file, which plays the role of a digital signature for the entire driver package, because each file included in the driver package is not signed separately. The only exceptions are the boot phase kernel driver binaries, but these are checked separate code kernels.

A laboratory was formed to test drivers and sign them Microsoft Windows Hardware Quality Lab (WHQL), which thoroughly tests drivers supplied with Windows distributions, as well as drivers from major hardware suppliers. For all other driver developers, procedures are provided for obtaining the ability to independently sign drivers for on a paid basis. When a driver passes all WHQL tests, it becomes "signed". This means that for a driver, WHQL generates a hash, or unique signature, that uniquely identifies the driver files, and then signs it using cryptographic algorithms with the help of a special private key Microsoft used to sign drivers. The signed hash is placed in a directory file (.cat file) that is placed directly in the driver package directory.
During the driver installation process, the user-mode PnP manager extracts the driver signature from the .cat file, decrypts the signature using the Microsoft public key, and compares the resulting hash with the hash of the installed driver file. If the hashes match, the driver is marked as having passed WHQL testing. If the signature cannot be verified, the PnP manager acts in accordance with the settings of the system driver signing policy, either prohibiting the installation of the driver, or still allowing the installation of the driver.

Creating a Backup

Pretty good Windows strategy create a restore point before adding new device drivers to the system. This is due, first of all, to the fact that a kernel mode driver containing an error can cause the system to become completely inoperable, and then what should we do with this system? Even despite all the signatures and checks, the user should be able to roll back the configuration if, for example, he didn’t like something after installation.

Driver installation

At this point, the third-party driver package is deployed to the system driver store. Then, the system performs the actual installation of the driver from the driver store, which is done using the %Windir%\System32\drvinst.exe utility. At this stage the following events occur:

• inf file of the driver is copied to the specialized folder %Windir%/inf. For drivers third party developers It is typical to rename the file to OEMx.inf, where x is the serial number of the inf file in the directory.
• The operating system code records the fact of installation of the inf file in the registry.
• A device node is created in the registry along the path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\ \\ , which contains detailed information about the device.
• The driver binaries are copied to the target folder %Windir%\System32\DRIVERS and possibly other target folders. Registry keys are updated.
• A registry key corresponding to the driver is generated: HKLM\SYSTEM\CurrentControlSet\Services\driver_name. The key parameters are generated.
• A registry key responsible for logging driver events is generated, located in the branch HKLM\SYSTEM\CurrentControlSet\Services\EventLog\System\driver_name.
• The PnP manager calls the DriverEntry procedure for each newly installed driver. The kernel mode PnP manager then attempts to "start" the driver by loading it into memory and calling the driver's AddDevice routine to inform the driver itself of the presence of the device for which it was loaded.

Driver Information Location

In addition to describing the driver installation algorithm itself in Windows, I would like to highlight a separate section and devote it to a description of possible locations for placing information about drivers in file system and registry. From a practical point of view, this information is intended to simplify manual editing in case of any fatal failures. The following are locations where you may notice traces of driver information.

General Driver Logs

There are a number of logs in the system that can help with various problems regarding drivers.

• %Windir%\setupact.log -- contains debug messages from the kernel mode driver installer, which is a Win32 DLL that accompanies the device installation process;
• %Windir%\inf\setupapi.app.log -- contains messages from the application installation process;
• %Windir%\inf\setupapi.dev.log -- contains messages from the device installation process;

Driver log

If you use the Package Manager (pkgmgr) to install/uninstall a package, which (in turn) installs, updates, or uninstalls a driver, then you have the opportunity to enable (for debugging purposes) the creation of a special log file drivers.log , which will only contain driver-specific errors. To create this log, create/specify next key registry, and then run pkgmgr again. After this, a drivers.log file will be created in the directory from which pkgmgr was launched.
Branch: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Device Installer
Key: DebugPkgMgr
Type: DWord
Value: 1

%Windir%\inf

All inf files are stored in this directory. As mentioned above, after installation third party driver into the system, its inf file is renamed OEMx.inf, so you can see a whole series of similar files in the directory. The operating system code remembers the fact that the inf file was installed in the registry.

%Windir%\System32\DRIVERS

This is the directory in the Windows file system where the driver files are located. In modern operating systems, and I’m talking now about Windows Vista and later, the vast majority of drivers in this directory have .sys extensions; dll files are less common, however general meaning this does not change, since, regardless of the extension, they are all identical in structure to .dll files. In earlier operating systems, formats such as .drv and .vxd were encountered.

%Windir%\System32\DriverStore

A system collection of drivers, which is intended to contain each and every driver that passed through your system. Used since Windows Vista. Before installing any driver into the operating system, first specialized code checks the driver signature, then the syntax of the driver inf files, then the privileges of the current user, and only then adds all driver components to the system collection. And only after this the driver can be used in the system to install devices without any user intervention.

HKLM\SYSTEM\CurrentControlSet\Enum

A registry hive containing information about the devices present in the system. The PnP manager creates a key here for each device in the format HKLM\SYSTEM\CurrentControlSet\Enum\Enumerator\deviceID. where Enumerator is the bus identifier described above in the article, obtained at the device enumeration stage, deviceid is the device type identifier. The key contains the following information: device description, hardware identifiers (Hardware ID), compatible device identifiers (Compatible ID) and resource requirements. The hive is reserved for use exclusively by operating system code, so user applications and drivers are not recommended to interact with it directly, but are encouraged to use documented system functions.

HKLM\SYSTEM\CurrentControlSet\Control

Registry hive containing information about different parameters driver configurations at the operating system startup stage. Contains such important keys as:

• Class contains information about device installation classes, which are used to group devices that are configured and installed in a similar way. For each installation class, this key contains a key whose name matches the GUID name of the corresponding installation class.
• CoDeviceInstallers contains information about class co-installers
• DeviceClasses contains information about device interfaces registered in the system. any driver that wants to interact with user-mode programs on the system must provide an interface. The device interface class provides functionality device and its drivers to others system components and user mode applications.

HKLM\SYSTEM\CurrentControlSet\Services

A registry hive that is used to place information about all services (drivers) in the system. Every system driver places quite important global information about itself in connections like HKLM\SYSTEM\CurrentControlSet\Services\<Имя_драйвера> , which is used by the driver during the initialization process at the system boot stage. The hive is actively used by the PnP manager to pass parameters when calling the driver initialization procedure.
This bush contains the following elements:

• ImagePath - contains the full path to binary file(image) of the driver. the installation program fills this value based on data from the inf file of the driver package;
• Parameters - stores individual driver information, filled in based on the data placed in the inf file of the driver package;
• Performance - information for monitoring the performance of the device controlled by the driver. Specifies the name of the performance monitoring DLL and the names of the functions exported by this DLL. Filled in based on data obtained from the inf file;

HKLM\SYSTEM\CurrentControlSet\HardwareProfiles

A registry hive that contains information about system hardware profiles and is designed to support this technology. A hardware profile is just a set of changes to the standard hardware configuration and service configuration (original configuration), loaded at system startup. Contains specific changes to the original, main hardware profile configured in two registry keys: HKLM\SOFTWARE and HKLM\SYSTEM. Not used in Windows 7, although registry keys remain, probably for compatibility reasons.