How to force install drivers on Windows 7.
This type of driver installation almost always helps when the driver for the device is not installed by simply running the installation file setup, with extensions *.exe or *.msi.
But the main condition for successful driver installation in this case is that the driver must be completely unpacked and the file with the extension *.inf must be available. Often, hardware manufacturers package their drivers not only with standard ZIP archivers, but also using intricate programs of their own making. Here a program can be very useful for unpacking Universal Extractor, which can be used to unpack almost any driver installer.
Let's consider how to force install a driver in Windows 7 using a webcam as an example Defender AV-W2035. There is a driver downloaded from the Internet AV-W2035_VISTA.zip, which we successfully unpacked into a folder C:/AW-0350-MIC-VISTA. First, we need to look at where our file with the extension is located *.inf. To do this, you need to enable the display of file extensions in Windows folder properties so that file names are written with their extensions. Or use a very useful program Total Commander or similar file manager. After looking through the folders (you can use the file search), we found the file snpstd2.inf
You should remember the entire path to this file so that later it will be easier to find it in Conductor. We connect the camera to the computer and wait for Windows to complete all its operations to detect new hardware.
Opening device Manager (Start –> Control Panel –> Device Manager)
The device is immediately visible USB camera without installed drivers. Right-click on the camera and select the item in the context menu Update drivers...
in the window that opens, click
and then select the button Further
A window will open with a list of equipment categories.
In order not to waste time or rack your brains, we simply point to the first line Show all devices and press the button Further
In the next window we will see a list of available drivers in the system (if any). But since we know that we have a folder with the driver, without selecting anything from the list, we click on the button
Press the button Review…
and using Explorer we look for our file with the extension *.inf, select it with the mouse and follow the button Open
and, of course, a button OK
Now our driver will appear in the window with a list of available drivers (if the driver is not suitable for the equipment, the system will generate an error).
Here you should pay attention to the checkbox Compatible devices only. The fact is that if the connected equipment has not been tested for compatibility with the installed version of Windows, then a driver for it will not be found, despite the fact that it may be completely working. Therefore, in some cases, this checkbox should be unchecked and the driver search repeated again.
So, after the file with the driver is found, select our driver in the list with the mouse and press the button Further
The driver installation will begin.
A Windows warning may appear indicating that the driver you are installing does not have digital signature or has not been checked for compatibility. If you are sure that the driver was taken from a reliable source and is exactly intended for the equipment being installed, then you should absolutely not be afraid of such a warning, but should agree to further install the driver. When the installation is complete, the system will display a completion window.
You can verify successful driver installation by checking Device Manager, where the connected device will no longer have a question mark, and its name will change to the correct one created by the manufacturer. In our case with the camera, this will be the device that appears with the name USB PC Camera (SN9C103)
The installation is complete, you can safely start using your new equipment!
Obviously, every user of a personal computer from time to time needs to connect some device to his station. 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 consequence of the overall performance of the system), it could also be simply the addition of new equipment to expand functionality 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 equipment by performing certain manipulations to ensure support for the new equipment at the software level. Many operating systems use an interface between the hardware and a software layer called a driver to provide software interaction with devices.
Driver is software with which the operating system and software modules running within it gain access to hardware or logical devices.
That is why the operating system is trying by all means available to it to ensure the functioning of the device in its environment; for this, an attempt is made to install the appropriate driver for the newly connected device, in order to thereby provide the functions of the new device for access to user mode programs and kernel mode code, because without this very notorious drivers, the equipment in the system simply will not be able to work.
It is no coincidence that I mentioned logical devices in the definition, since there is a separate category of drivers that do not maintain hardware, but are integrated to expand the implementation (expansion, addition) of the functional features of various system modules. 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 it with their eyes closed :) But have we thought about the details of this process, have we 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 (if unsuccessful) marking it with a special icon in the device manager, suggesting user in 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 imaginary simplicity? As you will see below, installing a Windows driver for a physical or logical device hides quite complex and extremely interesting 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, indicating the boot method;
- Adding the 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 be connected on the fly, such as devices with an 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, logical device drivers that cannot be automatically detected by the system and which cannot be installed otherwise in manual mode. A typical example would be antiviruses or virtual machines that 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). The key component of the driver installation package is a file that describes the driver installation process. inf file is divided into sections and consists of instructions that indicate to the system exactly how the driver is installed: they describe the device to be installed, the source and destination locations of all driver components, various changes, which must be entered into the registry when installing a Windows driver, information about driver dependencies, etc. .inf files associate a physical device with the driver that controls that device.
- Driver binary file(s). The package, at a minimum, must contain a .sys or .dll file for the driver core. In fact, a single .sys file (as a last resort) can be installed (with reservations) manually by editing the registry.
- Installation executables. 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) of 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 on 64-bit versions of Windows starting with Vista and later and recommended for all others.
- User mode control modules. Typically these are various command applets that work in user mode, such as ATI Catalist Control Center, VIA HD Audio Desk, Realtek HD Audio Control Panel and the like.
- 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 context of the main 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. It has the functionality of determining the driver required to support a specific device and the functionality of downloading/installing this driver. Able to recognize new devices, respond to their connection and disconnection. It is part of the Windows executive subsystem code.
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 that interests 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). The HAL at this stage functions as a bus driver that enumerates the devices directly connected to the 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. The primary PCI bus driver, in turn, lists the devices connected to this bus and 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 subkeys of this hive describe devices in the following format:
HKLM\SYSTEM\CurrentControlSet\Enum\ Enumerator\ DeviceID\ InstanceID
HKLM\SYSTEM\CurrentControlSet\Enum\ |
- 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 - a unique identifier for this type of device;
- 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 requests various parameters from the device (manufacturer, device, revision, etc. identifier) and generates a 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 have a similar format, but contain only more general values that do not contain device-specific parameters (some device identifiers) and are 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 at the stage of enumerating devices and loading drivers, the functional driver of the bus on which the new device is connected informs the PnP manager about changes in the connected child devices. The kernel mode PnP manager checks whether a driver is associated with the device by querying the driver of the bus on which the new device is connected and obtaining 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 identifiers HardwareID and (optional) CompatibleID, the values of which describe all possible options for identifying hardware 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 to be preferred over the less exact match, signed inf files are preferred over unsigned inf files, and later signed inf files are preferred over previously signed inf files. 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 the CompatibleID, the Add Hardware Wizard may prompt you to locate the latest hardware driver. Let's take a closer look at all of these sources of information about drivers.
Driver repository
The Driver Installation Wizard tries to find 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 "Windows Update" service, or installed in 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 of the current user, and only then places all driver components in 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 the information files of the 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 defines the type, manufacturer, model of the device, driver class, necessary files and resources.
Co-installer (structurally a regular DLL) 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), displaying 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 apply to various types of communication devices that require different 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 is checking the driver’s digital signature.
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 the kernel code to block or warn about the installation of 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.
A catalog file (.cat) is a special file that acts as a digital signature for the entire driver package, because each file included in the driver package is not signed separately. The only exception is the boot phase kernel driver binaries, but these are checked by separate kernel code.
To test drivers and sign them, the Microsoft Windows Hardware Quality Lab (WHQL) was formed, 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 opportunity to independently sign drivers on a paid basis. When a driver passes all WHQL tests, it becomes "signed". This means that WHQL generates a hash, or unique signature, for the driver that uniquely identifies the driver files, and then signs it using cryptographic algorithms using a special Microsoft private key used for signing 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
It's a pretty good Windows strategy to 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 third-party drivers, it is common 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 (devnode) 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 the file system and registry. From a practical point of view, this information is intended to simplify manual editing in the event 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 on the system that can help with various driver issues.
- %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/set the following registry key, 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 installing a third-party driver on 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 overwhelming majority of drivers in this directory have .sys extensions, dll files are less common, but this does not change the general meaning, since, regardless of the extension, all they are 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 discouraged from interacting directly with it and are encouraged to use documented system functions.
HKLM\SYSTEM\CurrentControlSet\Control
A registry hive containing information about various driver configuration parameters during operating system startup. 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 exposes the functionality of the device and its driver to other 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. Each system driver places quite important global information about itself in connections of the form 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 the driver binary file (image). 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.
Loading...