Ошибки при установке программ из пакета Windows Installer «.msi»

Довольно распространённая проблема среди пользователей операционной системы Windows любых версий – ошибка msi при установке программ из файла с расширением .msi. В этой статье я опишу часто встречаемые проблемы с установщиком Windows 7/10/XP и варианты их решения, а также сделаю видео по текущему вопросу.

Файлы с расширением .msi это обычные пакеты установки (дистрибутивы) из которых ставится программа. В отличии от обычных «setup.exe», для запуска файла msi система использует службу Windows Installer (процесс msiexec.exe). Говоря простыми словами, установщик Windows разархивирует и запускает файлы из дистрибутива. Когда Windows Installer не работает, то появляются различные ошибки.

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

Неполадки могут быть с работой самой службы или могут возникать в процессе установки программ, когда всё настроено, в принципе, правильно. В первом случае нужно ковырять службу установщика, а во втором решать проблему с конкретным файлом. Рассмотрим оба варианта, но сначала второй.

Ошибки msi файлов

Очень часто ошибки появляются из-за недостаточных прав системы на файлы или папки. Нельзя сказать, что Windows Installer не работает, в этом случае достаточно просто добавить нужные права и всё заработает. Буквально вчера я столкнулся с тем, что скаченный дистрибутив .msi не захотел устанавливаться, при этом успешно запускается мастер установки, выбираются параметры, но затем система думает несколько секунд и выдаёт ошибку:

«Error reading from file «имя файла» verify that the file exists and that you can access it» (Error 1305). Переводится «Ошибка чтения из файла … проверьте существует ли файл и имеете ли вы к нему доступ». Ну не тупняк ли? Естественно, что кнопка «Повторить» не помогает, а отмена прекращает всю установку. Сообщение особой смысловой нагрузки также не несёт, т.к. файл точно существует и я имею к нему доступ, иначе бы просто не смог его запустить и получить это сообщение, к тому же почему-то на английском языке 🙂

А ошибка в том, что не Я должен иметь доступ к файлу, а установщик Windows, точнее сама Система. Решается очень просто:

1. Кликаем правой кнопкой по файлу с расширением .msi, выбираем «Свойства»
2. На вкладке «Безопасность» смотрим, есть ли в списке пользователь с именем «система» или «System»
3. Скорее всего вы такого не увидите. Поэтому будем добавлять вручную. Нажимаем кнопку «Изменить…», затем «Добавить…»
4. В поле пишем «система» или «System» (если у вас английская Windows) и нажимаем «Проверить имена». При этом слово должно стать подчёркнутым как на картинке.
5. Нажимаем «ОК», ставим галочку «Полный доступ», «ОК»
6. Кнопка «Дополнительно» -> «Изменить разрешения…» ставим «Добавить разрешения, наследуемые от родительских объектов», «ОК» три раза.

Теперь ошибка установщика не появится! Можно добавить доступ на всю папку, из которой вы обычно инсталлируете программы, например на папку «Downloads», как у меня. Смотрим видео по решению проблем с правами доступа:

В Windows XP вкладки «Безопасность» не будет, если включён простой общий доступ к файлам. Чтобы его выключить, нужно зайти в «Пуск -> Панель управления -> Свойства папки -> Вид» и выключить опцию «Использовать простой общий доступ к файлам». В урезанных версиях Windows 7/10 и XP вкладки «Безопасность» нет в принципе. Чтобы её увидеть, нужно загрузить Windows в безопасном режиме и зайти в неё под администратором.

Ещё способы решить проблему

• Запускайте установку, войдя в систему под администраторским аккаунтом
• Правой кнопкой по пакету «.msi» и выбираем «Запуск от имени Администратора»
• Выключите антивирус на время
• Включить режим совместимости с предыдущими операционными системами. Для этого зайдите в свойства файла msi и на вкладке «Совместимость» поставьте галочку «Запустить программу в режиме совместимости»
  
• Если файл на флешке, то попробуйте скопировать его куда-нибудь на жёсткий диск и запустить оттуда (бывает, что запрещена установка программ со съёмных накопителей)
• Попробуйте просто создать новую папку с любым именем в корне диска, перекинуть туда дистрибутив и запустить его оттуда

