Add Device Drivers to Windows During Windows Setup

To install Windows on some hardware designs, you may need to add device drivers to WindowsВ Setup. You can add drivers to Windows Setup by using an answer file that specifies the path to the driver files. To do this in new installations, you add the Microsoft-Windows-PnpCustomizationWinPE component during the windowsPE configuration pass, add the driver paths, and then specify the answer file.

You can also modify existing images and add and remove drivers. You can service offline images in several ways. For example, you can add the Microsoft-Windows-PnpCustomizationsNonWinPE component during the offlineServicing configuration pass, add or remove the driver paths, and then specify the name of the answer file. For more information about how to modify drivers on an offline Windows image by using an answer file, and also other methods of adding drivers to and removing drivers from an existing image, see Add and Remove Drivers to an Offline Windows Image.

Add Drivers to New Installations (windowsPE)

For new installations, you add drivers during the windowsPE configuration pass.

This method initializes Windows Preinstallation Environment (WindowsВ PE) and processes WindowsВ PE settings from the answer file, as follows:

Windows stages the Windows PE drivers in the RAM driver store.. Windows loads boot-critical drivers that WindowsВ PE requires to access the local disk and network. When you right-click DevicePaths and select Insert New PathAndCredentials into WindowsВ PE, Windows PE processes other WindowsВ PE customizations that the answer file specifies.

The WindowsВ Setup process applies the Windows image. Boot-critical drivers appear on the Windows image before Setup installs that image. Other drivers that you added to the WindowsВ PE driver store appear in the Windows image driver store. When Windows Setup processes the offlineServicing pass, Windows Setup also adds any drivers that the driver path specifies to the Windows image driver store.

To add a device driver during the windowsPE pass

Use Windows System Image Manager (WindowsВ SIM) to create an answer file that contains the paths to the device drivers that you intend to install.

Add the Microsoft-Windows-PnpCustomizationsWinPE component to your answer file in the windowsPE configuration pass.

Expand the Microsoft-Windows-PnpCustomizationsWinPE node in the answer file. Right-click DevicePaths, and then select Insert New PathAndCredentials.

A new PathAndCredentials list item appears.

For each location that you access, add a separate PathAndCredentials list item.

You can include multiple device driver paths by adding multiple PathAndCredentials list items. If you add multiple list items, you must increment the Key value for each path. For example, if you add two separate driver paths, the first path uses the Key value of 1 , and the second path uses the Key value of 2 .

Save the answer file, and then close WindowsВ SIM. The answer file must resemble the following example:

Boot to WindowsВ PE.

At a command prompt, run WindowsВ Setup. Specify the name of the answer file. For example:

Windows Setup adds the device drivers in the \\server\share\drivers path to the system during the setup process.

For more information about drivers, see Device Drivers and Deployment Overview and Add a Driver Online in Audit Mode. For more information about Windows components, see Unattended Windows Setup Reference.

Specifying Driver Load Order

For most devices, the physical hierarchy of the devices on a computer determines the order in which Windows and the PnP manager load drivers. Windows and the PnP manager configure devices starting with the system root device, and then they configure the child devices of the root device (for example, a PCI adapter), the children of those devices, and so on. The PnP manager loads the drivers for each device as the device is configured, if the drivers were not previously loaded for another device.

Settings in the INF file can influence driver load order. This topic describes the relevant values that vendors should specify in the service-install-section referenced by a driver’s INF AddService directive. Specifically, this topic discusses the StartType, BootFlags, LoadOrderGroup, and Dependencies entries.

Drivers should follow these rules for specifying StartType:

A PnP driver should have a start type of SERVICE_DEMAND_START (0x3), specifying that the PnP manager can load the driver when the PnP manager finds a device that the driver services.

Driver for a device required to start the computer

If a device is required to start the computer, the drivers for the device should have a start type of SERVICE_BOOT_START (0x0).

Non-boot-start driver that detects device(s) that are not PnP-enumerable

For a device that is not PnP-enumerable, a driver reports the device to the PnP manager by calling IoReportDetectedDevice. Such a driver should have the start type SERVICE_SYSTEM_START (0x01) so Windows will load the driver during system initialization.

Only drivers that report non-PnP hardware should set this start type. If a driver services both PnP and non-PnP devices, it should set this start type.

Non-PnP driver that must be started by the service control manager

Such a driver should have the start type SERVICE_AUTO_START (0x02). PnP drivers must not set this start type.

A PnP driver should be written so that it can be loaded when Windows configures a device that the driver services. Conversely, a driver should be able to be unloaded any time that the PnP manager determines that there are no longer devices present that the driver services. The only driver load orderings that PnP drivers should depend on are as follows:

The drivers for a child device can depend on the fact that the drivers for the parent device are loaded.

A driver in the device stack can depend on the fact that any drivers below it are loaded.

For example, the function driver can be certain that any lower-filter drivers are loaded.

However, be aware that a driver in the device stack cannot depend on being loaded sequentially after a device’s lower drivers, because the driver might are loaded previously when another device was configured.

