Managing Windows services and drivers. Device driver management. Managing Boot Drivers Using Selection Profiles

The order of loading drivers and services in Windows

For those who are interested in the inner workings of the Windows operating system, I suggest a little research. We will try to find out what is responsible for the order in which drivers and services are loaded in Windows and whether this order can be changed.

First of all, let's look at the current system startup order using the LoadOrder program from Sysinternals. The program will show us what is loaded and in what order when the operating system starts.

As can be seen from the figure, first the device drivers necessary to start the system are loaded, and then various Windows services. Since there are some differences between loading services and loading drivers, we will consider them separately.

Drivers

As a test subject, let's take the Microsoft ACPI (Advanced Configuration and Power Interface) driver, which is responsible for hardware detection and power management. ACPI's job is to enable communication between the operating system and the hardware, so the ACPI driver is loaded at the very beginning.

The Loadorder program provides rather limited information about the loading order, so we go to the registry for more accurate data. Each driver and Windows service has its own section in the registry branch HKLM\SYSTEM\CurrentControlSet\Services. The sections are named after the driver\service name, so we need the ACPI section.

Three registry parameters control the order in which the driver is loaded. Main parameter Start- determines the driver startup type. Here are the rules by which drivers set the value of their Start parameter:

Drivers that should loaded by the system bootloader when the operating system starts, indicate the value Start equal 0 (launch on system boot ). An example is system bus drivers and a file system driver used when the system boots;
Driver that not required directly to boot the system, points to Start value equal to 1 (system startup ). Example - standard video card driver (VgaSave);
Driver, not required for system boot, sets the value Start equal 2 (autostart). An example is a driver for a Multiple UNC Provider (MUP) that supports UNC names of remote resources (type );
Drivers, not required for the operating system to function(for example, network adapter drivers), indicate the value Start equal 3 (launch on demand ).

Device drivers can also use parameters Group And Tag to control your boot order when the system starts. Drivers\services use the Group parameter to indicate the group to which they belong, and the order in which the groups are loaded is determined by the parameter List, located in the HKLM\SYSTEM\CurrentControlSet\Control\ServiceGroupOrder\ section.

By the way, the Group parameter is not required. If the driver\service is not included in any group, then it is loaded at the very end of the queue.

A driver can further refine its loading order by using the Tag parameter, which specifies the driver's specific position in the group. The I/O Manager sorts the drivers in the group by the value of this parameter, and drivers that do not have a Tag parameter are moved to the bottom of the list of drivers in the group.

Looking at the loading order, you might think that drivers with smaller Tag values are loaded first, then those with larger ones, but this is not entirely true. The priority of Tag parameter values within a group is determined in the HKLM\SYSTEM\CurrentControlSet\Control\GroupOrderList section.

For example, let's open the Boot Bus Extender binary parameter, which corresponds to the group of the same name, to which the ACPI driver belongs. The parameter is a set of double words (4 bytes each). The first word (highlighted in red) specifies the total length of the variable (the number of double words), in our example 06. The remaining double words are just tags. The ACPI driver has a tag equal to 01 (highlighted in green).

The priority of a tag is determined not by the value of the tag, but by its position: the higher the tag is located, the higher its priority in the group, and the higher the priority of the driver to which this tag corresponds. And since 01 is higher than the other tags, the ACPI driver is loaded first in the group.

Services

The order in which Windows services are loaded is somewhat different from the order in which drivers are loaded. Let's take the automatic update service (wuauserv) as an example. It is not particularly critical for the operation of the system and therefore is loaded last.

Let's go to the registry again. The service startup parameters are located in the HKLM\SYSTEM\CurrentControlSet\Services\wuauserv section. I have identified two main parameters that are responsible for the loading order of this service.

Windows services are started by the Service Control Manager (SCM) according to the parameter value Start. This parameter for services can take the following values:

Auto start (2) - the service starts automatically, immediately after the main SCM process Services.exe starts;
Launch on demand (3) - the service starts when necessary, at the request of any service or program;
Disabled (4) - the service is disabled and will not start under any circumstances.

The values 0 (start at system boot) and 1 (start by system) for services cannot be specified, only for device drivers.

In addition, starting with Windows Vista\Server 2008, another launch mode appeared for services - delayed autostart. The parameter is responsible for it DelayedAutoStart = 1, which tells the SCM to automatically start this service with a delay. SCM starts services that are set to delayed startup after the services that are marked for autostart have loaded.

The service launch mode can be controlled not only from the registry, but also in graphical mode, from the Services console.

Just like drivers, Windows services can use the Group parameter in their registry key to indicate the group to which they belong. Now, for clarity, let’s take our wuauserv service, located at the very end of the download list. Using the Group key, we will place it in the Event Log group, reboot and look at the loading order in Loadorder. As you can see, the order has changed and wuauserv has risen from last place, loading immediately after its classmate - the eventlog service. True, the placement order within the group cannot be changed, because Tag is not used for services.

And one more parameter that indirectly affects the order in which services are loaded - DependOnService. It indicates which services the service depends on. Accordingly, the service is not loaded until the services listed in DependOnService are loaded.

Dependencies work as follows - if services are in the same group, then the dependent service is moved to the end of the list and starts after the services on which it depends. If the groups are different, then the service simply will not start, and SCM will generate an error.

This is shown more clearly in the Services snap-in, where the Dependency tab lists both the services on which a given service depends and the services that depend on it.

So we found out in what order drivers and services are loaded in Windows and how this order can be changed. But before you rush to edit the registry, remember that the order in which drivers and services are loaded is determined automatically, and you should not make changes to it without a good reason. Just one incorrectly set parameter can lead to complete system inoperability, and there is no guarantee that it will be possible to restore it. Therefore, before you start editing the registry, be sure to make a backup copy of it, and it is also advisable to have bootable media on hand.

In the previous part of this series, we looked at two approaches ("let Windows decide" and "let me decide") that can be used to manage external drivers when performing a Lite Touch installation using MDT 2010. In this part, we will conclude the conversation about the problem of driver management , here will be some tips, tricks and a story. The first story was provided to me by one of our readers, Tim Lors, and is a great visual example of the problems you may encounter when trying to manage drivers during installation:

"Over a year ago, I wrote a software script that installs all the drivers on a WinXP PC. The problem I encountered when selecting drivers was not OS related. It was the manufacturer's failure to properly implement PnP between their driver inf files and the hardware itself More precisely, the inf file indicated that it was the best driver for a certain hardware device, when, in fact, it did not work with such a device. The only way to select a suitable driver in such a difficult situation was to compare the PnP identification numbers of the hardware. with a list of known problematic drivers, and if I found a match, I manually selected the appropriate driver based on additional criteria, usually the PC model number. The most common additional criteria required for "let me decide" selection was the PC model number, but sometimes included BIOS version and PnP subset ID, and in some rare cases it was trial and error. Of course, trial and error is quite difficult, because when Windows installed the driver that it considered most suitable, it had to isolate the non-working driver from Windows, or the system simply reinstalled it. Please note that this situation occurred in an environment containing nearly 10,000 PCs across more than 25 different models."

Most IT professionals I've talked to have told me that drivers are one of the biggest headaches, and the above story just goes to show that. So, having devoted the last four parts to this topic, I want to end the discussion of drivers with some tips and tricks that will help make your life easier.

Search for drivers

The first challenge is finding the freelance drivers your systems may require. Some manufacturers make this easy, others don't, and Dell is part of the first group because it provides drivers for every desktop system in the form of a .cab file for every operating system. To download these .cab files, go to http://www.delltechcenter.com/ and from the scrolling menu on the left, select Home, Microsoft, Microsoft System Center, SCCM " System Center Configuration Manager, Dell Business Client Operating System Deployment, Dell Business Client Operating System Deployment " The .CAB Files and you will see the page shown in Figure 1:

Figure 1: Downloading drivers for Dell client systems as .cab files

Once the .cab file is downloaded, you can extract it to a folder, then reference that folder when importing drivers into your installation share.

Other manufacturers also provide tools for downloading drivers, but in my opinion these tools are not as simple or convenient as Dell's approach. Here are some examples of such tools and links to them:

Extracting INF files from EXE

Sometimes system manufacturers provide device drivers in the form of .exe files rather than .cab files. In this case, an excellent set of tools is WinRAR, which allows you to extract driver files from an .exe file into a folder. Remember, in order to import a driver, MDT requires an .inf file and corresponding driver files; it is not possible to import an .exe file as a driver.

Preventing drivers from turning on

To prevent a driver you imported from being enabled (for example, if your tests show that the driver is causing problems after installation), simply open the driver properties and clear the Enable This Driver field (Figure 2):

Figure 2: You can disable or allow the driver to be enabled

Please note that the above driver was designed for 32-bit and 64-bit Windows. If you find that it doesn't work under 64-bit Windows, you can leave the driver enabled but uncheck x64, which will prevent it from being enabled during a 64-bit Windows installation.

If you wish, you can even disable all drivers in a folder by disabling the folder (Figure 3):

Figure 3: You can disable a custom folder in the installation resource

Managing Boot Drivers Using Selection Profiles

You can also use selection profiles to manage drivers during the Windows PE boot phase of an LTI installation. To do this, open the properties of your installation resource and select the Windows PE x64 Components or Windows PE x86 Components tab to manage drivers for the architecture of the OS you are installing (Figure 4):

By default, the All Drivers And Packages selection profile is selected, but only the network and storage drivers from this selection profile are included in the Windows PE boot image. If necessary, you can create your own selection profile that will include WinPE hardware-specific drivers for your target systems.

Using multiple driver groups to install by make and model

In the previous part, we looked at how to define one driver group called DriverGroup001 and use it to manage drivers during installation based on the make and model of the target computers. Keith Garner, System Deployment Specialist at Xtreme Consulting Group, has an excellent post that gives more information on this topic, and shows you how you can organize drivers more efficiently, and then use multiple driver groups to manage how they are enabled during installation.

Another useful post is this post on using model aliases, written by Michael Mergolo, Senior Consultant at Microsoft Consulting Services.

Adding drivers to the image

You can use the DISM.exe command to add drivers to offline images; simply mount the image and use the DISM command with the /add-driver option (see for more information on using DISM.exe).

To add drivers to the driver store (that is, pre-represent drivers so that they are available when Windows identifies devices that need drivers), you can use the PnPutil.exe command. This command can be useful if, for example, you used the Microsoft Update Catalog to download a .cab file of printer drivers and want to pre-present those drivers on your reference computer so that those drivers are available during installation. More information about this command can be found in and.

Maintaining Driver Configuration During Windows Imaging

Finally, if you create a reference image and install it on identical hardware, you can provide a faster first-time boot experience for users by configuring the PersistAllDeviceInstalls parameters in your response file to sysprepping your reference machine. See details

Devices and drivers for them are divided into two categories: with and without PnP support. For most PnP devices, a driver is included on the Windows Server 2003 CD. When you install a new device, the system automatically finds a driver for it and allocates resources for it (IRQs and DNA direct memory access channels). If the system cannot find a suitable driver, it will prompt the user for it, and the device in the Task Manager console will be marked with an exclamation mark in a yellow triangle. If the system is unable to determine the device type at all, then a driver request is not issued and the device is marked with a question mark in a yellow triangle as unknown.

To update device configurations, use the Device Manager snap-in. It can be used in two forms: with a device tree, with a resource tree for devices (manually setting up resources is not recommended). The Device Manager snap-in can be used to edit the configuration only on the local computer; on the remote computer it works in read-only mode. To get a detailed summary of devices and drivers, you can use the DriverQuery command line utility.

Computer administrators can install any devices and drivers. Regular users can install drivers in the following cases: the driver is digitally signed, the driver files are already on the computer and further installation does not require additional user intervention, and all three conditions must be met simultaneously (these conditions are usually true for printers, USB- devices and for the IEE1394 bus).

Starting with Windows 2000, device drivers have a digital signature that shows that the file has not been modified during use. Some drivers may not be digitally signed. If the driver is not signed, you can configure three options for the system to act: Skip (install the driver even if there is no signature. Available only for the administrator), Warn (ask the user whether to install the driver), Block (does not install drivers without a digital signature).

