Newsticker

Wednesday, October 14, 2015

An Insight into the Windows device driver infrastructure

An Insight into the Windows device driver infrastructure
Device Drivers are one of the most dreaded creatures in the world of Windows. Hardware and software issues like driver compatibility, device not recognized, invalid or corrupt device drivers seem to crop up often which wreck havoc on a computer. For most of the Windows users the nitty gritty of the Device drivers are an uncharted territory and require the help of an expert.

The following is an insight into the Windows device driver infrastructure - the fundamental concepts of the device drivers, the devices and driver installation process, the driver types, driver architectural models, the driver classes, and the interaction of drivers with hardware devices, Windows and other drivers to form the windows device input output system.


1. Driver Concepts

In order to provide system stability, security, and standardization in an preemptive multitasking environment the Windows operating system restricts direct access to the system hardware resources and the operating system resources by applications and provides access based on assigned scheduling priorities and defined access control model.

Driver types

  1. Device driver
    A device driver is a specialized computer program enables an operating system to interact with a hardware device like processor, RAM, storage media, input/output devices or any software component that observes or participates in the communication between the operating system and a device. For a given I/O request (like reading data from a device), there are often several drivers, layered in a stack, that participate in the request.
  2. Software driver
    A driver that is not associated with a device is called a software driver. Software drivers always run in kernel mode and provide access to the protected operating system resources like system configuration, settings, User Interface objects, graphics device interface (GDI) objects, and kernel objects.
  3. Export driver
    An export driver is a kernel-mode DLL that provides routines for other drivers to call. Like any standard driver, an export driver contains only routines that resolve to kernel-mode functions. Unlike a standard driver, however, an export driver does not receive IRPs or occupy a place in the driver stack, nor is it considered to be a system service.
  4. File system driver
    A file system stack consists of control device objects CDO) and volume device objects (VDO), together with any filter device objects for file system filter drivers that are attached to it for accessing a file system.

Processor Modes

A processor in a computer running Windows has two different modes:user mode and kernel mode. The processor switches between the two modes depending on what type of code is running on the processor. Applications run in user mode, and core operating system components run in kernel mode. Drivers can be written in either user mode or kernel mode.
  1. User mode drivers
    user mode string
    When you start a user-mode application, Windows creates a process for the application. The process provides the application with a private virtual address space and a private handle table. Because an application's virtual address space is private, one application cannot alter data that belongs to another application. Each application runs in isolation, and if an application crashes, the crash is limited to that one application. Other applications and the operating system are not affected by the crash. In addition to being private, the virtual address space of a user-mode application is limited. A processor running in user mode cannot access virtual addresses that are reserved for the operating system. Limiting the virtual address space of a user-mode application prevents the application from altering, and possibly damaging, critical operating system data. User mode drivers are implemented as dll files and run in the address space of the parent process.
  2. Kernel mode drivers
    All code that runs in kernel mode shares a single virtual address space. This means that a kernel-mode driver is not isolated from other drivers and the operating system itself. If a kernel-mode driver accidentally writes to the wrong virtual address, data that belongs to the operating system or another driver could be compromised. If a kernel-mode driver crashes, the entire operating system crashes. Kernel mode drivers as implemented as sys files and run in the system address space.


2. Windows Driver Model

To allow driver developers to write device drivers that are source-code compatible across all Microsoft Windows operating systems, the Windows Driver Model (WDM) was introduced. Kernel-mode drivers that follow WDM rules are called WDM drivers.
There are three kinds of WDM drivers:
  1. Bus drivers

    A bus driver services a bus controller, adapter, or bridge. Microsoft provides bus drivers for most common buses, such as PCI, PnpISA, SCSI, and USB. Other bus drivers can be provided by IHVs or OEMs. Bus drivers are required drivers; there is one bus driver for each type of bus on a machine. A bus driver can service more than one bus if there is more than one bus of the same type on the machine. Bus drivers also detect and report child devices that are connected to the bus. A Physical Device Object (PDO) represents a device on a bus to a bus driver.
  2. Function drivers

    The one driver in the stack that communicates directly with the device is called the function driver. A function driver is the main driver for a device. A function driver is typically written by the device vendor and is required (unless the device is being used in raw mode. The PnP manager loads at most one function driver for a device. A function driver can service one or more devices. The function driver for a device can be implemented as a driver/minidriver pair, such as a port/miniport driver pair or a class/miniclass driver pair. In such driver pairs, the minidriver is linked to the second driver, which is a DLL. In a minidriver model, the device driver consists of two parts: one that handles general tasks, and one that handles device-specific tasks. Typically, Microsoft writes the general portion and the device manufacturer writes the device-specific portion. A Functional Device Object (FDO) represents a device to a function driver.
  3. Filter drivers

    The drivers that perform auxiliary processing are called filter drivers. Filter drivers are optional drivers that add value to or modify the behavior of a device, a class of devices, or a bus. Bus filter drivers typically add value to a bus. Lower-level filter drivers typically modify the behavior of device hardware. Upper-level filter drivers typically provide added-value features for a device. A Filter Device Object (filter DO) represents a device to a filter driver.


3. Runtime Environment

Hardware Abstraction Layer

The Windows hardware abstraction layer (HAL) refers to a layer of software that deals directly with your computer hardware. Because the HAL operates at a level between the hardware and the Windows executive services, applications and device drivers need not be aware of any hardware-specific information. The HAL provides routines that enable a single device driver to support a device on different hardware platforms, making device driver development much easier. It hides hardware dependent details such as I/O interfaces, interrupt controllers, and multiprocessor communication mechanisms. Applications and device drivers are no longer allowed to deal with hardware directly and must make calls to HAL routines to determine hardware specific information. Thus, through the filter provided by the HAL, different hardware configurations can be accessed in the same manner. HAL is implemented via the kernel-mode hal.dll module. All Windows components access hardware via the HAL, and multiple HALs are available that are specific to different hardware platforms with the installed HAL chosen when the OS is installed.

Windows Kernel Executive Layer

The Windows operating system uses the term executive layer to refer to kernel-mode components that provide a variety of services to device drivers, including Object management, Memory management, Process and thread management, Input/output management, Configuration management. The executive layer components are part of Ntoskrnl.exe, but that drivers and the HAL are not part of the executive layer.
  1. Kernel-mode Object manager
    The Windows kernel-mode object manager component manages the creation, tracking, access control, destruction, and recycling resource space for Windows objects like Files, Devices, Threads, Processes, Events, Mutexes, Semaphores, and Registry keys.
  2. Kernel-mode Memory manager
    The Windows kernel-mode memory manager component manages physical memory for the operating system. This memory is primarily in the form of random access memory (RAM). The memory manager manages memory by managing the allocation and deallocation of memory virtually and dynamically, and supporting the concepts of memory-mapped files, shared memory, and copy-on-write.
  3. Kernel-mode Process and Thread manager
    The Windows kernel-mode process and thread manager handles the execution of processes having one or more threads on Windows and the synchronization of resources amongst the same.
  4. Kernel-mode I/O manager
    The Windows kernel-mode I/O manager manages the communication between applications and the interfaces provided by device drivers.The I/O manager has two subcomponents
  5. Plug and Play manager
    Plug and Play manager
    The Plug and Play (PnP) manager provides the support for PnP functionality in Windows and is responsible for Device detection and enumeration while the system is booting, and adding or removing devices while the system is running. The PnP manager maintains the Device Tree that keeps track of the devices in the system. The device tree contains information about the devices present on the system. When the computer starts, the PnP manager builds this tree by using information from drivers and other components, and updates the tree as devices are added or removed.
    The PnP manager has two parts:
    1. The Kernel-mode PnP manager interacts with operating system components and drivers to configure, manage, and maintain devices. The kernel-mode PnP manager notifies the user-mode PnP manager that a new device is present on the system and must be installed. The kernel-mode PnP manager also calls the DriverEntry and AddDevice routines of a device's driver and sends the IRP_MN_START_DEVICE request to start the device.
    2. The User-mode PnP manager interacts with user-mode setup components, such as Class Installers, to configure and install devices. The user-mode PnP manager also interacts with applications to, for example, register an application for notification of device changes and notify the application when a device event occurs. The user-mode PnP manager receives device installation requests from the kernel-mode PnP manager, calls other user-mode components to start device installation tasks, and sends control requests (such as "start the device") to the kernel-mode PnP manager. The user-mode PnP manager tries to install a device in a trusted process context without requiring users to respond to dialog boxes. This method is known as a server-side installation.
  6. Kernel-mode power manager
    The Windows kernel-mode power manager manages the orderly change in power status for all devices that support power state changes. This is often done through a complex stack of devices controlling other devices. Each controlling device is called a node and must have a driver that can handle the communication of power state changes up and down through a device stack. The power manager works in combination with policy management to handle power management and coordinate power events, and then generates power management IRPs. The power manager collects requests to change the power state, decides which order the devices must have their power state changed, and then send the appropriate IRPs to tell the appropriate drivers to make the changes (which in turn may tell subdevices to make the change as well). The policy manager monitors activity in the system and integrates user status, application status, and device driver status into power policy.


4. Device and Driver Stack

The WDM drivers are layered in a vertical calling sequence that is called a driver stack. Because devices operate at speeds that may not match the operating system, the communication between the operating system and device drivers is primarily done through I/O request packets (IRPs). These packets are similar to network packets or Windows message packets. They are passed from operating system to specific drivers and from one driver to another.The topmost driver in the stack typically receives I/O requests from user applications, after the requests have passed through the operating system's I/O manager. The lower driver layers typically communicate with computer hardware. Frequently several drivers participate in a single I/O request (like reading data from a device). The drivers are layered in a stack, and the conventional way to visualize the stack is with the first driver at the top and the last driver at the bottom. The stack has one function driver and can also have filter drivers. Windows operating system communicates with drivers by sending I/O request packets (IRPs). The Windows I/O system provides a layered driver model called stacks. Typically IRPs go from one driver to another in the same stack to facilitate communication. For example, a joystick driver would need to communicate to a USB hub, which in turn would need to communicate to a USB host controller, which would then need to communicate through a PCI bus to the rest of the computer hardware. The stack consists of joystick driver, USB hub, USB host controller, and the PCI bus. This communication is coordinated by having each driver in the stack send and receive IRPs.

Each driver stack supports one or more device stacks. Each device stack represents one device. Each driver creates a device object for each of its devices and attaches each device object to a device stack. Device stacks are created and removed as devices are plugged in and unplugged, and each time the system is rebooted.


5. Driver Services

A service is an application that runs as a background process, rather than being under the direct control of an interactive user. Services are long-running executable applications that run in their own Windows sessions and execute even when no user is logged on to the system. Services run in the security context of three predefined user accounts - System, Network Service and Local Service, or any specific user account that may be different from the logged-on user or the default computer account.

A service application conforms to the interface rules of the Service Control Manager (SCM). It can be started automatically at system boot, by a user through the Services control panel applet, or by an application that uses the service functions. A driver service conforms to the device driver protocols. It is similar to a service application, but it does not interact with the SCM.

The HKLM\SYSTEM\CurrentControlSet\Services registry Key stores information about each service on the system that govern the startup and running of Windows Services.

  1. ServiceType Specifies the type of service as follows:
    1. SERVICE_KERNEL_DRIVER (0x1) - Kernel device driver.
    2. SERVICE_WIN32_OWN_PROCESS - Microsoft Win32 service that is installed for a device.
    3. SERVICE_WIN32_SHARE_PROCESS (0x20) - A Win32 service that can share a process with other Win32 services.
    4. SERVICE_INTERACTIVE_PROCESS - Win32 service which can interact with the desktop.
    5. SERVICE_FILE_SYSTEM_DRIVER - Highest level network driver, such as a redirector, or a file system driver.
  2. ServiceName Each driver has a key of the form HKLM\SYSTEM\CurrentControlSet\Services\DriverName. The PnP manager passes this path of a driver in the RegistryPath parameter when it calls the driver's DriverEntry routine. A driver can store global driver-defined data under its key in the Services tree. Information that is stored under this key is available to the driver during its initialization.
  3. DisplayName Specifies a friendly name for the service/driver



  4. Description. This string gives the user more information about the service



  5. StartType Specifies when to start the driver. SERVICE_BOOT_START Indicates a driver started by the operating system loader. This value must be used for drivers of devices required for loading the operating system. SERVICE_SYSTEM_START Indicates a driver started during operating system initialization. This value should be used by PnP drivers that do device detection during initialization but are not required to load the system. SERVICE_AUTO_START Indicates a driver started by the service control manager during system startup. This value should never be used in the INF files for WDM or PnP device drivers. SERVICE_DEMAND_START Indicates a driver started on demand, either by the PnP manager when the corresponding device is enumerated or possibly by the service control manager in response to an explicit user demand for a non-PnP device. This value should be used in the INF files for all WDM drivers of devices that are not required to load the system and for all PnP device drivers that are neither required to load the system nor engaged in device detection. SERVICE_DISABLED Indicates a driver that cannot be started. This value can be used to temporarily disable the driver services for a device. However, a device/driver cannot be installed if this value is specified in the service-install section of its INF file.



  6. Dependencies Each depend-on-item-name item in a dependencies list specifies the name of a service or load-order group on which the device/driver depends. If the depend-on-item-name specifies a service, the service that must be running before this driver is started. A depend-on-item-name can specify a load order group on which this device/driver depends. Such a driver is started only if at least one member of the specified group was started.



  7. ImagePath A value entry that specifies the fully qualified path of the driver's image file. Windows creates this value by using the required ServiceBinary entry in the driver's INF file. This entry is in the service-install-section referenced by the driver's INF AddService directive. A typical value for this path is %SystemRoot%\system32\Drivers\DriverName.sys, where DriverName is the name of the driver's Serviceskey.



  8. Parameters A key that is used to store driver-specific data. For some types of drivers, the system expects to find specific value entries. You can add value entries to this subkey using AddReg entries in the driver's INF file.



  9. Performance A key that specifies information for optional performance monitoring. The values under this key specify the name of the driver's performance DLL and the names of certain exported functions in that DLL. You can add value entries to this subkey using AddReg entries in the driver's INF file.



Specifying Driver Load Order

The operating system loads drivers according to the service-install-section StartType value, as follows:
  • During the system boot start phase, the operating system loads all (SERVICE_BOOT_START) drivers.
  • During the system start phase, the operating system first loads all WDM and PnP drivers for which the PnP manager finds device nodes (devnodes) in the registry ..\Enum tree (whether their INF files specify SERVICE_SYSTEM_START or SERVICE_DEMAND_START).Then the operating system loads all remaining SERVICE_SYSTEM_START drivers.
  • During the system auto-start phase, the operating system loads all remaining SERVICE_AUTO_START drivers.

6. Device Interface Classes

Device Interface Classes are used to group devices together that provide similar capabilities. Any driver of a physical, logical, or virtual device to which user-mode code can direct I/O requests must supply some sort of name for its user-mode clients. Using the name, a user-mode application (or other system component) identifies the device from which it is requesting I/O. A device interface class is a way of exporting device and driver functionality to other system components, including other drivers, as well as user-mode applications. A driver can register a device interface class, then enable an instance of the class for each device object to which user-mode I/O requests might be sent. Device interface classes provide a mechanism for grouping devices according to shared characteristics. Instead of tracking the presence in the system of an individual device, drivers and user applications can register to be notified of the arrival or removal of any device that belongs to a particular interface class. Definitions of interface classes are not provided in a single file. A device interface class is always defined in a header file that belongs exclusively to a particular class of devices. For example, Ntddmou.h contains the definition of GUID_CLASS_MOUSE, the GUID representing the mouse interface class; Ntddpar.h defines the interface class GUID for parallel devices;Ntddpcm.h defines the standard interface class GUID for PCMCIA devices;Ntddstor.h defines the interface class GUID for storage devices, and so on. The GUIDs in header files that are specific to the device interface class should be used to register for notification of arrival of an instance of a device interface. If a driver registers for notification using a setup class GUID instead of an interface class GUID, then it will not be notified when an interface arrives. Each device interface class is associated with a GUID. The system defines GUIDs for common device interface classes in device-specific header files. Vendors can create additional device interface classes. For example, three different types of mouse devices could be members of the same device interface class, even if one connects through a USB port, a second through a serial port, and the third through an infrared port. Each driver registers its device as a member of the interface class GUID_DEVINTERFACE_MOUSE. Typically, drivers register for only one interface class. However, drivers for devices that have specialized functionality beyond that defined for their standard interface class might also register for an additional class. For example, a driver for a disk that can be mounted should register for both its disk interface class (GUID_DEVINTERFACE_DISK) and the mountable device class (MOUNTDEV_MOUNTED_DEVICE_GUID). When a driver registers an instance of a device interface class, the I/O manager associates the device and the device interface class GUID with a symbolic link name. The link name is stored in the registry and persists across system starts. An application that uses the interface can query for instances of the interface and receive a symbolic link name representing a device that supports the interface. The application can then use the symbolic link name as a target for I/O requests. If a driver exports the functionality of a device interface class, therefore creating a new instance of the interface class, such as kernel-streaming still-image capture or data decompression, its INF file can have this section. Device interfaces are available to both kernel-mode components and user-mode applications. Registers device functionality (a device interface) for a device. Retrieves information about an existing device interface and adds it to the specified device information set. Device interface classes are the methods available to applications for accessing the capabilities of a device driver. They indicate to whatever receives notifications that a particular interface is present. A device driver can have multiple device interface classes, or it can have no device interface classes. HKLM\SYSTEM\CurrentControlSet\Control\DeviceClasses Contains information about the device interfaces on the system. There is a subkey for each device interface class and entries under those subkeys for each instance of an interface that is registered for the device interface class. Battery and ACPI devices, Bluetooth devices, Display and Image devices, Interactive Input devices, Modem devices, Network devices, Serial and Parallel Port devices, Storage devices

7. Device Identifiction Strings

Windows uses the following device identification strings to locate the information (INF) file that best matches the device. These strings are reported by a device's enumerator. Windows tries to find a match for one of the hardware IDs or compatible IDs. In addition to using the preceding IDs to identify devices, the PnP manager uses the following IDs to uniquely identify instances of each device that are installed in a computer: Each enumerator customizes its device IDs, hardware IDs, and compatible IDs to uniquely identify the device that it enumerates. In addition, each enumerator has its own policy to identify hardware IDs and compatible IDs. Device Identifier Formats. Most, but not all, identifier strings are bus-specific. The Plug and Play (PnP) manager also supports a set of generic device identifiers for devices that can appear on many different buses.
Hardware ID A hardware ID is a vendor-defined identification string that Windows uses to match a device to an INF file. In most cases, a device has associated with it a list of hardware IDs.
Compatible ID A compatible ID is a vendor-defined identification string that Windows uses to match a device to an INF file. A device can have associated with it a list of compatible IDs. The compatible IDs should be listed in order of decreasing suitability. If Windows cannot locate an INF file that matches one of a device's hardware IDs, it uses compatible IDs to locate an INF file.
Instance ID An instance ID is a device identification string that distinguishes a device from other devices of the same type on a computer. An instance ID contains serial number information, if supported by the underlying bus, or some kind of location information.
Device instance ID A device instance ID is a system-supplied device identification string that uniquely identifies a device in the system. The Plug and Play (PnP) manager assigns a device instance ID to each device node (devnode) in a system's device tree.
Container ID A container ID is a system-supplied device identification string that uniquely groups the functional devices associated with a single-function or multifunction device installed in the computer. Starting with Windows 7, the PnP manager uses the Container ID device identification string to group one or more device nodes (devnodes) that were enumerated from each instance of a physical device installed in a computer.

8. Driver Package

A driver package consists of all the software components that you must supply in order for your device to be supported under Windows. Installing a device or driver involves system-supplied and vendor-supplied components. The system provides generic installation software for all device classes. Vendors must supply one or more device-specific components within the driver package. The following components are necessary to install and support a device on a Windows operating system:

Driver Files

Driver Files The driver is the part of the package that provides the I/O interface for a device. Typically, a driver is a dynamic-link library (DLL) with the .sys file name extension. Long file names are allowed, except for boot-start drivers. When a device is installed, Windows copies the .sys file to the %SystemRoot%\system32\drivers directory. The software that is required to support a particular device depends on the features of the device and the bus or port to which it connects. Microsoft ships drivers for many common devices and nearly all buses with the operating system. If your device can be serviced by one of these drivers, you might have to write only a device-specific minidriver. A minidriver handles device-specific features on behalf of a system-supplied driver. For some types of devices, even a minidriver is not necessary. For example, modems can typically be supported with just installation files.

Device setup information (INF file)

An INF file contains information that the system Windows components use to install support for the device. Windows copies this file to the %SystemRoot%\inf directory when it installs the driver. An INF file is a text file that contains all the information necessary to install a device, such as Manufacturer and device model information, driver names and locations, registry information, version information, and other installation information that is used by the Setup components. Windows INF files do not contain installation scripts. The installation procedures are part of a Microsoft Win32 installer application with INF file acting only as a resource.

Driver Catalog (.cat) file

Windows device installation uses digital signatures to verify the integrity of driver packages and to verify the identity of the vendor (software publisher) who provides the driver packages. A driver catalog file contains a cryptographic hash of each file in the driver package. Windows uses these hashes to verify that the package was not altered after it was published. To ensure that the catalog file is not altered, it should be digitally signed and a driver catalog file contains digital signatures. A vendor obtains digital signatures by submitting its driver package to the Windows Hardware Quality Lab (WHQL) for testing and signing. WHQL returns the package with a catalog file (.cat file).

Device setup classes

Used to group devices together that are installed and configured in a similar manner. To facilitate device installation, devices that are set up and configured in the same manner are grouped into a device setup class. The device setup class defines the class installer and class co-installers that are involved in installing the device. Microsoft defines setup classes for most devices. IHVs and OEMs can define new device setup classes, but only if none of the existing classes apply. There is a GUID associated with each device setup class. The device setup class GUID defines the ..\CurrentControlSet\Control\Class\ClassGuid registry key under which to create a new subkey for any particular device of a standard setup class. Device setup classes provide a mechanism for grouping devices that are installed and configured in the same way. A setup class identifies the class installer and class co-installers that are involved in installing the devices that belong to the class. For example, all CD-ROM drives belong to the CDROM setup class and will use the same co-installer when installed.Windows classes are defined in the system file Devguid.h. This file defines a series of GUIDs for setup classes. HKLM\SYSTEM\CurrentControlSet\Control\Class Contains information about the device setup classes on the system. There is a subkey for each class that is named using the GUID of the setup class. Each subkey contains information about a setup class, such as the class installer (if there is one), registered class upper-filter drivers, and registered class lower-filter drivers. Each class subkey contains other subkeys known as software keys (or, driver keys for each device instance of that class installed in the system. Each of these software keys is named by using a device instance ID, which is a base-10, four-digit ordinal value.

Class installer

Required only for new device setup classes; system-supplied for existing classes. As a rule, vendors should not define new setup classes, and should not supply class installers. If a to-be-installed component, such as a new class driver, provides one or more new device interface classes to higher-level components, its INF file has this section. In effect, this section bootstraps a set of device interfaces for a new class by setting up whatever is needed to use the functionality that the interface class provides. A class installer DLL performs installation operations that apply to devices in a particular device setup class. For example, the system-supplied Ports class installer is responsible for assigning a COM port name to a device in the Ports setup class. If the devices in a particular setup class do not require any special installation operations, a class installer is not required for that setup class. Microsoft provides class installers for the system-supplied device setup classes that require a class installer. For devices that belong to these setup classes, a vendor can provide a co-installer to perform additional setup operations, if needed. If you create a new device setup class for your device, you might have to write a class installer. However, you rarely have to create a new device setup class because most devices can be associated with one of the system-supplied device setup classes. For example, the maker of a digital camera might think that digital cameras require a new setup class. However, cameras fall under the image class.

Co-installers

A co-installer is an optional Microsoft Win32 DLL that supplements the operations of the system's device installer or of an existing device class installer and assists in device installation on Windows operating systems. A co-installer typically writes additional configuration information to the registry or performs other installation tasks that require dynamically generated, system-specific information that is not available when an INF is created. A device-specific co-installer supplements the installation operations either of the OS's device installer or of the appropriate class installer when that device is installed. Co-installers are called by SetupAPI as "helpers" for Class Installers. For example, a vendor can provide a co-installer to write device-specific information to the registry that cannot be handled by the INF file. The registry key HKLM\SYSTEM\CurrentControlSet\Control\CoDeviceInstallers Contains information about the class-specific co-installers that are registered on the system.
  1. Device co-installer
    A device co-installer handles custom installation requirements for a specific device or family of devices. Required if installation requires information from the user or from the registry. Often supplied by vendors. On the other hand, vendors often supply device co-installers. You should write a device co-installer if you have to display property pages or custom Finish pages during device or driver installation.
  2. Class co-installer
    A class co-installer performs identical actions for every device in its class. Required only if installation of all devices of this class requires information from the user or from the registry. System-supplied for classes that require them; vendors should rarely supply them. Microsoft supplies class co-installers for classes that require them; third parties seldom do.

Driver Store

The driver store is a trusted collection of inbox and third-party driver packages. The operating system maintains this collection in a secure location on the local hard disk. Only the driver packages in the driver store can be installed for a device. When a driver package is copied to the driver store, all of its files are copied. This includes the INF file and all files that are referenced by the INF file. All files that are in the driver package are considered critical to the device installation. The INF file must reference all of the required files for device installation so that they are present in the driver store. If the INF file references a file that is not included in the driver package, the driver package is not copied to the store. The process of copying a driver package to the driver store is called staging. A driver package must be staged to the driver store before the package can be used to install any devices. As a result, driver staging and device installation are separate operations. A driver package is staged to the driver store by being verified and validated: Verifying the driver package integrity. Software integrity has become a top priority for IHVs and OEMs. Concerned by the increase in malicious software on the Internet, these customers want to be sure that their software has not been tampered with or corrupted. Before a driver package is copied to the driver store, the operating system first verifies that the digital signature is correct. Validating the driver package. The operating system validates the driver package in the following ways: The current user must have permission to install the driver package. The INF file of the driver package is syntactically correct, and all files referenced by the INF files are present in the driver package. After a driver package has passed integrity and syntax checks, it is copied to the driver store. Afterwards, the operating system uses the driver package to automatically install new devices without requiring user interaction.

Other files

A driver package can contain other files, such as a custom device installation application recommended when value-added software is provided with device and driver, or when a driver replaces a previous driver that might already be installed, a device icon, or a driver library file (such as for video drivers). The same can also include Device and Driver Installation software - the various software components that can be optionally developed to enhance device and driver installations like Wizard Pages, Device Property Pages.

9. Driver Installation

Windows provides components to install devices and drivers. The system-provided device installation components work with vendor-supplied components to install devices. Windows installs devices when the system restarts and at any time after a system restart when a user plugs in a Plug and Play (PnP) device (or manually installs a non-PnP device).
  1. Device Identification

    Before a driver is installed for a new device, the bus or hub driver to which the device is connected assigns a hardware identifier ID to the device. The Windows Plug and Play (PnP) manager uses hardware IDs to find the closest match between a device and a driver package that contains the driver for the device.
  2. Driver Selection

    After a new device is detected and identified, using the hardware identifier (ID) that is reported by the bus or hub driver, Windows searches for driver packages that match a device hardware ID or compatible ID in the driver package and selects the most appropriate driver for the device from one or more driver packages.
  3. Device Enumeration

    device tree
    Windows represents each device instance as a unique device node (devnode). The PnP manager creates a devnode for each device on a machine and the devnodes are organized into a hierarchical Device Tree. A devnode contains the device stack (the device objects for the device's drivers) and information about the device such as whether the device has been started and which drivers have registered for notification on the device. Windows represents a driver for the device as a driver node. A driver node includes all the software support for a device, such as any services, device-specific co-installers, and registry entries based on the information from the driver package. The HKLM\SYSTEM\CurrentControlSet\Enum registry tree contains information about the devices on the system. The PnP manager creates a subkey for each device, with a name in the form of HKLM\SYSTEM\CurrentControlSet\Enum\Enumerator\deviceID. Under each of these keys is a subkey for each device instance present on the system. This subkey, which is known as the device's hardware key (or, device key), has information such as the device description, hardware IDs, compatible IDs, and resource requirements. The Enum tree is reserved for use by operating system components, and its layout is subject to change.
  4. Driver Installation

    Windows copies the driver binaries and other associated files to the hard disk and registers any device-specific co-installer. Windows determines the device setup class from the driver package INF file. To optimize device installation, the devices that are set up and configured in the same manner are grouped into the same device setup class which contains system configuration information about a setup class, such as the class installer (if there is one), the registered class device drivers and services, the upper-filter drivers, and registered class lower-filter drivers. Microsoft defines the setup classes for most devices with a GUID associated with each class. The information is stored under the registry key HKLM\System\CurrentControlSet\Control\Class\ClassGuid.
  5. Driver Startup

    The PnP manager loads the appropriate function driver and any optional filter drivers for the device and starts the device.

No comments:

Post a Comment