Filter drivers in a filter group cannot predict their load ordering. For example, if a device has three registered upper-filter drivers, those three drivers will all be loaded after the function driver but could be loaded in any order within their upper-filter group.

If a driver has an explicit load-order dependency on another driver, that dependency should be implemented through a parent/child relationship. A driver for a child device can depend on the drivers for the parent device being loaded before the child drivers are loaded.

To reinforce the importance of setting the correct StartType value, the following list describes how Windows and the PnP manager use the StartType entries in INF files:

On system startup, the operating system loader loads drivers of type SERVICE_BOOT_START before it transfers control to the kernel. These drivers are in memory when the kernel gets control.

Boot-start drivers can use INF LoadOrderGroup entries to order their loading. (Boot-start drivers are loaded before most of the devices are configured, so their load order cannot be determined by device hierarchy.) The operating system ignores INF Dependencies entries for boot-start drivers.

The PnP manager calls the DriverEntry routines of the SERVICE_BOOT_START drivers so the drivers can service the boot devices.

If a boot device has child devices, those devices are enumerated. The child devices are configured and started if their drivers are also boot-start drivers. If a device’s drivers are not all boot-start drivers, the PnP manager creates a device node (devnode) for the device but does not start the device yet.

After all the boot drivers have loaded and the boot devices are started, the PnP manager configures the rest of the PnP devices and loads their drivers.

The PnP manager walks the device tree and loads the drivers for the devnodes that are not yet started (that is, any nonstarted devnodes from the previous step). As each device starts, the PnP manager enumerates the children of the device, if any.

As it configures these devices, the PnP manager loads the drivers for the devices, regardless of the drivers’ StartType values (except when StartType is SERVICE_DISABLED) before proceeding to start the devices. Many of these drivers are SERVICE_DEMAND_START drivers.

The PnP manager ignores registry entries that were created as a result of INF Dependencies entries and LoadOrderGroup entries for drivers that it loads in this step. The load ordering is based on the physical device hierarchy.

At the end of this step, all the devices are configured, except devices that are not PnP-enumerable and the descendants of those devices. (The descendants might or might not be PnP-enumerable.)

The PnP manager loads drivers of StartType SERVICE_SYSTEM_START that are not yet loaded.

These drivers detect and report their non-PnP devices. The PnP manager processes registry entries that are the result of INF LoadOrderGroup entries for these drivers. It ignores registry entries that were created because of INF Dependencies entries for these drivers.

The service control manager loads drivers of StartType SERVICE_AUTO_START that are not yet loaded.

The service control manager processes the service database information with respect to the services’ DependOnGroup and DependOnServices. This information is from Dependencies entries in INF AddService entries. Be aware that the Dependencies information is only processed for non-PnP drivers because any necessary PnP drivers were loaded in an earlier step of system startup. The service control manager ignores INF LoadOrderGroup information.

See the Microsoft Windows SDK documentation for more information about the service control manager.

Using BootFlags to Promote a Driver’s StartType at Boot Depending on Boot Scenario

The operating system can promote a driver’s StartType to be a boot start driver depending on the BootFlags value specified in the driver’s INF. You can specify one or more (ORed) of the following numeric values in the INF file, expressed as a hexadecimal value:

• If a driver should be promoted to be a boot start driver on network boot, specify 0x1 (CM_SERVICE_NETWORK_BOOT_LOAD).
• If a driver should be promoted on booting from a VHD, specify 0x2 (CM_SERVICE_VIRTUAL_DISK_BOOT_LOAD)
• If a driver should be promoted while booting from a USB disk, specify 0x4 (CM_SERVICE_USB_DISK_BOOT_LOAD).
• If a driver should be promoted while booting from SD storage, specify 0x8 (CM_SERVICE_SD_DISK_BOOT_LOAD)
• If a driver should be promoted while booting from a disk on a USB 3.0 controller, specify 0x10 (CM_SERVICE_USB3_DISK_BOOT_LOAD).
• If a driver should be promoted while booting with measured boot enabled, specify 0x20 (CM_SERVICE_MEASURED_BOOT_LOAD).
• If a driver should be promoted while booting with verifier boot enabled, specify 0x40 (CM_SERVICE_VERIFIER_BOOT_LOAD).
• If a driver should be promoted on WinPE boot, specify 0x80 (CM_SERVICE_WINPE_BOOT_LOAD).

For more information about promoting a driver’s StartType at boot, depending on the boot scenario, see INF AddService directive.

Алгоритм установки драйвера в Windows

Очевидно, что у каждого пользователя персонального компьютера, время от времени возникает необходимость подключить к своей станции какое-либо устройство. Причина, по которой это происходит, нас сейчас не сильно то и интересует, это может быть и хорошо знакомый многим апгрейд (в целях увеличения производительности отдельных узлов, и как следствие общей производительности системы), это может быть и просто добавление нового оборудования для расширения функционала существующей конфигурации, как, например, в случае с подключением нового игрового манипулятора, это может быть и потребность в использовании данных с флеш-накопителя. Вне зависимости от того, каким именно образом мы подключаем новое устройство, операционная система Windows вынуждена реагировать на появление нового оборудования, производя определенные манипуляции для обеспечения поддержки нового оборудования на программном уровне. Во многих операционных системах для обеспечения программного взаимодействия с устройствами используются интерфейс между оборудованием и программным слоем под названием драйвер .

Именно поэтому операционная система пытаемся всеми доступными ей методами обеспечить функционирование устройства в своей среде, для этого производится попытка установки для вновь подключаемого устройства соответствующего драйвера, дабы тем самым предоставить функции нового устройства для доступа программам пользовательского режима и коду режима ядра, ведь без этого самого пресловутого драйвера оборудование в системе работать попросту не сможет.
Я не случайно упомянул в определении логические устройства, поскольку существует отдельная категория драйверов, которые не занимаются обслуживанием аппаратного обеспечения, а интегрируются для расширения реализации (расширения, дополнения) функциональных особенностей различных модулей системы. Но кого сейчас удивишь установкой драйверов? Этот процесс настолько уже хорошо знаком всем пользователям ПК по многолетней практике, что некоторые, я уверен, могут делать это с закрытыми глазами 🙂 Но задумывались ли мы о деталях этого процесса, размышляли ли когда-нибудь над алгоритмом установки драйвера? Задавались ли вопросом, какие именно действия выполняет операционная система в момент подключения нового устройства и инсталляции драйверов?

Согласитесь, что с точки зрения пользователя процесс установки драйвера в Windows, в большинстве случаев, выглядит достаточно прозаично. В системном трее появляется привычный анимированный значок мастера установки, и система через некоторое время может выдать отчет об успешном, либо неудачном завершении процедуры инсталляции в системе драйвера нового устройства. Более того, зачастую мастер установки кроме этой самой иконки в трее вовсе не выдает никаких визуальных подтверждений о попытках инсталляции нового устройства, при этом «тихо» добавляя новое оборудование в список устройств и (в случае неудачи) маркируя его специальным значком в диспетчере устройств, предлагая пользователю в ручном режиме продолжить конфигурирование оборудования. Все эти внешние процессы, хорошо уже знакомые как Вам так и мне, в той или ином виде присутствуют во всех версиях операционных систем Windows практически с момента появления этой операционной системы, незначительно отличаясь между собой лишь в деталях. Они стали настолько знакомыми и привычными, что я даже никогда и не задумывался, а что же происходит «по ту сторону экрана», в недрах операционной системы, что скрывается под этой мнимой простотой? Как Вы увидите далее, установка драйвера Windows для физического либо логического устройства скрывает под собой довольно сложные и чрезвычайно интересные процессы. Алгоритм установки драйвера в Windows можно разбить на перечисленные ниже ключевые глобальные задачи:

• Копирование двоичного файла драйвера в соответствующий каталог в системе;
• Регистрация драйвера в системе Windows с указанием метода загрузки;
• Добавление необходимой информации в системный реестр;
• Копирование/установка связанных вспомогательных компонентов из пакета драйвера;

Помимо основных задач, выполняемых в рамках алгоритма установки драйвера в Windows, неплохо было бы классифицировать и условия, по которым стартует процесс установки драйвера Windows:

• Пользователь инсталлирует в выключенный компьютер новое устройство. В этом случае, сам процесс обнаружения нового устройства и инсталляции драйвера начинается уже на этапе загрузки операционной системы.
• Пользователь с правами локального администратора, при помощи оснастки «Диспетчер устройств» инициирует установку либо обновление драйвера для какого-либо уже установленного устройства.
• Пользователь «на ходу» подключает к работающему компьютер новое устройство. В этом случае речь идет об определенной категории устройств, которые могут подключаться «на лету», таких как устройства с внешним интерфейсом eSata , USB и прч. Ведь Вы же не будете инсталлировать внутреннюю видеокарту, когда питание подано на слоты PCIe ? Я лично такого пока еще не вытворял 🙂
• Пользователь самостоятельно запускает программу установки комплекта пакета драйвера из-под учетной записи с правами локального администратора. Такой способ может использоваться как для установки драйверов для физических устройств, которые поддерживают стандарт Plug and Play, так и для установки не-PnP (legacy) драйверов, драйверов логических устройств, которые не могут быть автоматически обнаружены системой и которые не могут быть проинсталлированы иначе как в ручном режиме. Характерным примером могут быть антивирусы или виртуальные машины, которые инсталлируют свои драйвера (логических устройств) в систему.
• Пользователь щелкает правой кнопкой мыши на .inf -файле в директории с драйвером и выбирает пункт Установить из-под учетной записи с правами локального администратора.

Но что представляет из себя сам пакет драйвера? Ведь, как мы неоднократно видели, это целый набор файловом абсолютно различного, на первый взгляд, назначения. Без более углубленного обзора структуры инталляционного пакета установки драйвера нам будет сложно понять и сам алгоритм установки драйвера, поэтому приведем общие составляющие: