Руководство по устранению неполадок MSIX

В этом руководстве рассматриваются наиболее распространенные ошибки MSIX при установке, подписывании, доставке установщика приложений, отсутствии зависимостей и поведении среды выполнения. Каждый раздел включает симптом, первопричину и разрешение.

Для полного журнала событий развертывания откройте Просмотр событий и перейдите по адресу: Applications and Services Logs → Майкрософт → Windows → AppxDeployment-Server → Operations

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

0x80070005 — доступ запрещен

Симптом:Add-AppxPackage или установщик приложений завершается ошибкой с кодом 0x80070005.

Применимо к: Windows 10 и более поздних версий Windows 11

Причины и исправления:

Установка пакета заблокирована, так как приложение используется

Симптом. Обновление или повторная установка завершается ошибкой, указывающей, что пакет используется. В Просмотр событий видно, что операция развертывания отклонена.

Применимо к: Windows 10 и более поздних версий Windows 11

Исправление. Закройте все запущенные экземпляры приложения перед обновлением. Если приложение является фоновой службой или имеет фоновую задачу, возможно, потребуется завершить следующие действия:

Get-Process -Name "MyApp" | Stop-Process -Force
Add-AppxPackage -Path .\updated-app.msix

Для корпоративных развертываний рекомендуется планировать обновления во время обслуживания с помощью Intune или Configuration Manager.

Несоответствие минимальной версии или архитектуры

Symptom: установка завершается ошибкой, например "Не удалось установить пакет, так как он несовместим с этой версией Windows" или "Пакет не применим к этому компьютеру".

Применимо к: Windows 10 и более поздних версий

Причины и исправления:

Команда Add-AppxPackage выполняется успешно, но приложение отсутствует в меню "Пуск".

Симптом: PowerShell сообщает об успешном выполнении, но приложение не отображается в меню "Пуск" или списке приложений.

Применимо к: Windows 10 и более поздних версий Windows 11

Распространенные причины:

• Установка для каждого пользователя и каждого компьютера: Add-AppxPackage устанавливается только для текущего пользователя. Если вы работаете от имени администратора, но предполагаете, что приложение должно использоваться другим пользователем, используйте Add-AppxProvisionedPackage вместо этого.
• Пакет зарегистрирован, но плитка не закреплена: приложение установлено, но меню "Пуск" не обновлено. Выйдите и войдите обратно или проверьте параметры → Приложения , чтобы подтвердить установку.
• Отсутствует запись меню "Пуск" в манифесте: Проверьте, что элемент <Application> в AppxManifest.xml содержит запись VisualElements с допустимым значением Square150x150Logo.
• Конфликт с повторяющимся именем семейства пакетов: если более новая или более старая версия приложения уже установлена с тем же именем семейства пакетов, новая установка может автоматически заменить ее. Проверьте с помощью Get-AppxPackage -Name "YourPackageFamilyName".

Ошибки подписывания и сертификата

Сертификат не является доверенным (0x800B0109)

Симптом: установка завершается ошибкой 0x800B0109 : "Цепочка сертификатов обработана, но завершена в корневом сертификате, который не является доверенным поставщиком доверия".

Применимо к: Windows 10 и более поздних версий Windows 11

Причина. Сертификат, используемый для подписи пакета, не находится в хранилищах доверенных сертификатов устройства. Это часто происходит при использовании самозаверяющих сертификатов для разработки.

Исправлено. Импорт сертификата подписи в локальное хранилище компьютеров устройства → доверенных людей (а не текущее хранилище пользователей — установщик приложений проверяет только хранилище компьютеров):

# Export the certificate from the package first (if needed)
$cert = (Get-AuthenticodeSignature -FilePath .\app.msix).SignerCertificate
Export-Certificate -Cert $cert -FilePath .\app-cert.cer

# Import into Trusted People (requires administrator rights)
Import-Certificate -FilePath .\app-cert.cer -CertStoreLocation Cert:\LocalMachine\TrustedPeople

Для рабочих приложений используйте сертификат, выданный доверенным центром сертификации или Azure Signing Artifact (ранее Trusted Signing), которая восходит к корневому центру сертификации проверки подлинности Майкрософт — по умолчанию доверен на Windows 10 версии 1809 и более поздних версиях, а также в Windows 11.

несоответствие имени Publisher (0x8007000B, идентификатор события 150)

ru-RU: Symptom: SignTool завершился с ошибкой 0x8007000B, а Просмотр событий (операционный журнал AppxPackagingOM) отображает Event ID 150:

error 0x8007000B: The app manifest publisher name (CN=Contoso) must match
the subject name of the signing certificate (CN=Contoso, C=US).

Применимо к: Windows 10 и более поздних версий Windows 11

Cause: атрибут Publisher в AppxManifest.xml должен точно соответствовать имени субъекта сертификата подписи, включая все поля различающихся имен в одном порядке.

Исправление:

1. Получите точное имя субъекта из сертификата:

   (Get-Item Cert:\CurrentUser\My\THUMBPRINT).Subject
   # Example output: CN=Contoso, C=US
   

2. Обновление AppxManifest.xml до точного соответствия:

   <Identity Name="Contoso.MyApp"
             Publisher="CN=Contoso, C=US"
             ... />
   

3. Упакуйте заново с MakeAppx.exe и подпишите заново.

Ошибки установщика приложений и веб-доставки

Несоответствие версии схемы в файле .appinstaller

Симптом: установщик приложений не может проанализировать или обработать .appinstaller файл, часто с универсальной ошибкой о недопустимом файле или неподдерживаемой схеме.

Применимо к: Windows 10 и более поздних версий (см. таблицу)

Cause: атрибут Uri корневого элемента <AppInstaller> указывает версию схемы, которую установленная версия Windows не поддерживает.

Версии схем по выпускам Windows

Fix: Установите URI схемы в .appinstaller файле на минимальную версию, которую поддерживает самая старая версия вашей ОС.

<?xml version="1.0" encoding="utf-8"?>
<AppInstaller Uri="https://example.com/app.appinstaller"
              Version="1.0.0.0"
              xmlns="http://schemas.microsoft.com/appx/appinstaller/2017">

Не используйте последнюю версию схемы, если необходимо поддерживать старые версии Windows 10.

Файлы, поданные с неправильным типом MIME или отсутствующим заголовком Content-Length

Симптом: установщик приложений выдает ошибку при установке из точки доступа HTTP/HTTPS. Ошибка может быть универсальной, например 0x80072F76 ("Неизвестная ошибка") или "Сбой установки приложения".

Применимо к: Windows 10 и более поздних версий

Причина: веб-сервер обслуживает .msixфайл или .msixbundle.appinstaller файл с неправильным Content-Type заголовком или пропускает Content-Length заголовок.

Исправление. Настройте веб-сервер для обслуживания файлов, связанных с MSIX, с правильными типами MIME:

Кроме того, убедитесь, что каждый ответ содержит допустимый Content-Length заголовок — это относится к обоим GET и HEAD запросам.

Для IIS добавьте сопоставления типов MIME в web.config. Для Статические веб-приложения Azure или GitHub Pages типы MIME для этих расширений могут потребовать явной настройки или пользовательского решения размещения.

Отсутствующие зависимости

Пакет платформы не установлен (VCLibs, .NET, Windows App SDK)

Symptom: приложение устанавливается успешно, но завершается ошибкой при запуске, или установка терпит неудачу с ошибкой зависимости, ссылающейся на имя семейства пакетов, например Майкрософт.VCLibs, Майкрософт.WindowsAppRuntime или Майкрософт.NET.Native.

Применимо к: Windows 10 и более поздних версий Windows 11

Общие платформы и где их получить:

Исправление для разработчиков. При локальной установке Add-AppxPackage добавьте -DependencyPackages параметр или сначала установите пакеты фреймворка:

# Install VCLibs dependency first
Add-AppxPackage -Path .\Microsoft.VCLibs.x64.14.00.Desktop.appx

# Then install your app
Add-AppxPackage -Path .\MyApp.msix

Исправление для распространения: если вы распространяете за пределами Магазина, включите пакеты среды выполнения в файл в .appinstallerразделе <Dependencies> :

<Dependencies>
  <Package Name="Microsoft.VCLibs.140.00.UWPDesktop"
           Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US"
           Version="14.0.30704.0"
           Uri="https://aka.ms/Microsoft.VCLibs.x64.14.00.Desktop.appx"
           ProcessorArchitecture="x64"/>
</Dependencies>

SignTool не найден в CI/CD

Symptom: конвейер CI/CD (GitHub Actions, Azure DevOps) завершается ошибкой, например 'signtool' is not recognized as an internal or external command или SignTool.exe: not found.

Применимо к: Windows 10 и более поздним версиям, Windows 11 (подписывающее устройство)

Cause: SignTool является частью пакета SDK Windows и по умолчанию не входит в стандартные образы запуска CI.

Fixes:

Option 1 — установка Windows SDK в конвейере (GitHub Actions):

- name: Install Windows SDK
  run: |
    winget install --id Microsoft.WindowsSDK.10.0.22621 --accept-source-agreements --accept-package-agreements

Вариант 2. Используйте интерфейс командной строки WinApp (простейший для подписи MSIX):

- name: Install WinApp CLI
  run: winget install -e --id Microsoft.WinAppCLI --source winget --accept-source-agreements
- name: Sign MSIX
  run: winapp sign output\MyApp.msix --cert ${{ secrets.CERT_THUMBPRINT }}

Вариант 3 — используйте подписание артефактов в Azure (рекомендуется для использования в рабочей среде):

- name: Sign with Azure Artifact Signing
  uses: azure/trusted-signing-action@v0
  with:
    azure-tenant-id: ${{ secrets.AZURE_TENANT_ID }}
    azure-client-id: ${{ secrets.AZURE_CLIENT_ID }}
    azure-client-secret: ${{ secrets.AZURE_CLIENT_SECRET }}
    endpoint: ${{ secrets.AZURE_ARTIFACT_SIGNING_ENDPOINT }}
    trusted-signing-account-name: ${{ secrets.AZURE_CODE_SIGNING_NAME }}
    certificate-profile-name: ${{ secrets.AZURE_CERT_PROFILE_NAME }}
    files-folder: ${{ github.workspace }}\output
    files-folder-filter: msix

Полное пошаговое руководство по настройке подписи для CI/CD см. в пошаговом руководстве по подписанию пакета MSIX.

Поведение среды выполнения и виртуализации

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

Почему записи файлов исчезают (перенаправление файлов VFS)

Симптом: приложение записывает файл в путь вида C:\Program Files\MyApp\config.ini во время выполнения, но файл не отображается там. Приложение правильно считывает значение, но другие процессы или пользователи не видят его.

Применимо к: Windows 10 и более поздних версий Windows 11

Объяснение. MSIX использует перенаправление виртуальной файловой системы (VFS). Записи в защищенные системные пути автоматически перенаправляются в отдельный контейнер для каждого пользователя.

%LocalAppData%\Packages\<PackageFamilyName>\LocalCache\Local\VFS\

Это сделано преднамеренно — это предотвращает изменение общих системных областей приложениями MSIX, поддерживая чистое удаление.

Параметры:

• Вместо этого используйте папки данных приложения: записывайте в ApplicationData.Current.LocalFolder (WinRT) или %LocalAppData%\Packages\<PFN>\LocalState\, чтобы обеспечить сохранение данных для каждого пользователя.
• Использовать AppData\Roaming для данных, которые должны перемещаться по устройствам.
• Проверьте контейнер VFS , чтобы просмотреть перенаправленные файлы: %LocalAppData%\Packages\<PackageFamilyName>\LocalCache\

Дополнительные сведения о том, какие пути виртуализированы, см. в статье "Устранение неполадок среды выполнения в контейнере MSIX".

Почему запись реестра исчезает (виртуализация реестра)

Симптом: приложение записывает в HKEY_LOCAL_MACHINE\Software\MyApp\ во время выполнения, но значение не отображается другим процессам и не сохраняется после переустановки.

Применимо к: Windows 10 и более поздних версий Windows 11

Объяснение. MSIX перехватывает записи HKLM\Software и перенаправляет их в куст реестра для каждого пакета, изолированный от остальной части системы. При удалении hive удаляется.

Параметры:

• Записываемые параметры для каждого пользователя — они HKEY_CURRENT_USER\Software\<AppName> виртуализированы и сохраняются.
• Используйте API-интерфейсы Windows ApplicationData для хранилища структурированных параметров.
• Объявите записи реестра, которые должны быть общими для пользователей или процессов с помощью механизма <Extensions> / <com:Extension>.

Для более детального изучения поведения контейнера MSIX см. статью Как работают упакованные настольные приложения в Windows.

Ограничения Windows 10 MSIX

Для некоторых функций MSIX требуется Windows 11 или определенная версия Windows 10. Если вы развертываете на Windows 10 устройствах, помните следующее.

Компоненты, требующие Windows 10 версии 2004 (сборка 19041) или более поздней версии

Функции, требующие Windows 11

Windows 10 устройства старше версии 1709

MSIX изначально не поддерживается в версиях Windows 10 до 1709 (Fall Creators Update). Чтобы развернуть пакеты MSIX на этих устройствах, используйте MSIX Core, который предоставляет уровень совместимости для версий нижнего уровня Windows 10.

Расширения манифеста

Некоторые расширения пространства имен AppxManifest.xml доступны только для Windows 11. Объявление их в пакете, нацеленном на Windows 10, может вызвать ошибку проверки схемы во время упаковки или привести к отказу во время установки. Проверьте ссылку на схему манифеста пакета приложения , чтобы получить MinOSVersion список для каждого расширения.

Совет по отладке

Чтобы проверить, какие функции MSIX доступны в определенной сборке Windows 10, проверьте функции MSIX и поддерживаемые платформы, в которой перечислены возможности доступности компонентов по версии ОС.

Связанные ресурсы

• Общие сведения о пакете MSIX
• Подпишите ваш пакет MSIX — полное руководство
• Известные проблемы и устранение неполадок для SignTool
• Устранение неполадок установщика приложений
• Устранение неполадок среды выполнения в контейнере MSIX
• Устранение неисправностей упаковки, развертывания и запросов приложений Windows