In the Device Manager snap-in, you can update drivers for the selected device (for example, if the manufacturer has released a new version). If, after installing a new driver, problems arise in the operation of the device, you can return to the previous version of the driver by clicking the Rollback button. You can also delete drivers for devices (if it is a PnP device, deleting the driver will entail deleting the device itself; if the device driver was added manually, it will remain in the system, but without a configured driver. If the device has additional properties with which you can configure it, they will be accessed with the same rights as the Task Manager. You can also restrict access to such settings using Group Policy.

If problems arise with the operation of devices, you can use the following means: returning the previous version of the driver (if the system boots), loading the last successful configuration (will work if the problem occurred before the last successful login), safe mode (loads a minimum set of drivers and subsystems ( after booting, you can disable it in Device Manager), recovery console (used if all of the above does not have an effect, allows you to manage devices and drivers from the command line, but you need to know the device name or driver file. When device errors occur, codes are displayed in Device Manager). states that allow you to determine the type of error. A description of the codes can be found in the Windows help system.

For those who are interested in the internal structure of the operating system, I suggest a little research. We will try to find out what is responsible for the order in which drivers and services are loaded and whether this order can be changed.

First of all, let's look at the current system startup order using the LoadOrder program from Sysinternals. The program will show us what is loaded and in what order when the operating system starts.

As can be seen from the figure, first the device drivers necessary to start the system are loaded, and then various services. Since there are some differences between loading services and loading drivers, we will consider them separately.

Drivers

Let's take the driver as a test subject. Microsoft ACPI (Advanced Configuration and Power Interface), which is responsible for hardware discovery and power management. ACPI's job is to enable communication between the operating system and the hardware, so the ACPI driver is loaded at the very beginning.

Drivers that must be loaded by the boot loader when the operating system starts specify a Start value of 0 (start at system boot). An example is system bus drivers and a file system driver used when the system boots;
A driver that is not directly required to boot the system specifies a Start value of 1 (started by the system). Example - standard video card driver (VgaSave);
The driver, which is not required to boot the system, sets the Start value to 2 (autostart). An example is a driver for a Multiple UNC Provider (MUP) that supports UNC names of remote resources (such as \\Computer\Share);
Drivers that are not required for the operating system to function (for example, network adapter drivers) specify the Start value as 3 (start on demand).

Device drivers can also use parameters Group And Tag to control your boot order when the system starts. Drivers\services use the Group parameter to indicate the group to which they belong, and the order in which the groups are loaded is determined by the parameter List located in the HKLM\SYSTEM\CurrentControlSet\Control\ServiceGroupOrder\ section.

By the way, the Group parameter is not required. If the driver\service is not included in any group, then it is loaded at the very end of the queue.

The driver can further fine-tune its boot order using the parameter Tag, which specifies the specific position of the driver in the group. The I/O Manager sorts the drivers in the group by the value of this parameter, and drivers that do not have a Tag parameter are moved to the bottom of the list of drivers in the group.

The priority of the tag is determined not by the value of the tag, but by its position: the higher the tag is located, the higher its priority in the group, and the higher the priority of the driver to which this tag corresponds. And since 01 is higher than the other tags, the ACPI driver is loaded first in the group.

Services

Windows services are started by the Service Control Manager (SCM) according to the parameter value Start. This parameter for services can take the following values:

The values 0 (start at system boot) and 1 (start by system) for services cannot be specified, only for device drivers.

In addition, starting with Windows Vista\Server 2008, another launch mode appeared for services - delayed autostart. The parameter is responsible for it DelayedAutoStart = 1, which instructs SCM to automatically start this service with a delay. SCM starts services for which delayed start is selected after loading the services marked for autostart.

The service launch mode can be controlled not only from the registry, but also in graphical mode, from the Services console.

This is shown more clearly in the Services snap-in, where the Dependency tab lists both the services on which a given service depends and the services that depend on it.

Since Windows is a multitasking system, it excludes such liberties for application programs as directly accessing I/O ports or handling hardware interrupts. Interaction with hardware at a low level can only be performed by system programs running in privileged mode. Device drivers play a major role here.

Windows uses a multi-level driver structure in which high-level drivers can act as filters that perform special processing on data received from or passed to a low-level driver. An example would be to separate the driver that controls the bus from the drivers for the specific devices connected to the bus. Another example is a driver that performs data encryption/decryption when working with the NTFS file system. The structure of drivers at all levels is subject to uniform standards known as WDM (Windows DiverModel), however, high-level drivers, unlike low-level ones, do not handle hardware interrupts.

Oddly enough, in WindowsNT low-level drivers are not yet the lowest level of device management. Even closer to the hardware lies the so-called HAL level (Hardware Abstractions Level). Its role is to hide from other OS modules, including drivers, some details of working with the hardware, depending on specific buses, the type of motherboard, and connection method. For example, HAL provides drivers with the ability to access device registers by their logical numbers without knowing whether the register is connected to a processor port or memory mapped.

Despite the standardization of the structure, several special types of drivers can be distinguished, differing in functionality.

GDI (GraphicDeviceInterface) drivers are high-level drivers for graphics devices (monitors, printers, plotters). These drivers translate Windows graphics calls (such as draw line, fill area, output text, select current font, current pen, current fill) into commands that perform corresponding actions on a specific device. The issuance of these commands to the device is performed by another, low-level driver. Thanks to the presence of GDI drivers, the same program can output graphic images to different devices. A prime example of this is the preview mode available in various editors, which displays pages on the screen exactly as they will be printed.

Keyboard and mouse drivers, in addition to standard driver operations, perform additional load. They generate messages about events on the corresponding device (key press and release, mouse movement, mouse button press and release) and place them in the system message queue. The system then forwards each message to the process it was intended for further processing.

Device virtualization drivers (VxD drivers) serve to share devices between processes, creating the illusion that the process has exclusive ownership of the device. In fact, the driver organizes a queue of requests from processes, switches the device to the mode required for the next process, etc. An example would be a monitor virtualization driver. A console application (for example, an MS-DOS program) works with the entire screen in text mode. But if such an application is launched in a Windows window, then the VxD driver simulates text mode in graphics. To do this, the driver must intercept the program's attempts to access video memory addresses directly and convert the coordinates of text mode familiar locations into the coordinates of the corresponding positions in the window.