Описанный метод поможет при разных сообщениях, с разными номерами. Например, вы можете видеть такие ошибки файлов msi:

• Error 1723
• Internal Error 2203
• Системная ошибка 2147287035
• Ошибка «Невозможно открыть этот установочный пакет»
• Ошибка 1603: Во время установки произошла неустранимая ошибка

Во всех этих случаях должна помочь установка прав на файл и/или на некоторые системные папки. Проверьте, имеет ли доступ «система» к папке временных файлов (вы можете получать ошибку «Системе не удается открыть указанное устройство или файл»). Для этого:

1. Сначала узнаем нужные пути. Нажмите «Win + Pause» и зайдите в «Дополнительные параметры системы -> Вкладка «Дополнительно» -> кнопка «Переменные среды»»
2. В списках ищем переменные с названиями «TEMP» и «TMP» (значения обычно совпадают), в них записаны пути к временным папкам, которые использует установщик Windows
3. Теперь идём к этим папкам и смотрим в их свойствах, имеет ли к ним доступ «система». Чтобы быстро получить путь к временной папке пользователя, кликните два раза по переменной, скопируйте путь и вставьте его в адресной строке «Проводника» Windows

После нажатия «Enter» путь преобразится на «нормальный» и вы переместитесь в реальную временную папку. Права на неё и надо проверять. Также рекомендую очистить временные папки от всего что там скопилось или даже лучше удалить их и создать новые с такими же названиями. Если не получается удалить папку, почитайте как удалить неудаляемое, но это не обязательно.

Если служба Windows Installer всё равно не хочет работать, то проверьте права на папку «C:\Config.Msi», сюда «система» также должна иметь полный доступ. В этом случае вы могли наблюдать ошибку «Error 1310». На всякий случай убедитесь, что к папке КУДА вы инсталлируете софт также есть все права.

Если вы используете шифрование папок, то отключите его для указанных мной папок. Дело в том, что хотя мы сами имеем к ним доступ, служба Microsoft Installer не может до них достучаться пока они зашифрованы.

Ещё ошибка может быть связана с битым файлом. Может быть он не полностью скачался или оказался битым уже на сервере. Попробуйте скачать его ещё раз оттуда же или лучше с другого места.

Ошибка установщика Windows

В случае общих проблем не будут устанавливаться никакие msi файлы, процесс установки, скорее всего, даже не начнётся. При этом могут появляться ошибки вида:

• Нет доступа к службе установщика Windows
• Не удалось получить доступ к службе установщика Windows
• Ошибка пакета установщика Windows (1719)

или ещё нечто подобное со словами «ошибка msi», «Windows Installer Error». Всё это означает, что система дала сбой и теперь её надо лечить. Может вы ставили какой-то софт, который испортил системные файлы и реестр, или подхватили вирус. Конечно, никогда не будет лишним удалить вирусы, или убедиться что их нет. Но оставьте этот вариант на потом, т.к. обычно проблема кроется в другом.

Сначала давайте проверим работает ли служба Windows Installer:

1. Нажмите «Win + R» и введите services.msc
2. Найдите в конце списка службу «Установщик Windows» или «Windows Installer»
3. Тип запуска должен быть «Вручную». Если она «Отключена», то зайдите в «Свойства» и выберите «Вручную»
4. Затем кликните по ней правой кнопкой и выберите «Запустить» или «Перезапустить». Если ошибок нет и состояние переходит в режим «Работает», то здесь всё нормально.
5. Нажмите «Win + R» и введите msiexec. Если модуль MSI работает нормально, то должно появиться окно с версией установщика и параметрами запуска, а не ошибка.

Следующее что я посоветую сделать – это выполнить команду сканирования системы на повреждённые и изменённые системные файлы. Нажмите «Win + R» и введите

Sfc /scannow

Произойдёт поиск и замена испорченных файлов на оригинальные, при этом может потребоваться вставить установочный диск с Windows XP-7-10. После окончания процесса перегрузитесь и посмотрите, решена ли проблема.

Microsoft сам предлагает утилиту, призванную решить нашу проблему. Запустите программу Easy Fix и следуйте мастеру.

Параметры реестра и службы

Следующий способ устранения ошибки – восстановление рабочих параметров в реестре установщика Windows Installer.

Для этого скачайте архив и запустите оттуда два reg-файла, соответственно своей версии Windows. Согласитесь с импортом настроек.

В Windows XP или Windows Server 2000 установите последнюю версию установщика 4.5.

Если не помогло, то проделайте ещё перерегистрацию компонентов:

1. Нажмите «Win + R» и введите «cmd». Затем в чёрном окне введите последовательно команды:
   MSIExec /unregister
   MSIExec /regserver
2. В ответ должна быть пустота, никаких ошибок. Если проблема не решена, введите ещё команду
   regsvr32 msi.dll
3. Закройте чёрное окно

Если пишет, что не хватает прав, то нужно запускать командную строку от имени Администратора.

Если команды выполнились, но не помогло, то скачайте файл и запустите msi_error.bat из архива, проверьте результат.

Последний вариант — скачайте программу Kerish Doctor, почитайте мою статью, там есть функция исправления работы службы установщика и многих других частых проблем Windows.

Также, многие программы используют .NET Framework, поэтому не будет лишним установить последнюю версию этого пакета. И, напоследок, ещё один совет: если в пути к файлу-дистрибутиву есть хоть одна папка с пробелом в начале названия, то удалите пробел. Такой простой приём решит вашу проблему 🙂

Подведение итогов

Ошибки с установщиком Windows очень неприятные, их много и сразу непонятно куда копать. Одно ясно – система дала сбой и нужно восстанавливать её до рабочего состояния. Иногда ничего не помогает и приходится переустанавливать Windows. Однако не торопитесь это делать, попробуйте попросить помощи на этом форуме. В точности опишите вашу проблему, расскажите что вы уже делали, какие сообщения получили, и, возможно, вам помогут! Ведь мир не без добрых людей 🙂

Device Drivers

You can add device drivers to a Windows image before, during, or after you deploy the image. When planning how to add drivers to your Windows deployment, it’s important to understand how driver folders are added to the image, how driver ranking affects deployment, and the digital signature requirements for drivers.

Adding Drivers

You can add device drivers to a Windows image:

Add drivers 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 drivers 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 to an offline image, it’s either staged or reflected in the image:

Boot-critical drivers are reflected. In other words, the files are copied into the image according to what’s specified in the .inf file. The PC completes installation tasks during the initial boot, including updating the Critical Devices Database (CDDB) and the registry.

Drivers 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 from the driver store.

You can use DISM commands to add or remove drivers on a mounted or applied Windows or Windows Preinstallation Environment (WindowsВ PE) image.

NoteВ В You can’t use DISM to remove inbox drivers (drivers that are installed on Windows by default). You can use it only to remove third-party or out-of-box drivers.

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 drivers to an offline Windows image. Drivers 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 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 drivers during an automated deployment by using WindowsВ Setup and an answer file

You can use an unattended answer file to add drivers to an image when you use WindowsВ Setup for deployment. In this answer file, you can specify the path of a device driver 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 drivers are staged (added to the driver store on the image), and boot-critical drivers are reflected (added to the image so that they’ll be used when the computer boots). Setup uses the answer file. By adding device drivers during the windowsPE or offlineServicing configuration passes, you can add out-of-box device drivers to the Windows image before the computer starts. You can also use this method to add boot-critical device drivers 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 drivers to WindowsВ PE, use the windowsPE configuration pass to reflect the drivers before the WindowsВ PE image is booted. The difference between adding boot-critical drivers during the windowsPE configuration pass and adding them during the offlineServicing configuration pass is that during the windowsPE configuration pass, boot-critical drivers are reflected for WindowsВ PE to use. During the offlineServicing configuration pass, the drivers are staged to the driver store on the Windows image.

Methods for adding device drivers by using WindowsВ Setup include these:

Using an answer file to add drivers during the offlineServicing configuration pass of Setup.

Using an answer file to add drivers during the windowsPE configuration pass of Setup.

For Windows Server, placing drivers 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 device drivers 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 drivers. You can configure drivers 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 drivers that match the installed hardware on the client. For more information about how to implement this functionality, see the Windows Deployment Services documentation.

Add drivers after deployment on a running operating system by using PnPUtil or an answer file

You can use the PnPUtil tool to add or remove drivers on a running operating system. Alternatively, you can use an answer file to automate the installation of the drivers 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 drivers 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 device drivers online to a running operating system include these:

Using PnPUtil to add or remove PnP drivers. 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 drivers when the computer is booted in audit mode. For more information, see Add a Driver Online in Audit Mode.

Drivers for Windows 10 S

Drivers in Windows 10 S must meet certain requirements. See Windows 10 S driver requirements to learn about the types of drivers you can add to Windows 10 S.

Managing Driver Folders

If you’re adding multiple drivers, you should create separate folders for each driver or driver category. This makes sure that there are no conflicts when you add drivers that have the same file name. After the driver 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 are renamed to Oem0.inf and Oem1.inf after they’re installed.

When you specify a device-driver path in an answer file, all .inf drivers in the specified directory and subdirectories are added to the driver store of the Windows image, %SystemRoot%\System32\DriverStore\FileRepository. For example, if you want all of the drivers 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 drivers in each subdirectory will be added to the driver store in your Windows image.

If all drivers 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.

If it isn’t practical to manage your driver shares so that only the required drivers are added to your image, you can use the Driver Package Installer (DPInst) tool to add drivers that aren’t boot critical online. DPInst selectively installs drivers that aren’t boot critical only if the hardware is present or if the driver package is a better match for the device.

Understanding Driver Ranking

One of the most common issues in deploying drivers happens when a driver is successfully imported into the driver store but, after the system is online, PnP finds a higher-ranking driver and installs that driver instead.

The WindowsВ PnP manager ranks these driver package properties in order of importance:

For example, if a device has a better PnP ID match but is unsigned, a signed driver that has a compatible ID match takes precedence. An older driver can outrank a newer driver if the older driver has a better PnP ID match or signature.

For more information about driver ranking, see How Windows Ranks Drivers.

Understanding Digital Signature Requirements

Signed device drivers are a key security feature in Windows. Drivers that are installed on x64-based computers must have a digital signature. Although it isn’t required, we recommend making sure that drivers are signed before you install them on x86-based computers.

All boot-critical drivers must contain embedded signatures. A digital signature isn’t required for Plug and Play (PnP) drivers. But when an unsigned PnP driver is installed on a running operating system, administrator credentials are required, and you can’t install such drivers on 64-bit operating systems.

There are two ways that a driver can be signed:

Kernel mode and boot-critical drivers are digitally signed via a method called embedded signing. By using embedded signatures, every binary in the driver package is signed. Embedded signatures improve boot loading performance. For drivers that are not PnP, signatures should be embedded so that they’re not lost during an upgrade of the operating system.

Digitally signed PnP drivers contain a catalog (.cat) file that’s digitally signed. The catalog file contains a hash of all the files in the driver’s .inf file for installation. A signed catalog file is all that’s required to correctly install most PnP drivers.

Either of these sources can sign drivers:

WindowsВ Hardware Quality Labs (WHQL), which makes sure that your drivers qualify for the Windows Hardware Certification Program. WHQL creates a signed driver catalog. For boot-critical drivers, you should add embedded signatures instead of relying on the catalog. Embedded signatures in boot-critical driver image 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 drivers, Microsoft provides an additional certificate that can be used to cross-sign the drivers. Drivers 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 drivers 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 from a vendor for testing, you can use a test signature to validate the driver 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 drivers offline.

DISM validates WHQL certifications only for boot-critical drivers. 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 drivers 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 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.

CautionВ В If an unsigned or invalid boot-critical device driver is installed on an x64-based computer, the computer will not boot. The unsigned or invalid boot-critical device driver will cause a Stop error. You should remove the driver from either the critical device database (CDDB) or its reflected location in the image. If you’re performing an upgrade, make sure that unsigned drivers and their associated applications, services, or devices are removed or updated with a signed driver.

If you don’t enable test mode by using BCDedit, and you have a test-signed driver installed, your computer will not boot. If you use DISM to remove the driver, all instances of the reflected driver package might not be removed. So, we recommend that you don’t deploy images that have test-signed drivers installed.

Additional Resources

These websites provide more information about device-driver requirements:

For more information about PnP driver deployment, see PnP Device Installation Signing Requirements.

For more information about digital signatures and developing drivers, see the relevant page on the Windows Hardware Developer Central website.