Driver package installer что это
You can add driver packages to a Windows image before, during, or after you deploy the image. When planning how to add driver packages to your Windows deployment, it's important to understand how driver packages are added to the image, how driver ranking affects deployment, and the digital signature requirements for driver packages.
Adding Driver Packages
You can add driver packages to a Windows image:
Add driver packages before deployment on an offline Windows image by using DISM
Offline servicing occurs when you modify a Windows image entirely offline without booting the operating system. You can add, remove, and enumerate driver packages on an offline Windows image by using the DISM command-line tool. DISM is installed with Windows and is also distributed in the Windows Assessment and Deployment Kit (Windows ADK). For more information about DISM, see the DISM - Deployment Image Servicing and Management Technical Reference for Windows.
When you add a driver package to an offline image, it's either staged or reflected in the image:
Boot-critical driver packages are reflected. In other words, they are added to the Driver Store and then the files are copied into the image according to what's specified in the .inf file as the destination of the files. The system completes installation tasks during the initial boot, including updating the registry.
Driver packages that aren't boot critical are staged. In other words, they're added to the Driver Store. After Windows starts, PnP detects the device and installs the matching driver package from the Driver Store.
You can use DISM commands to add or remove driver packages on a mounted or applied Windows or Windows Preinstallation Environment (Windows PE) image.
You can't use DISM to remove inbox driver packages (driver packages that are installed on Windows by default), except for some network drivers. You can use it only to remove third-party or out-of-box driver packages.
You can also use DISM commands to apply an unattended answer file to a mounted or applied Windows image.
If you're using DISM, you can add only .inf driver packages to an offline Windows image. Driver packages that display the Designed for Windows logo are provided as .cab files. You must expand the .cab file before you install the .inf file if you're using DISM for the installation. You must install a driver package that's packaged as a .exe file or another file type on a running Windows operating system. To run a .exe or Windows Installer (.msi) driver package, you can add a custom command to an answer file to install the driver package. For more information, see Add a Custom Command to an Answer File.
Add driver packages during an automated deployment by using Windows Setup and an answer file
You can use an unattended answer file to add driver packages to an image when you use Windows Setup for deployment. In this answer file, you can specify the path of a driver package on a network share (or a local path). You accomplish this by adding the Microsoft-Windows-PnpCustomizationWinPE or Microsoft-Windows-PnpCustomizationNonWinPE components and specifying the configuration passes where you want to install them. When you run Windows Setup and specify the name of the answer file, out-of-box driver packages are staged (added to the Driver Store on the image), and boot-critical driver packages are reflected (added to the image so that they'll be used when the computer boots). Setup uses the answer file. By adding driver packages during the windowsPE or offlineServicing configuration passes, you can add out-of-box driver packages to the Windows image before the computer starts. You can also use this method to add boot-critical driver packages to a Windows image. For more information, see Add Device Drivers to Windows During Windows Setup. For more information about how Windows Setup works, see the Windows Setup Technical Reference.
If you want to add boot-critical driver packages to Windows PE, use the windowsPE configuration pass to reflect the driver packages before the Windows PE image is booted. The difference between adding boot-critical driver packages during the windowsPE configuration pass and adding them during the offlineServicing configuration pass is that during the windowsPE configuration pass, boot-critical driver packages are reflected for Windows PE to use. During the offlineServicing configuration pass, the driver packages are staged to the Driver Store on the Windows image.
Methods for adding driver packages by using Windows Setup include these:
- Using an answer file to add driver packages during the offlineServicing configuration pass of Setup.
- Using an answer file to add driver packages during the windowsPE configuration pass of Setup.
- For Windows Server, placing driver packages in the $WinPEDriver$ directory to be installed automatically during the windowsPE configuration pass of Setup. All drive letters with a value of C or greater are scanned for a $WinPEDriver$ directory. The drive must be accessible to the hard disk during Setup. Make sure that the drive does not require a storage driver to be loaded before it can be accessed.
For more information about these and other configuration passes, see Windows Setup Configuration Passes.
When you're using Windows Deployment Services for deployment in Windows Server, you can add driver packages to your server and configure them to be deployed to clients as part of a network-based installation. You configure this functionality by creating a driver group on the server, adding packages to it, and then adding filters to define which clients will install those driver packages. You can configure driver packages to be installed based on the client's hardware (for example, manufacturer or BIOS vendor) and the edition of the Windows image that's selected during the installation. You can also configure whether clients install all packages in a driver group or only the driver packages that match the installed hardware on the client. For more information about how to implement this functionality, see the Windows Deployment Services documentation.
Add driver packages after deployment on a running operating system by using PnPUtil or an answer file
You can use the PnPUtil tool to add or remove driver packages on a running operating system. Alternatively, you can use an answer file to automate the installation of the driver packages when the computer is booted in audit mode. These methods can be helpful if you want to maintain a simple Windows image, and then add only the driver packages that are required for a specific hardware configuration. For more information about how to use audit mode, see Boot Windows to Audit Mode or OOBE.
Methods for adding driver packages online to a running operating system include these:
Using PnPUtil to add or remove PnP driver packages. For more information, see Use PnPUtil at a command line to install a Plug and Play device.
Using an answer file to automate the installation of PnP driver packages when the computer is booted in audit mode. For more information, see Add a Driver Online in Audit Mode.
Driver packages for S mode
Driver packages in Windows S mode must meet certain requirements. See Windows 10 S driver requirements to learn about the types of driver packages you can add to Windows in S mode.
Managing Driver Folders
If you're adding multiple driver packages, you should create separate folders in your source location for each driver package or driver package category. This makes sure that there are no conflicts when you add driver packages that have the same file name. After the driver package is installed on the operating system, it's renamed to Oem*.inf to ensure unique file names in the operating system. For example, the staged drivers named MyDriver1.inf and MyDriver2.inf may be renamed to Oem0.inf and Oem1.inf after they're installed.
When you specify a device-driver path in an answer file, all .inf driver packages in the specified directory and subdirectories are added to the Driver Store of the Windows image. For example, if you want all of the driver packages in the C:\MyDrivers\Networking, C:\MyDrivers\Video, and C:\MyDrivers\Audio directories to be available in your Windows image, specify the device-driver path, C:\MyDrivers, in your answer file. If you're not using an answer file, you can use the /recurse command in DISM. For more information about the /recurse command, see DISM Driver Servicing Command-Line Options. This command makes sure that all driver packages in each subdirectory will be added to the Driver Store in your Windows image.
If all driver packages in the specified directory and subdirectories are added to the image, you should manage the answer file or your DISM commands and these directories carefully. Do your best to address concerns about increasing the size of the image through unnecessary driver packages.
Understanding Driver Ranking
One of the most common issues in deploying driver packages happens when a driver package is successfully imported into the driver store but, after the system is online, PnP finds a better-ranking driver and installs that driver instead.
The Windows PnP manager ranks these driver package properties in order of importance:
- Signing
- PnP ID match
- Driver date
- Driver version
For example, if a driver package has a better PnP ID match but is unsigned, a signed driver package that has a compatible ID match takes precedence. An older driver package can outrank a newer driver package if the older driver package has a better PnP ID match or signature.
For more information about driver package ranking, see How Windows Ranks Drivers.
Understanding Digital Signature Requirements
Signed driver packages are a key security feature in Windows. Driver packages that are installed on x64-based computers must have a digital signature. Although it isn't required, we recommend making sure that driver packages are signed before you install them on x86-based computers.
All boot-critical driver binary files must contain embedded signatures. For example, kernel mode .sys files that are critical for accessing the boot disk.
There are two ways that a driver binary file can be signed:
Boot-critical kernel mode driver binary files are digitally signed via a method called embedded signing. Embedded signatures improve boot loading performance. For driver binary files that are not part of a PnP driver package, signatures should be embedded so that they're not lost during an upgrade of the operating system.
Digitally signed PnP driver packages contain a catalog (.cat) file that's digitally signed. The catalog file contains a hash of all the files in the driver package's .inf file for installation. A signed catalog file is all that's required to correctly install most PnP driver packages.
Either of these sources can sign driver packages:
Windows Hardware Quality Labs (WHQL), which makes sure that your driver packages qualify for the Windows Hardware Certification Program. WHQL creates a signed driver package catalog. For boot-critical driver binary files, you should add embedded signatures instead of relying on the catalog. Embedded signatures in boot-critical driver binary files optimize boot performance of the operating system by eliminating the requirement to locate the appropriate catalog file when the operating system loader verifies the driver signature.
A certification authority (CA), by using a Software Publishing Certificate (SPC). For boot-critical and x64-based kernel driver binary files, Microsoft provides an additional certificate that can be used to cross-sign the driver binary files. Driver binary files that aren't boot critical don't have to be cross-signed by Microsoft or embedded. You can use the Windows Kernel Mode Code Signing process if you need the flexibility of signing the driver binary files yourself. For information about digital signatures for kernel modules on x64-based systems, see 64-Bit Driver Guidelines.
For testing, you can also use test certificates.
If you have received an unsigned driver package from a vendor for testing, you can use a test signature to validate the driver package and to test the installation. Test signing is the act of digitally signing an application by using a private key and a corresponding code-signing certificate that's trusted only in the confines of a test environment.
These are the primary ways to generate such test-signing certificates:
- Developers can generate their own self-signed certificates.
- A CA can issue certificates.
For either option, test-signing certificates must be clearly identified as appropriate only for testing. For example, the word "test" can be included in the certificate subject name, and additional legal disclaimers can be included in the certificate. Production certificates that are issued by commercial CAs must be reserved for signing only public beta releases and public final releases of software and internal line-of-business software.
When you're adding test-signed driver packages to Windows, consider these points:
You must install the test certificates on a running operating system. You can't install them offline.
The certificate of the CA that issued the test certificate must be inserted in the Trusted Root Certification Authorities certificate store.
[note] If the test certificate is self-signed—for example, by using the Certificate Creation Tool (MakeCert)—the test certificate must be inserted in the Trusted Root Certification Authorities certificate store.
The test certificate that's used to sign the driver package must be inserted in the Trusted Publishers certificate store.
You must add test certificates online (to a booted instance of the Windows image) before you can use the Deployment Image Servicing and Management (DISM) command-line tool to add test-signed driver packages offline.
DISM validates WHQL certifications only for boot-critical driver packages. But, a DISM command-line option can override this behavior. For more information, see DISM Driver Servicing Command-Line Options.
To install and verify test-signed driver packages on 64-bit operating systems, set the Windows boot configuration to test mode by using the BCDedit tool on the destination computer. Test mode verifies that the driver image is signed, but certificate path validation doesn't require the issuer to be configured as a trusted root authority. For the PnP driver installation and ranking logic to treat the driver package correctly, the test certificate must be stored in the trusted certificate store of the operating system image. For information about test mode during development, see 64-Bit Driver Guidelines.
If an unsigned or invalid boot-critical driver package is installed on an x64-based computer, the computer will not boot. The unsigned or invalid boot-critical driver package will cause a Stop error. You should remove the driver package from the image. If you're performing an upgrade, make sure that unsigned driver packages and their associated applications, services, or devices are removed or updated with a signed driver package.
If you don't enable test mode by using BCDedit, and you have a test-signed driver package installed, your computer will not boot. If you use DISM to remove the driver package, all instances of the reflected driver package might not be removed. So, we recommend that you don't deploy images that have test-signed driver packages installed.
Additional Resources
These websites provide more information about driver package requirements:
For more information about PnP driver package deployment, see PnP Device Installation Signing Requirements.
For more information about digital signatures and developing driver packages, see the relevant page on the Windows Hardware Developer Central website.
Последнее обновление: 07/01/2021 [Время на прочтение:
Файл DPInst.exe считается разновидностью файла Driver Package Installer. Наиболее часто он используется в ПО Driver Package Installer (DPInst), разработанном компанией IObit. Он использует расширение EXE и считается файлом Win64 EXE (Библиотека динамической компоновки).
Первый выпуск файла DPInst.exe в ОС Windows 10 состоялся 09/24/2019 в составе Driver Booster 7.0.2.435. Последнее обновление для IObit Toolbox 1.2 состоялось 03/17/2011 [версия файла 2.1].
В этой статье приведены подробные сведения о DPInst.exe, руководство по устранению неполадок с файлом EXE и список версий, доступных для бесплатной загрузки.
Совместимость с Windows 10, 8, 7, Vista, XP и 2000
Средняя оценка пользователей
| Сведения о разработчике и ПО | |
|---|---|
| Разработчик ПО: | Microsoft Corporation |
| Программа: | Driver Package Installer (DPInst) |
| Авторское право: | © Microsoft Corporation. All rights reserved. |
| Сведения о файле | |
|---|---|
| Набор символов: | Unicode |
| Код языка: | English (U.S.) |
| Флаги файлов: | Private build |
| Маска флагов файлов: | 0x003f |
| Точка входа: | 0x6bd3c |
| Размер кода: | 529408 |
| Информация о файле | Описание |
|---|---|
| Размер файла: | 664 kB |
| Дата и время изменения файла: | 2020:01:28 16:58:55+00:00 |
| Тип файла: | Win64 EXE |
| Тип MIME: | application/octet-stream |
| Тип компьютера: | AMD AMD64 |
| Метка времени: | 2006:11:02 09:06:09+00:00 |
| Тип PE: | PE32+ |
| Версия компоновщика: | 8.0 |
| Размер кода: | 529408 |
| Размер инициализированных данных: | 146944 |
| Размер неинициализированных данных: | 0 |
| Точка входа: | 0x6bd3c |
| Версия ОС: | 6.0 |
| Версия образа: | 6.0 |
| Версия подсистемы: | 5.2 |
| Подсистема: | Windows GUI |
| Номер версии файла: | 2.1.0.0 |
| Номер версии продукта: | 2.1.0.0 |
| Маска флагов файлов: | 0x003f |
| Флаги файлов: | Private build |
| Файловая ОС: | Windows NT 32-bit |
| Тип объектного файла: | Dynamic link library |
| Подтип файла: | 0 |
| Код языка: | English (U.S.) |
| Набор символов: | Unicode |
| Наименование компании: | Microsoft Corporation |
| Описание файла: | Driver Package Installer |
| Версия файла: | 2.1 |
| Внутреннее имя: | DPInst |
| Авторское право: | © Microsoft Corporation. All rights reserved. |
| Название продукта: | Driver Package Installer (DPInst) |
| Версия продукта: | 2.1 |
✻ Фрагменты данных файлов предоставлены участником Exiftool (Phil Harvey) и распространяются под лицензией Perl Artistic.
DPInst.exe — ошибки выполнения
Ошибки выполнения — это ошибки IObit Toolbox, возникающие во время «выполнения». Термин «выполнение» говорит сам за себя; имеется в виду, что данные ошибки EXE возникают в момент, когда происходит попытка загрузки файла DPInst.exe — либо при запуске приложения IObit Toolbox, либо, в некоторых случаях, во время его работы. Ошибки выполнения являются наиболее распространенной разновидностью ошибки EXE, которая встречается при использовании приложения IObit Toolbox.
К числу наиболее распространенных ошибок DPInst.exe относятся:
Не удается запустить программу из-за отсутствия DPInst.exe на компьютере. Попробуйте переустановить программу, чтобы устранить эту проблему.
Таким образом, крайне важно, чтобы антивирус постоянно поддерживался в актуальном состоянии и регулярно проводил сканирование системы.
Поиск причины ошибки DPInst.exe является ключом к правильному разрешению таких ошибок. Несмотря на то что большинство этих ошибок EXE, влияющих на DPInst.exe, происходят во время запуска, иногда ошибка выполнения возникает при использовании Driver Package Installer (DPInst). Причиной этого может быть недостаточное качество программного кода со стороны Microsoft Corporation, конфликты с другими приложениями, сторонние плагины или поврежденное и устаревшее оборудование. Кроме того, эти типы ошибок DPInst.exe могут возникать в тех случаях, если файл был случайно перемещен, удален или поврежден вредоносным программным обеспечением. Таким образом, крайне важно, чтобы антивирус постоянно поддерживался в актуальном состоянии и регулярно проводил сканирование системы.
Шаг 1. Восстановите компьютер до последней точки восстановления, «моментального снимка» или образа резервной копии, которые предшествуют появлению ошибки.
Чтобы начать восстановление системы (Windows XP, Vista, 7, 8 и 10):
Если на этапе 1 не удается устранить ошибку DPInst.exe, перейдите к шагу 2 ниже.
Шаг 2. Если вы недавно установили приложение IObit Toolbox (или схожее программное обеспечение), удалите его, затем попробуйте переустановить IObit Toolbox.
Чтобы удалить программное обеспечение IObit Toolbox, выполните следующие инструкции (Windows XP, Vista, 7, 8 и 10):
После полного удаления приложения следует перезагрузить ПК и заново установить IObit Toolbox.
Если на этапе 2 также не удается устранить ошибку DPInst.exe, перейдите к шагу 3 ниже.
IObit Toolbox 1.2
Шаг 3. Выполните обновление Windows.
Если ни один из предыдущих трех шагов по устранению неполадок не разрешил проблему, можно попробовать более агрессивный подход (примечание: не рекомендуется пользователям ПК начального уровня), загрузив и заменив соответствующую версию файла DPInst.exe. Мы храним полную базу данных файлов DPInst.exe со 100%-ной гарантией отсутствия вредоносного программного обеспечения для любой применимой версии IObit Toolbox . Чтобы загрузить и правильно заменить файл, выполните следующие действия:
Windows 10: C:\iobit_toolbox\tools\DPINST\32\Windows 10: C:\Program Files (x86)\IObit\Driver Booster\7.0.2\DpInst\x86\
Windows 10: C:\iobit_toolbox\tools\DPINST\64\
Windows 10: C:\Program Files (x86)\PC Connectivity Solution\
Windows 10: C:\Program Files\DIFX\F4092DA208C2C970\
Показать на 9 каталогов больше + Windows 10: C:\Program Files (x86)\Sony Ericsson\Sony Ericsson PC Suite\Drivers\
Windows 10: C:\Program Files (x86)\PC Connectivity Solution\
Windows 10: C:\Program Files\DIFX\F4092DA208C2C970\
Windows 10: C:\Program Files (x86)\PC Connectivity Solution\
Windows 10: C:\Program Files\DIFX\F4092DA208C2C970\
Windows 10: C:\Program Files (x86)\Nokia\Nokia PC Suite 7\Inf\
Windows 10: C:\Program Files\DIFX\0169CE3A95F06636\
Windows 10: C:\Program Files (x86)\Sony\Sony PC Companion\Drivers\
Windows 10: C:\Program Files (x86)\IObit\Driver Booster\7.0.2\DpInst\x64\
Если этот последний шаг оказался безрезультативным и ошибка по-прежнему не устранена, единственно возможным вариантом остается выполнение чистой установки Windows 10.
Решить задачу пакетной установки драйверов можно разными способами. Среди них наиболее распространенный – интеграция в дистрибутив операционной системы, однако он не единственный. Поговорим о малоизвестных способах пакетной установки драйверов.
В крупных организациях парк компьютеров, как правило, унифицирован. Однако он постоянно обновляется. Самый распространенный из них – интеграция пакета драйверов в дистрибутив операционной системы. Существует еще несколько альтернативных способов, которым стоит уделить внимание: установка пакета драйверов с помощью командного файла и с помощью Driver Package Installer.
Довольно часто возникает ситуация, когда необходимо предустановить пакет драйверов. В целях безопасности большинство сотрудников в сети не обладают административными правами и не могут устанавливать устройства. По этой причине они не могут подключить без помощи администратора различные внешние устройства с интерфейсом USB, Fire Ware и т. д.
Для решения этой проблемы необходимо инсталлировать часто используемые драйверы на всех компьютерах на этапе разворачивания программного обеспечения.
Для обеспечения автоматической пакетной установки драйверов можно использовать либо командный файл, либо Driver Package Installer (DPInst). Рассмотрим подробнее два способа.
Алгоритм установки драйверов устройств описан в INF-файле. В нем находится информация о том, какие библиотеки и куда необходимо скопировать, какие изменения сделать в реестре и т. д.
В Windows используется два интерпретатора INF-файлов: SETUPAPI и ADVANCEDINF, которые представляют собой два DLL-файла, располагающихся в каталоге %SystemRoot%/System32.
Интерпретатор SETUPAPI находится в библиотечном файле setupapi.dll, интерпретатор ADVANCEDINF – в библиотечном файле advpack.dll. Основным интерпретатором является SETUPAPI. Для получения доступа к интерпретаторам используется запускаемый файл RUNDLL32.EXE. Формат запуска любой библиотеки следующий:
rundll32.exe DLL,Function Рarameters
- DLL – имя файла библиотеки. В данном случае setupapi.dll или advpack.dll.
- Function – функция, вызываемая из библиотеки, или, как ее еще называют, точка входа. Обратите внимание: название файла и вызываемой функции разделены запятой без пробелов.
- Parameters – параметры, передаваемые функции.
Интерпретатор SETUPAPI позволяет:
- управлять реестром: создание и удаление ключей, параметров и их значений;
- распаковывать CAB-файлы;
- управлять файлами и папками, их атрибутами;
- устанавливать и удалять драйверы устройств.
Для запуска процесса установки драйверов используется функция InstallHinfSection, для удаления – соответственно unInstallHinfSection. В листинге 1 приведен пример установки драйверов, описанных в файле HP_1200.INF.
Листинг 1. Установка драйверов с помощью интерпретатора SETUPAPI
rundll32.exe setupapi,InstallHinfSection HP_1200_PPD 132 C:\HP_1200.INF
Функция InstallHinfSection имеет три параметра. Первый из них – имя выполняемой секции INF-файла, второй – флаг обработки файла. В таблице приведены возможные значения флага. Третий параметр – непосредственно имя INF-файла.
По своей сути интерпретатор ADVANCEDINF является надстройкой над SETUPAPI, позволяющей выполнять дополнительно следующие функции:
- однократное выполнение доустановки после входа в систему при инсталляции и деинсталляции (Active Setup);
- предварительная запись изменяемых ключей реестра в бинарный файл (функция отката);
- запуск исполняемых файлов с параметрами в скрытом и нормальном режимах;
- вывод диалоговых окон.
Стандартные функции ADVANCEDINF передает на исполнение интерпретатору SETUPAPI.
Листинг 2. Установка драйверов с помощью интерпретатора SETUPAPI
rundll32.exe advpack,LaunchINFSection C:\HP_1200.INF HP_1200_PPD 132
Бесспорным преимуществом является интегрированность обоих интерпретаторов, используемых в командных файлах, в операционную систему, однако при этом необходимо точно указывать местонахождение драйвера и секцию INF-файла, служащую его точкой входа. Для этого администратор должен разбираться в синтаксисе.
Возможные флаговые значения обработки файлов
Driver Package Installer
Driver Package Installer (DPInst) – компонент, разработанный компанией Microsoft, входящий в состав пакета Microsoft Windows Driver Install Frameworks (DIF). В настоящее время используется DIF v 2.1. DPInst обладает возможностями:
- Установка Plug and Play (PnP) драйверов. По умолчанию устанавливаются все подписанные PnP-драйверы, находящиеся в каталоге с файлом dpinst.exe. Для отключения проверки используется ключ /LM.
- Пакетная установка драйверов с помощью файла dpinst.xml. Описание структуры XML-файла см. далее.
- Поддержка «тихого» режима установки. Для включения режима используется ключ /S или /Q.
- Поддержка многоязычного интерфейса установщика драйверов.
- Ведение журнала установки.
- Деинсталляция драйверов.
Из перечисленных возможностей видно, что с помощью DPInst можно реализовать автоматическую установку группы драйверов в «тихом» режиме. По умолчанию DPInst устанавливает в системе все драйверы, INF-файлы которых находятся в одном каталоге с этой утилитой, однако устраивать помойку из драйверов по меньшей мере некорректно. Для решения этой проблемы используется DPInst.XML, находящийся в одном каталоге с DPInst.EXE. Он представляет собой обычный текстовый файл в формате XML. Единственное его отличие от других файлов – наличие стандартизированных тегов.
Установка пакета драйверов
Существует два способа пакетной установки: с помощью тега <group> и <search>. Принципиальная разница между этими способами заключается в том, что с помощью тега <group> реализована установка драйверов, местоположение которых точно указано. Используя тег <search>, можно установить все драйверы в указанной и ее дочерних папках. Рассмотрим подробнее оба способа.
Пакетная установка драйверов с помощью тега <group>
Для обеспечения установки пакета драйверов в файле DPInst.XML используется тег <group>, в котором может быть три типа дочерних тегов:
- <package path = «…»/> – таких тегов может быть неограниченное количество. Значение параметра path – относительный или абсолютный путь к INF-файлу драйвера.
- <installAllOrNone/> – в случае ошибки установки одного из драйверов осуществляется деинсталляция всех драйверов данного пакета. Этот тег по действию аналогичен ключу /A утилиты DPInst.exe.
- <suppressAddRemovePrograms/> – при наличии этого параметра мастером установки не будет создаваться соответствующая запись для каждого драйвера в папке «Установка и удаление программ», находящейся в «Панели управления» (см. рисунок). Этот тэг по действию аналогичен ключу /SA утилиты DPInst.exe.
Для автоматической установки пакета драйверов, состоящего из трех драйверов, находящихся в папках C:\hp1200\1200.inf, C:\hp3380\3380.inf, C:\hp4100\4100.inf, рекомендуется использовать XML-файл, приведенный в листинге 3.
Листинг 3. XML-файл, для автоматической установки
Для обеспечения автоматической установки рекомендуется для запуска утилиты DPInst.exe использовать два ключа, включающих тихий режим установки (/S) и позволяющих устанавливать неподписанные драйверы (/LM):
DPInst .exe / S /LM
Пакетная установка драйверов с помощью тега <search>
Для пакетной установки драйверов на практике используется более быстрый способ, реализованный с помощью тега <search>. Его преимущество, которое в определенной ситуации является серьезным недостатком, – инсталляция всех найденных драйверов в указанном месте (листинг 4).
Листинг 4. Установка найденных драйверов в подпапках
Установка пакета драйверов с использованием интерфейса
Утилиты DPInst.exe поддерживает многоязычный интерфейс. Текст всех диалоговых окон, лицензионное соглашение и другая информация могут быть переведены разработчиком драйверов или администратором. Рассмотрим этот вопрос подробнее на примере создания русскоязычного интерфейса. Для описания интерфейса служит тэг <language>. С помощью параметра code задается кодовая страница, например, 0х0409 соответствует английскому языку, а 0х0419 – русскому (листинг 5).
Листинг 5. Шаблон файла DPInst.XML
В тэге <language> могут быть приведены различные элементы, которые логически можно разделить на две группы. К первой группе отнесем те из них, которые управляют интерфейсом основного диалогового окна инсталлятора, ко второй – управляющие интерфейсом лицензионного соглашения. Поскольку перед системным администратором обычно стоит задача реализовать «тихую» установку, то ограничимся упоминанием о поддержке многоязычного интерфейса. Полное описание всех тегов находится в MSDN.
Driver Package Installer имеет неоспоримые преимущества перед установкой драйверов с помощью командного файла благодаря реализованной возможности автоматического поиска драйверов в указанном месте. При этом за один заход можно установить в систему неограниченное количество драйверов.
В заключение, хочется сказать несколько слов в защиту командных файлов. Достаточно часто встречаются ситуации, когда все способы перепробованы, но по тем или иным причинам достичь желаемого результата не удалось, тогда приходят на выручку такие способы, как установка драйверов с помощью командного файла.
пакеты драйверов можно добавить в образ Windows до, во время или после развертывания образа. при планировании добавления пакетов драйверов в развертывание Windows важно понимать, как добавляются пакеты драйверов к образу, как ранжирование драйверов влияет на развертывание, а также требования к цифровой подписи для пакетов драйверов.
Добавление пакетов драйверов
пакеты драйверов можно добавить в образ Windows:
добавление пакетов драйверов перед развертыванием в автономном образе Windows с помощью DISM
автономное обслуживание происходит при изменении Windows образа полностью вне сети без загрузки операционной системы. вы можете добавлять, удалять и перечислять пакеты драйверов в автономном Windows образе с помощью программы командной строки DISM. DISM устанавливается с Windows и также распространяется в комплекте средств для развертывания и оценки Windows (Windows ADK). Дополнительные сведения о DISM см. в статье Технический справочник по обслуживанию образов развертывания и управления ими для Windows.
При добавлении пакета драйверов в образ в автономном режиме он помещается в промежуточный режим или отражается в образе:
Пакеты драйверов, критически важных для загрузки , отражены. Другими словами, они добавляются в хранилище драйверов , а затем файлы копируются в образ в соответствии с тем, что указано в INF-файле в качестве места назначения файлов. Система завершает задачи установки во время начальной загрузки, включая обновление реестра.
Пакеты драйверов, которые не являются критическими для загрузки , являются промежуточными. Другими словами, они добавляются в хранилище драйверов. после запуска Windows PnP обнаруживает устройство и устанавливает соответствующий пакет драйверов из хранилища драйверов.
команды DISM можно использовать для добавления или удаления пакетов драйверов на подключенном или примененном Windows или среда предустановки Windows (Windows PE).
вы не можете использовать DISM для удаления пакетов драйверов папки "входящие" (пакеты драйверов, установленные на Windows по умолчанию), за исключением некоторых сетевых драйверов. Его можно использовать только для удаления пакетов драйверов сторонних производителей или поставщиков из списка.
если вы хотите добавить пакеты драйверов, критические для загрузки, в Windows PE, используйте этап настройки windowsPE , чтобы отразить пакеты драйверов перед загрузкой образа PE Windows. разница между добавлением пакетов драйверов, критических для загрузки, во время этапа настройки windowspe и добавлением их во время этапа настройки windowspe заключается в том, что во время этапа настройки для использования Windows PE будут отражены пакеты драйверов, критически важные для загрузки. во время этапа настройки offlineServicing пакеты драйверов помещаются в хранилище драйверов на Windowsном образе.
ниже перечислены методы добавления пакетов драйверов с помощью программа установки Windows.
дополнительные сведения об этих и других этапах настройки см. в разделе программа установки Windows конфигурации.
при использовании служб Windows deployment Services для развертывания в Windows server можно добавить пакеты драйверов на сервер и настроить их для развертывания на клиентах в рамках сетевой установки. Эта функция настраивается путем создания группы драйверов на сервере, добавления в нее пакетов, а затем добавления фильтров для определения того, какие клиенты будут устанавливать эти пакеты драйверов. можно настроить установку пакетов драйверов на основе оборудования клиента (например, производителя или поставщика BIOS) и выпуска образа Windows, выбранного во время установки. Можно также настроить, будут ли клиенты устанавливать все пакеты в группе драйверов или только пакеты драйверов, соответствующие установленному оборудованию на клиенте. дополнительные сведения о реализации этой функции см. в документации по службам развертывания Windows.
Ниже перечислены методы добавления пакетов драйверов в работающую операционную систему.
Использование средства PnPUtil для добавления или удаления пакетов драйверов PnP. Дополнительные сведения см. в статье Использование средства PnPUtil в командной строке для установки Самонастраивающийся устройства.
Пакеты драйверов для режима S
пакеты драйверов в режиме Windows S должны соответствовать определенным требованиям. ознакомьтесь с требованиями к драйверу Windows 10 s , чтобы узнать о типах пакетов драйверов, которые можно добавить в Windows в режиме S.
Управление папками драйверов
При добавлении нескольких пакетов драйверов следует создать отдельные папки в исходном расположении для каждого пакета драйверов или категории пакетов драйверов. Это гарантирует отсутствие конфликтов при добавлении пакетов драйверов с одинаковыми именами файлов. После установки пакета драйверов в операционной системе он переименовывается в * файл OEM. INF, чтобы гарантировать уникальность имен файлов в операционной системе. Например, промежуточные драйверы с именами MyDriver1. INF и MyDriver2. inf могут быть переименованы в oem0. INF и OEM1. INF после их установки.
Основные сведения о ранжировании драйверов
Одна из наиболее распространенных проблем при развертывании пакетов драйверов возникает, когда пакет драйверов успешно импортируется в хранилище драйверов, но после подключения системы служба PnP находит драйвер лучшего ранжирования и устанавливает этот драйвер.
диспетчер Windows PnP ранжирует эти свойства пакета драйверов в порядке важности.
Сертификат для подписи маркера
Соответствие ИД PnP
Например, если пакет драйвера имеет более подходящий идентификатор PnP, но не подписан, приоритет имеет подписанный пакет драйверов с совместимым ИДЕНТИФИКАТОРом. Более старый пакет драйверов может использовать более новый пакет драйверов, если более старый пакет драйверов имеет более высокий приоритет, совпадающий с ИДЕНТИФИКАТОРом PnP или подписью.
дополнительные сведения о ранжировании пакетов драйверов см. в статье Windows ранжирования драйверов.
Основные сведения о требованиях к цифровой подписи
Подписанные пакеты драйверов являются ключевой функцией безопасности в Windows. Пакеты драйверов, установленные на компьютерах на базе процессоров x64, должны иметь цифровую подпись. Хотя это не обязательно, рекомендуется убедиться, что пакеты драйверов подписаны, прежде чем устанавливать их на компьютеры на базе x86.
Все двоичные файлы драйверов, критические для загрузки, должны содержать внедренные подписи. Например, в режиме ядра .sys файлы, критически важные для доступа к загрузочному диску.
Двоичный файл драйвера можно подписать двумя способами:
Двоичные файлы драйвера в режиме ядра, необходимые для загрузки, снабжены цифровой подписью с помощью метода, именуемого встроенным подписыванием. Внедренные подписи улучшают производительность загрузки при загрузке. Для двоичных файлов драйвера, которые не являются частью пакета драйвера PnP, подписи должны быть внедрены, чтобы они не были потеряны во время обновления операционной системы.
Пакеты драйверов PnP с цифровой подписью содержат файл каталога (CAT) с цифровой подписью. Файл каталога содержит хэш всех файлов в INF-файле пакета драйверов для установки. Подписанный файл каталога — это все, что необходимо для правильной установки большинства пакетов драйверов PnP.
Один из этих источников может подписывать пакеты драйверов:
Windows лаборатория по качеству оборудования (WHQL), которая гарантирует, что пакеты драйверов должны быть определены для программы сертификации Windows оборудования. WHQL создает каталог подписанных пакетов драйверов. Для двоичных файлов драйверов, критических для загрузки, следует добавить внедренные подписи вместо того, чтобы полагаться на каталог. Встроенные подписи в двоичных файлах драйверов, критических для загрузки, оптимизируют производительность загрузки операционной системы, устраняя необходимость в поиске соответствующего файла каталога, когда загрузчик операционной системы проверяет подпись драйвера.
Центр сертификации (ЦС) с помощью сертификата издателя программного обеспечения (SPC). Для двоичных файлов драйверов ядра, критически важных для загрузки и x64, корпорация Майкрософт предоставляет дополнительный сертификат, который можно использовать для перекрестной подписи двоичных файлов драйвера. Двоичные файлы драйверов, не являющиеся критическими для загрузки, не должны быть подписаны корпорацией Майкрософт или внедренными. вы можете использовать Windows процесс подписи кода в режиме ядра, если вам нужна гибкость для самостоятельного подписывания двоичных файлов драйвера. Сведения о цифровых подписях для модулей ядра в системах на базе x64 см. в руководстве по драйверам 64-разрядной версии.
Для тестирования можно также использовать тестовые сертификаты.
Если вы получили неподписанный пакет драйверов от поставщика для тестирования, можно использовать тестовую подпись для проверки пакета драйвера и проверки установки. Тестовая подпись — это акт цифровой подписи приложения с помощью закрытого ключа и соответствующего сертификата подписи кода, который является доверенным только в ограничении тестовой среды.
Ниже приведены основные способы создания таких сертификатов подписи тестирования.
Разработчики могут создавать собственные самозаверяющие сертификаты.
ЦС может выдавать сертификаты.
В обоих вариантах сертификаты подписи тестов должны быть четко идентифицированы в соответствии с проверкой. Например, слово «test» можно включать в имя субъекта сертификата, а в сертификат могут включаться дополнительные юридические заявления об отказе. Производственные сертификаты, выданные коммерческими центрами сертификации, должны быть зарезервированы только для подписывания общедоступных бета-версий и бесплатных окончательных выпусков программного обеспечения и внутреннего бизнес-программного обеспечения.
при добавлении пакетов драйверов, подписанных тестами, в Windows следует учитывать следующие моменты.
Необходимо установить тестовые сертификаты в работающей операционной системе. Их нельзя установить в автономном режиме.
Сертификат центра сертификации, выдавшего тестовый сертификат, должен быть вставлен в хранилище сертификатов доверенных корневых центров сертификации.
Примечание
Если тестовый сертификат является самозаверяющим, например с помощью средства создания сертификатов (MakeCert), то тестовый сертификат должен быть вставлен в хранилище сертификатов доверенных корневых центров сертификации.
Тестовый сертификат, используемый для подписи пакета драйверов, должен быть вставлен в хранилище сертификатов "Доверенные издатели".
необходимо добавить тестовые сертификаты в оперативный режим (в загруженный экземпляр образа Windows), прежде чем можно будет использовать программу командной строки для обслуживания образов развертывания и управления ими (DISM) для добавления пакетов драйверов, подписанных с помощью тестовой подписи, в автономный режим.
DISM проверяет сертификаты WHQL только для пакетов драйверов, критических для загрузки. Но параметр командной строки DISM может переопределить это поведение. Дополнительные сведения см. в разделе параметры Command-Line обслуживания драйвера DISM.
чтобы установить и проверить пакеты драйверов, подписанные с помощью тестовой подписи, в 64-разрядных операционных системах, задайте конфигурацию загрузки Windows в тестовом режиме с помощью средства BCDedit на конечном компьютере. Тестовый режим проверяет, что образ драйвера подписан, но для проверки пути сертификата не требуется, чтобы издатель был настроен в качестве доверенного корневого центра сертификации. Чтобы правильно обработать пакет драйвера в логике установки и ранжирования драйвера PnP, тестовый сертификат должен храниться в хранилище доверенных сертификатов образа операционной системы. Сведения о тестовом режиме во время разработки см. в разделе рекомендации по драйверам 64-bit.
[! Внимание! *] Если на компьютере с архитектурой x64 установлен неподписанный или недопустимый критически важный для загрузки пакет драйверов, компьютер не будет загружаться. Неподписанный или недопустимый критически важный для загрузки пакет драйверов приведет к ошибке. Необходимо удалить пакет драйверов из образа. При выполнении обновления убедитесь, что неподписанные пакеты драйверов и связанные с ними приложения, службы или устройства удалены или обновлены с подписанным пакетом драйверов.
Если вы не включите режим тестирования с помощью BCDedit, и у вас установлен пакет драйверов, подписанный тестом, компьютер не будет загружаться. При использовании DISM для удаления пакета драйверов все экземпляры отраженного пакета драйверов могут не быть удалены. Поэтому рекомендуется не развертывать образы с установленными пакетами драйверов, подписанными тестами.
Дополнительные ресурсы
Эти веб-сайты содержат дополнительные сведения о требованиях к пакету драйверов:
Дополнительные сведения о развертывании пакетов драйверов PnP см. в разделе требования к подписывания установки устройства PnP.
дополнительные сведения о цифровых подписях и разработке пакетов драйверов см. на соответствующей странице на центральном веб-сайте Windows Hardware для разработчиков .
Читайте также: