Рішення помилок встановлення програм MSI та Appx у Windows

Коли інсталяція Windows завершується невдачею, з’являються загадкові повідомлення, шістнадцяткові коди та журнали, повні даних, легко впасти в відчай. Помилки пакета MSI, APPX та MSIX Вони можуть бути спричинені тисячею різних причин: від ненадійного сертифіката до відсутньої інфраструктури, проблем із самою службою інсталятора Windows або з протоколом розповсюдження, що використовується для файлу .appinstaller.

У цій статті ми спокійно та ґрунтовно розберемо найпоширеніші причини збоїв під час встановлення програм MSI та Appx/MSIX у Windows 10 та Windows 11, а також розглянемо, як їх крок за кроком виправити. Ви побачите, як це зробити. перевірте журнали інсталятора Windows Ми вже використовуємо PowerShell для встановлення пакетів, і подивимося, що робити, коли проблема на сервері або в самій конфігурації бокового завантаження.

Помилки MSIEXEC.EXE та msi.dll під час встановлення пакетів MSI

Один із найнеприємніших сценаріїв — це коли класичний інсталятор Windows, тобто MSIEXEC.EXEВін або аварійно завершує роботу, або генерує помилки в журналі програм. Типовий приклад журналу помилок може відображати дані, подібні до цих (адаптованих): назва програми, що вийшла з ладу, MSIEXEC.EXE, модуль, що вийшов з ладу msi.dll, код винятку 0xc0000005, шлях до програми C:\WINDOWS\SysWOW64\MSIEXEC.EXE та шлях до модуля C:\WINDOWS\System32\msi.dll.

Коли з'являється код винятку 0xc0000005 Зазвичай це вказує на проблему доступу до пам'яті (порушення доступу). У контексті інсталятора Windows це може бути пов'язано з пошкодженим компонентом, втручанням антивіруса, конфліктуючими DLL-файлами або драйверами, які не були належним чином зареєстровані під час інсталяції. У цих випадках, перш ніж намагатися перевстановити систему, рекомендується виконати кілька тестів і перевірок.

Дуже поширеною помилкою під час встановлення MSI-пакетів є Помилка 1721Це повідомлення, яке зазвичай відображається приблизно так: «Виникла проблема з цим пакетом інсталятора Windows. Не вдалося запустити програму, необхідну для завершення інсталяції. Зверніться до служби підтримки або постачальника пакета». Це повідомлення вказує на те, що MSI намагається виконати настроювану дію, яка викликає виконуваний файл або скрипт (наприклад, команду PowerShell), і щось заважає її завершенню.

У реальних випадках, таких як встановлення Оновлення Surface Dock Для драйверів Surface Book 2 інсталятор запускає дію InstallDriversPnP, розташовану за шляхом, таким як C:\Program Files\SurfaceUpdate\, з командою PowerShell, яка виконує pnputil для всіх знайдених файлів .inf. Якщо цю команду неможливо виконати (через дозволи, політики, антивірус або обмежений PowerShell), інсталяція переривається з помилкою 1721.

Якщо користувач уже намагався перезапустити службу інсталятора Windows, скористатися засобами усунення несправностей інсталяції/видалення та перевірити сумісність програм без успіху, причина зазвичай криється глибше: дозволи на виконання, цілісність системи або конфлікти з інструментами постачальника що змінюють стек встановлення.

Виправлення неполадок з основними інсталяторами MSI у Windows

Щоб усунути помилки з MSIEXEC.EXE та msi.dll організованим чином, рекомендується виконати низку основних кроків, які в багатьох випадках вирішують проблему без необхідності перевстановлення Windows. Мета полягає в тому, щоб переконатися, що служба інсталятора Windows працює правильно, що системні компоненти не пошкоджені, і що ніщо зовнішнє не блокує виконання настроюваних дій MSI.

Перший крок – перевірити, чи послуга Windows Installer Він не вимкнений і не завис. Навіть якщо користувач уже намагався зупинити та перезапустити його, варто перевірити, чи жодна групова політика або стороннє програмне забезпечення не змінили його параметри запуску чи дозволи, оскільки обмежена служба може спричиняти періодичні збої під час запуску певних пакетів.

Рекомендується використовувати власні інструменти системи для перевірки справності критично важливих файлів. Запустіть SFC / scannow А за необхідності запуск DISM /RestoreHealth з командного рядка з підвищеними правами може відновити пошкоджені компоненти, пов'язані з msi.dll або іншими залежностями інсталятора Windows. Багато помилок 0xc0000005, пов'язаних з інсталятором, зникають після виправлення невідповідностей у цих двійкових файлах.

Ще одним кроком діагностики є перевірка встановленого антивіруса або рішення безпеки. Деякі пакети безпеки можуть непомітно блокувати виконання скриптів PowerShell, pnputil або тимчасових виконуваних файлів MSI, викликаючи помилки, такі як 1721. Спроба тимчасово вимкнути антивірус або додати винятки для конкретного інсталятора може допомогти виключити цю причину без необхідності кардинальних змін у системі.

Якщо проблема виникає лише з інсталяторами певного виробника (наприклад, Surface Dock Updater або пакетами драйверів), рекомендується перевірити наявність будь-яких попередніх версій, залишків старих інсталяцій або частково видалених пакетів. Сканування за допомогою спеціалізованих утиліт, призначених для очищення застарілих інсталяцій MSI, разом із ручним видаленням застарілих записів у розділі «Програми та засоби», може вирішити ситуації, коли інсталятор помилково вважає, що попередні версії вже існують і потребують оновлення або видалення.

Вимоги до встановлення та завантаження програм APPX та MSIX

Коли ми говоримо про файли .appx, .appxbundle, .msix та msixbundleТепер ми вступаємо у сферу сучасних програм Windows (UWP та подібних) та механізмів їх розповсюдження та завантаження. У Windows 10 та пізніших версіях встановлення таких пакетів, особливо поза межами Microsoft Store, вимагає виконання низки часто недооцінених передумов.

По-перше, пристрій повинен довіряти сертифікат, за допомогою якого підписано пакетЯкщо сертифікат походить від центру сертифікації, який розпізнає система, Windows зазвичай автоматично вважає його довіреним. Проблема зазвичай виникає із самопідписаними сертифікатами або сертифікатами, виданими внутрішнім центром сертифікації в організації, які дуже поширені в середовищах розробки та тестування.

Крім того, важливо, щоб версія Windows 10, яка використовується, підтримувала обидва Схема файлу .appinstaller наприклад, використовуваний протокол розповсюдження. Не всі версії Windows 10 підтримують однаковий набір функцій для інсталятора програм, тому завантаження програми за допомогою методу, якого немає у вашій конкретній збірці, призведе до помилки розгортання, навіть якщо пакет виглядає дійсним.

У системах до Windows 10 версії 1607 завантаження збоку можна було виконати лише через PowerShell за допомогою команди Add-AppxPackage, без графічного інтерфейсу чи інсталятора. З розвитком версій додаються нові можливості, такі як встановлення через HTTP, налаштування перевірки оновлень або використання файлу .appinstaller, тобто рекомендований метод встановлення залежить від конкретної збірки.

Тому, перш ніж звинувачувати пакет чи сервер, важливо визначити, чи підтримує версія та збірка Windows 10 користувача процес інсталяції. Пакет, розроблений для розширених сценаріїв розгортання, може не працювати на старіших версіях, які ще не реалізують ці функції.

Сумісність версій Windows 10 з .appinstaller та sideload

З кожним оновленням Windows 10 покращується досвід встановлення програм Appx та MSIX, і це відображається на підтримці таких функцій, як HTTP-доступ, спільні папки та автоматичні оновлення. Розуміння того, що пропонує кожна версія, запобігає витрачанню часу на методи, які просто не підтримуються.

У збірці 10240, тобто версії 1507 Windows 10, функція нестандартного завантаження доступна лише через PowerShell та команда Add-AppxPackageПоки що немає інсталятора програм із графічним інтерфейсом для .appx, тому будь-яка спроба використати файл .appinstaller або протоколи автоматичного встановлення буде невдалою.

З оновленням 1511 (збірка 10586) ця ситуація зберігається: завантаження збоку залишається обмеженим Add-AppxPackage з командного рядка, що змушує адміністраторів працювати безпосередньо з локальними скриптами та пакетами без зручності спеціального інсталятора.

Основний стрибок відбувся зі збіркою 14393 (ювілейне оновлення, 1607). Саме тут вперше представлено наступне: Інсталятор програмВін здатний встановлювати файли .appx та .appxbundle. Хоча використання файлу .appinstaller ще не підтримується, встановлення через графічний інтерфейс вже спрощено, особливо в середовищах з кінцевими користувачами, не знайомими з PowerShell.

У версії 1703 (збірка 15063, оновлення для творців) інсталятор програм отримав можливість завантажувати залежності програм з Microsoft Store (у режимі випуску). Це дуже корисно для програм, які потребують додаткових фреймворків, оскільки система сама шукатиме та завантажуватиме їх без ручного втручання.

Оновлення Fall Creators (версія 1709, збірка 16299) представляє Файл .appinstallerЦе ключовий фактор для забезпечення автоматичних оновлень. Наразі єдиним підтримуваним методом розповсюдження є кінцеві точки HTTP, а перевірки оновлень не налаштовуються та відбуваються фіксовано кожні 24 години.

Нарешті, починаючи з версії 1803 (збірка 17134, оновлення за квітень 2018 року), підтримка файлу .appinstaller розширена, що дозволяє доступ до нього з спільні папки та UNC-шляхиТакож додано опції для налаштування частоти перевірки оновлень. Ці покращення роблять розгортання корпоративних програм за допомогою App Installer набагато гнучкішим.

Помилки сертифікатів довіри та ненадійних пакетів

Одна з найпоширеніших причин, чому інсталятор програм відмовляється встановлювати пакет Appx або MSIX, полягає в тому, що Сертифікат підпису не є надійним для пристрою. Типовим симптомом є повідомлення про те, що пакет не є надійним, і встановлення блокується без надання додаткової інформації.

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

Щоб пристрій довіряв цим нестандартним сертифікатам, користувач із правами локального адміністратора повинен використовувати засіб керування сертифікатами комп’ютера (MMC) та імпортувати сертифікат до одного з дозволених місць зберігання. Рекомендовані місця розташування: «Локальна команда: Довірені особи» та, менш бажано, «Локальна команда: Довірені кореневі організації».

Консоль сертифікатів комп’ютера можна легко знайти, знайшовши «сертифікати» в меню «Пуск» і вибравши опцію, яка відкриває оснащення адміністрування для комп’ютера, а не лише для поточного користувача. Опинившись там, просто імпортуйте сертифікат підпису з пакета (зазвичай з розширенням .cer) у відповідний контейнер і завершіть роботу майстра.

Після успішного імпорту, коли ви знову запустите інсталятор програм, система розпізнає сертифікат як довірений. У цей момент інтерфейс вкаже, що Пакет надійний і дозволить завершити встановлення без відображення попередження про ризик або попереднього блокування.

Залежності фреймворку не встановлено

Сучасні програми Windows 10 можуть використовувати різні фреймворки залежно від мови та технології, що використовуються для їх розробки. Якщо ці залежності відсутні на комп’ютері, інсталяція може завершитися невдачею з незрозумілими повідомленнями або просто відображати, що розгортання програми неможливо завершити.

Заявки, написані в C# або VB .NET Зазвичай вони вимагають наявності пакетів .NET Runtime та .NET Framework, що відповідають версії, за допомогою якої було скомпільовано програму. Хоча Windows за замовчуванням містить кілька версій .NET, деякі програми використовують певні середовища виконання, упаковані як залежності Appx або MSIX.

Тим часом, програми, розроблені в C + + Зазвичай для них потрібні пакети бібліотек середовища виконання Visual C++, відомі як vclibs. Ці залежності можна розповсюджувати як частину пакета або встановлювати окремо з магазину Microsoft Store чи веб-сайту Microsoft.

Якщо ці залежності встановлено неправильно, помилка може проявлятися як збій розгортання, аварійне завершення роботи програми під час запуску або загальне повідомлення, в якому явно не згадується фреймворк. Щоб уникнути таких проблем, рекомендується завжди перевіряти, чи доступні залежності, перелічені в маніфесті пакета, і чи має пристрій дозвіл на їх завантаження або встановлення.

У випадках, коли доступ до Інтернету обмежено або Магазин вимкнено політикою, інсталятор програм може не мати змоги автоматично отримати ці фреймворки. У таких випадках стратегія передбачає... Розповсюджуйте залежності разом з основним пакетомабо через PowerShell, або через внутрішній репозиторій, доступний через HTTP або UNC.

Проблеми з доступом до файлів та неправильні типи MIME

Ще однією поширеною причиною збоїв встановлення програм Appx та MSIX є те, як файли надходять із сервера або як до них здійснюється доступ. Під час встановлення з кінцевої точки HTTP кожен компонент (appinstaller, пакети, комплекти) має бути доступним та обслуговуватися з правильним типом MIME та заголовками.

Перш за все, доцільно перевірити, якомога простіше, що Всі необхідні файли доступніЯкщо HTML-сторінку було створено за допомогою Visual Studio для публікації програми, вона зазвичай містить посилання на різні ресурси. Перейшовши за цими посиланнями у браузері, ви можете перевірити, чи файл .appinstaller, файл .appx або .appxbundle, або файли .msix та msixbundle працюють правильно та завантажуються без помилок.

Важливо, щоб веб-сервер призначив правильний MIME-тип до кожного розширення. Якщо файл .appx подається як звичайний текст або із загальним типом вмісту (Content-Type), інсталятор програми може відхилити його або неправильно інтерпретувати його вміст. Налаштування конфігурації сервера (IIS, Apache, Nginx або іншого) для включення офіційних типів MIME для .appx, .appxbundle, .msix, msixbundle та .appinstaller є важливим кроком у професійних середовищах розгортання.

Окрім типу MIME, усі відповідні HTTP-відповіді повинні містити заголовок Зміст-довжина Це стосується як запитів GET, так і запитів HEAD. Якщо сервер не встановлює це значення або встановлює його неправильно, можуть з’являтися помилки, такі як «Встановлення програми не вдалося з повідомленням про помилку: Операція інсталятора програми не вдалася з кодом помилки 0x80072F76. Деталі: Невідома помилка (0x80072f76)» або подібні помилки, пов’язані з проблемами часткового завантаження.

Коли інсталяція виконується зі спільної папки або UNC-шляху замість HTTP, підхід змінюється, але основна ідея залишається незмінною: усі файли повинні бути доступні з відповідними дозволами для користувача, який запускає інсталяцію, без блокування антивірусом або мережевих фільтрів, що обмежують доступ до необхідних ресурсів.

Помилки з URL-адресами та повідомлення «Параметр неправильний»

У деяких випадках проблема полягає не в пакеті, сертифікаті чи сервері, а в самому пакеті. URL-адреса, яка використовується для запуску інсталяціїЦе трапляється особливо під час використання протоколу ms-appinstaller для запуску програми з браузера або за посиланням на веб-сторінці.

Наразі ms-appinstaller не підтримує так звані «марні URL-адреси», що змушує вас дотримуватися дуже конкретного правила: параметр source URL-адреси повинен закінчуватися саме на .appinstallerНедостатньо просто перенаправити файл .appinstaller; навіть якщо оригінальна URL-адреса не закінчується цим розширенням, спроба встановлення все одно не вдасться.

Коли ця умова не виконується, інсталятор програм часто повертає загальну помилку про те, що «параметр неправильний». Це повідомлення зазвичай бентежить користувача, оскільки в ньому безпосередньо не згадується URL-адреса, але корінь проблеми полягає саме у форматі посилання, яке запускає інсталяцію.

Рішення просте з технічної точки зору, хоча воно вимагає налаштування способу генерації посилань: ви повинні переконатися, що значення вихідного параметра Шлях, що передається протоколу ms-appinstaller, має вказувати на адресу, останній фрагмент (шлях) якої буквально закінчується на .appinstaller. Будь-яке проміжне перенаправлення також має дотримуватися цього формату, щоб уникнути порушення потоку.

У корпоративних середовищах, де використовуються скорочувачі URL-адрес або проксі-сервери публікацій, важливо перевірити конфігурацію, щоб переконатися, що остаточне розширення посилань не змінено або не замінено псевдонімами без .appinstaller, інакше інсталяція систематично завершуватиметься невдачею на всіх комп’ютерах, що залежать від цих шляхів.

Розширена діагностика за допомогою інсталятора програм та PowerShell

Коли інсталятор програм не завершує встановлення, окрім відображення основних повідомлень на екрані, необхідна подальша діагностика. Це включає як безпосередню перевірку файлів пакета, так і аналіз певних журналів, що генеруються інфраструктурою розгортання Appx у Windows.

Ефективний метод полягає в вручну завантажити файл пакета (наприклад, файл .appx або .msix) у локальній папці та спробуйте встановити його за допомогою PowerShell за допомогою команди Add-AppxPackage. Якщо пакет також містить файл .appinstaller, ви також можете завантажити та запустити цей файл за допомогою Add-AppxPackage -AppInstaller, що допоможе вам визначити, чи проблема полягає в інтерфейсі інсталятора програм, чи в самому механізмі розгортання.

Коли ці команди не виконуються, повідомлення про помилку, яке повертає PowerShell, зазвичай містить набагато детальнішу інформацію, ніж просте графічне попередження в інсталяторі програм. Воно може містити посилання на відсутні залежності, недоступні шляхи, конфлікти версій або обмеження політик, які не відображаються у стандартному інтерфейсі.

Окрім тестування PowerShell, Windows генерує певні події, які значно допомагають зрозуміти, що відбувається. У засобі перегляду подій, у дереві журналів програм і служб -> Microsoft -> Windows -> AppxDeployment-Server, реєструються події, які описують кожну спробу встановлення, оновлення або видалення сучасних програм.

У цій самій області система може створювати додаткові файли журналів у таких розташуваннях, як %LocalAppData%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir. Ці журнали містять детальну інформацію про процес інсталяції, результати викликів API розгортання та точні причини помилок.

Аналізуючи ці журнали, адміністратори можуть визначити, чи проблема пов'язана з конфлікт ідентифікації пакетаЦе може бути пов’язано з уже встановленою версією, яка перешкоджає оновленню, обмеженнями, накладеними політиками організації, або збоями під час завантаження проміжних файлів, що полегшує застосування відповідного виправлення без спроб рішень наосліп.

Використання wsreset та пов'язані з цим проблеми з Microsoft Store

Іноді збої в установці або оновленні програм, що використовують App Installer, пов'язані з проблемами в самій програмі. Microsoft магазин або його внутрішній кеш. Хоча може здаватися, що Магазин не пов’язаний безпосередньо з певним MSI або інсталятором Appx, існують сценарії, коли очищення його внутрішнього стану вирішує помилки, які, здавалося б, не були пов’язані.

Поширеною рекомендацією на форумах підтримки є виконання команди wsresetЩоб це зробити, просто відкрийте меню «Пуск», введіть «wsreset», клацніть правою кнопкою миші на результаті та виберіть «Запуск від імені адміністратора». Чорне вікно (консоль) ненадовго відкриється, а потім автоматично закриється, поки Microsoft Store перезавантажиться.

Ця процедура скидає кеш Магазину без видалення вже встановлених програм або даних користувача, але вона може виправити невідповідності що перешкоджають правильному виявленню оновлень або блокують правильну взаємодію між Магазином, Інсталятором програм та іншими компонентами системи.

У деяких системах періодичний запуск wsreset та перезапуск вирішував повторювані проблеми, коли користувач завжди бачив ті самі помилки інсталяції, незважаючи на те, що він пробував інші рішення, такі як перезапуск служб або запуск діагностичних інструментів від Surface чи інших виробників.

Хоча це не панацея від усіх помилок MSI або Appx, включення wsreset до списку швидкої перевірки – це неінвазивний варіант, який, хоча й не завжди вирішує проблему, допомагає виключити, що джерело збою криється в управлінні магазином або його інтеграції з системою.

Інструменти діагностики та підтримки виробника

Коли помилки впливають на певні продукти, такі як пристрої Surface, багато користувачів звертаються до офіційних діагностичних утиліт, таких як Набір інструментів для поверхневої діагностикиЦі інструменти можуть виявляти проблеми з мікропрограмою, драйвером або конфігурацією обладнання, які не очевидні лише за допомогою типових повідомлень інсталятора Windows.

Нерідко після запуску Surface Diagnostic Toolkit звіт вказує на те, що щось було виправлено, і пропонує перезавантажити комп’ютер. Однак користувачі повідомляють, що під час спроби перевстановити проблемний пакет MSI вони стикаються з тією ж помилкою, що й раніше, що може бути досить неприємно.

У таких випадках важливо поєднувати використання цих утиліт із загальними діагностичними кроками, описаними вище: перевірка служби інсталятора Windows, запуск перевірок SFC та DISM, сканування антивірусного програмного забезпечення, аналіз дозволів та запуск інсталяторів від імені адміністратора. Цей набір інструментів може виправити певні компоненти пристрою, але він не завжди вирішує проблему. конфлікти програмного забезпечення сторонніх розробників або проблеми на рівні розгортання застосунків.

Під час пошуку рішень на форумах пам’ятайте, що багато тем зрештою посилаються на одні й ті ж загальні відповіді: перезапустіть службу, запустіть засіб усунення несправностей, використовуйте режим сумісності тощо. Хоча ці поради є гарною відправною точкою, вони часто не вирішують основні причини, такі як сертифікати, типи MIME, залежності або помилки протоколу, які ми обговорювали.

Якщо після завершення всіх перевірок та застосування можливих виправлень (сертифікати, версії Windows, залежності, сервер, URL-адреса, PowerShell та журнали) проблема залишається лише з певним продуктом, тоді має сенс відкрити звернення до служби підтримки постачальника, додавши детальні журнали з AppxDeployment-Server та реєстру програм Windows, щоб постачальник міг дослідити, чи є проблема. дефект інсталяційного пакету.

З огляду на всі ці фактори, стає зрозуміло, що помилки встановлення програм MSI та Appx, хоча на перший погляд здаються випадковими або невирішуваними, зазвичай виникають через дуже специфічні причини: неправильно розміщений сертифікат, неправильний тип MIME, відсутній заголовок HTTP, версія Windows, яка не підтримує певну функцію, невдалена залежність фреймворку або заблокована команда PowerShell. Методичне вирішення проблеми за допомогою засобу перегляду подій, PowerShell та правильного налаштування сертифікатів і сервера дозволяє вирішити більшість проблем, не вдаючись до радикальних рішень, таких як повна перевстановлення операційної системи.