Guide de résolution des problèmes MSIX

Ce guide décrit les erreurs MSIX les plus courantes lors de l’installation, de la signature, de la remise du programme d’installation d’application, des dépendances manquantes et du comportement d’exécution. Chaque section inclut le symptôme, la cause racine et la résolution.

Pour obtenir un journal complet des événements de déploiement, ouvrez observateur d'événements et accédez à : Journaux des applications et services → Microsoft → Windows → AppxDeployment-Server → Opérationnel

Conseil / Astuce

Pour un ensemble consolidé de diagnostics, exécutez également application Windows Kit de certification avant de distribuer votre package.

Erreurs d’installation

0x80070005 — Accès refusé

Symptôme : Add-AppxPackage ou le programme d’installation d’application échoue avec le code 0x80070005d’erreur .

Applies à : Windows 10 et versions ultérieures, Windows 11

Causes et correctifs :

La cause Réparer
Exécution en tant qu’utilisateur standard sans élévation lorsque le package nécessite une installation par ordinateur Exécutez PowerShell en tant qu’administrateur. Pour installer pour tous les utilisateurs, utilisez Add-AppxProvisionedPackage plutôt que Add-AppxPackage.
Logiciel antivirus ou de sécurité bloquant le fichier de package Désactiver temporairement l’analyse en temps réel ou ajouter une exclusion pour le .msix / .msixbundle fichier
Package préparé pour un autre utilisateur et n'a pas été provisionné Utiliser Add-AppxProvisionedPackage pour approvisionner tous les utilisateurs
Listes de contrôle d’accès du système de fichiers bloquant l’accès en lecture au package Vérifier les autorisations sur le fichier de package avec icacls; accorder l’accès en lecture à l’utilisateur d’installation

Installation de package bloquée, car l’application est en cours d’utilisation

Symptôme : une mise à jour, une réparation, une suppression ou une réinstallation échoue et renvoie ERROR_PACKAGES_IN_USE (0x80073D02). Le message de déploiement indique que les ressources que l’opération modifie sont actuellement en cours d’utilisation.

Applies à : Windows 10 et versions ultérieures, Windows 11

MSIX ne modifie pas un package pendant qu’un processus l’utilise. Les exécutables et les DLL peuvent être mappés dans des processus en cours d’exécution, et une application peut avoir des opérations actives sur des fichiers, le Registre ou des communications interprocessus.

Correctif préféré : demandez à l’utilisateur de fermer l’application correctement avant de réessayer le déploiement. Recherchez les processus en arrière-plan, les services ou les composants hors processus qui utilisent le package.

Pour le déploiement sans assistance, choisissez l’une des options suivantes.

Arrêter l’application cible

Utilisez -ForceTargetApplicationShutdown pour arrêter les processus associés au package cible, de force si nécessaire :

Add-AppxPackage -Path .\updated-app.msix -ForceTargetApplicationShutdown

L’option équivalente Windows.Management.Deployment est AddPackageOptions.ForceTargetAppShutdown.

Cette option peut mettre fin à l’application si elle ne se ferme pas. N’utilisez pas l’arrêt forcé lorsque l’application peut perdre du travail non enregistré ou interrompre une opération de longue durée.

Différer l’inscription jusqu’à ce que le package ne soit plus utilisé

Utilisez -DeferRegistrationWhenPackagesAreInUse pour mettre à disposition la mise à jour et différer l’inscription :

Add-AppxPackage -Path .\updated-app.msix -DeferRegistrationWhenPackagesAreInUse

L’API équivalente est AddPackageOptions.DeferRegistrationWhenPackagesAreInUse. Windows termine l’enregistrement lorsque le package peut être mis à jour, par exemple lors d’une activation ultérieure.

Sur Windows 11, version 24H2 et ultérieures, un package peut déclarer l’élément de manifeste uap17:UpdateWhileInUse avec une valeur de defer. Ce paramètre au niveau du package est prioritaire sur les options d’arrêt forcé. Voir uap17:UpdateWhileInUse.

Les applications qui utilisent le SDK d’application Windows peuvent appeler PackageDeploymentManager.IsPackageRegistrationPending pour détecter une inscription précédemment différée pour l’utilisateur actuel. Un administrateur peut appeler IsPackageRegistrationPendingForUser pour vérifier le statut d’un autre utilisateur.

Différer la suppression du package

La suppression demande normalement l’arrêt de l’application. Pour différer la suppression à la place, appelez PackageManager.RemovePackageAsync avec RemovalOptions.DeferRemovalWhenPackagesAreInUse.

Pour les déploiements d’entreprise, planifiez des mises à jour perturbatrices pendant les fenêtres de maintenance et sélectionnez une stratégie de report ou d’arrêt qui correspond au risque de perte de données de l’application. Pour plus d’informations, consultez Maintenance en cours d’utilisation et ERROR_PACKAGES_IN_USE.

Incompatibilité de MinVersion ou de l’architecture

Symptom : l’installation échoue avec une erreur telle que « Impossible d’installer le package, car il n’est pas compatible avec cette version de Windows » ou « Le package n’est pas applicable à cet ordinateur ».

Applies à : Windows 10 et versions ultérieures

Causes et correctifs :

La cause Réparer
Le package MinVersion dans le manifeste est supérieur à la version du système d’exploitation Générer un package distinct ciblant la version du système d’exploitation installée ou mettre à jour l’appareil
Incompatibilité de l’architecture (par exemple, package arm64 sur un appareil x64) Générez et distribuez la variante d’architecture correcte ; utiliser un bundle (.msixbundle) pour traiter plusieurs architectures à partir d’un seul fichier
Le package cible une API Windows 11 uniquement sans vérification de compatibilité Ajouter une entrée TargetDeviceFamily pour les Windows 10 et les Windows 11, ou protéger l’appel d’API avec une vérification de version lors de l’exécution

Note

Utilisez des .msixbundle fichiers lors de la distribution dans des environnements à architecture mixte. Un bundle contient des packages pour plusieurs architectures et Windows sélectionne le package approprié au moment de l’installation.

Add-AppxPackage réussit, mais l’application est manquante dans le menu Démarrer

Symptôme : PowerShell signale la réussite, mais l’application n’apparaît pas dans le menu Démarrer ou la liste des applications.

Applies à : Windows 10 et versions ultérieures, Windows 11

Causes courantes :

  • Par utilisateur et par ordinateur : Add-AppxPackage installe uniquement l’utilisateur actuel. Si vous exécutez en tant qu'administrateur mais que vous souhaitez utiliser l'application pour un autre utilisateur, utilisez Add-AppxProvisionedPackage à la place.
  • Package enregistré mais vignette non épinglée : l’application est installée, mais le menu Démarrer n’a pas été actualisé. Déconnectez-vous et reconnectez-vous ou vérifiez les paramètres → Apps pour confirmer l’installation.
  • Entrée de menu Démarrer manquante dans le manifeste : vérifiez que l’élément <Application>AppxManifest.xml inclut une VisualElements entrée avec une entrée valide Square150x150Logo.
  • Conflit de noms de famille de packages en double : si une version plus récente ou antérieure de l’application est déjà installée avec le même nom de famille de packages, la nouvelle installation peut la remplacer en mode silencieux. Vérifiez avec Get-AppxPackage -Name "YourPackageFamilyName".

Erreurs de signature et de certificat

Note

Pour obtenir des codes d’erreur et des indicateurs SignTool détaillés, consultez problèmes connus et résolution des problèmes pour SignTool.

Certificat non approuvé (0x800B0109)

Symptôme : L’installation échoue avec une erreur 0x800B0109 : « Une chaîne de certificats traitée, mais arrêtée dans un certificat racine qui n’est pas approuvé par le fournisseur d’approbation ».

Applies à : Windows 10 et versions ultérieures, Windows 11

Cause : le certificat utilisé pour signer le package n’est pas dans les magasins de certificats approuvés de l’appareil. Cela est courant lors de l’utilisation de certificats auto-signés pour le développement.

Correctif : Importez le certificat de signature dans le magasin de l'ordinateur local de l’appareil → magasin Personnes de confiance (et non le magasin de l'utilisateur actuel – le programme d’installation d’application vérifie uniquement le magasin de l'ordinateur) :

# 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

Important

N’importez pas de certificats de signature dans le magasin Autorités de certification racines de confiance, sauf si le certificat est celui d’une autorité de certification racine. L’importation de certificats auto-signés non approuvés affaiblit la posture de sécurité de l’appareil.

Pour les applications de production, utilisez un certificat émis par une autorité de certification approuvée ou Azure Artifact Signing (anciennement Trusted Signing), qui établit une chaîne de certification avec l’autorité de certification racine Microsoft Identity Verification Root Certificate Authority, approuvée par défaut sur Windows 10 version 1809 et ultérieure, ainsi que sur Windows 11.

Incohérence du nom du fournisseur (0x8007000B, ID d’événement 150)

Symptom : SignTool échoue avec 0x8007000B et observateur d'événements (journal opérationnel AppxPackagingOM) affiche 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).

Applies à : Windows 10 et versions ultérieures, Windows 11

Cause : l’attribut Publisher dans AppxManifest.xml doit correspondre exactement au nom subject du certificat de signature, y compris tous les champs de nom unique dans le même ordre.

Correctif :

  1. Obtenez le nom exact du sujet à partir du certificat :

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

  2. Mise à jour AppxManifest.xml pour correspondre exactement :

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

  3. Recréez le package avec MakeAppx.exe puis signez-le à nouveau.

Conseil / Astuce

Lorsque vous utilisez Signature d'artefact Azure (anciennement Signature Approuvée), la valeur de l'éditeur dans votre manifeste doit correspondre à votre identité vérifiée, trouvée dans le portail Azure sous le champ Nom du sujet de votre profil de certificat.

Erreurs d’App Installer et de remise web

Incompatibilité de version de schéma dans le fichier .appinstaller

Symptôme : Le programme d’installation d’application ne parvient pas à analyser ou traiter le .appinstaller fichier, souvent avec une erreur générique concernant un fichier non valide ou un schéma non pris en charge.

Applies à : Windows 10 et versions ultérieures (dépendant de la version – voir la table)

Cause : l'attribut Uri de l'élément racine <AppInstaller> spécifie une version de schéma que la version installée de Windows ne prend pas en charge.

Versions de schéma par version de Windows :

version de Windows Version minimale prise en charge du schéma
Windows 10 version 1709 1.0.0.0
Windows 10 version 1803 1.1.0.0
Windows 10 version 1809 1.2.0.0
Windows 10 version 1903 et ultérieure, Windows 11 1.3.0.0, 1.4.0.0, 1.5.0.0

Correctif : définissez l’URI du schéma dans votre fichier .appinstaller sur la version minimale requise par le système d’exploitation le plus ancien pris en charge :

<?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">

Évitez d’utiliser la dernière version du schéma si vous devez prendre en charge les versions antérieures de Windows 10.

Fichiers servis avec un type MIME incorrect ou une longueur de contenu manquante

Symptôme : Le programme d’installation d’application échoue lors de l’installation à partir d’un point de terminaison HTTP/HTTPS. L’erreur peut être générique, par 0x80072F76 exemple (« Erreur inconnue ») ou « Échec de l’installation de l’application ».

Applies à : Windows 10 et versions ultérieures

Cause : Le serveur web transmet le fichier , .msix, ou .msixbundle avec un en-tête incorrect .appinstaller, ou en omettant l’en-tête Content-Type.

Correctif : Configurez votre serveur web pour traiter les fichiers LIÉS à MSIX avec les types MIME appropriés :

Extension de fichier Type MIME requis
.msix application/msix
.msixbundle application/msixbundle
.appinstaller application/appinstaller
.appx application/appx
.appxbundle application/appxbundle

Vérifiez également que chaque réponse inclut un en-tête valide Content-Length — cela s'applique à la fois aux requêtes GET et HEAD.

Pour IIS, ajoutez des mappages de types MIME dans web.config. Pour Azure Static Web Apps ou GitHub Pages, les types MIME pour ces extensions peuvent avoir besoin d’une configuration explicite ou d’une solution d’hébergement personnalisée.

Dépendances manquantes

Package framework non installé (VCLibs, .NET, SDK d'application Windows)

Symptom : l’application s’installe correctement, mais se bloque lors du lancement, ou l’installation échoue avec une erreur de dépendance référençant un nom de famille de package tel que Microsoft.VCLibs, Microsoft.WindowsAppRuntime ou Microsoft.NET.Native.

Applies à : Windows 10 et versions ultérieures, Windows 11

Cadres courants et où les obtenir

Cadre Nécessaire quand Origine
VCLibs (x64/x86/arm64) L’application utilise le runtime C++ Microsoft Store (installé automatiquement) ou direct download
.NET 8 Desktop Runtime L'application cible .NET 8 Inclus avec SDK d'application Windows ; ou direct download
SDK d'application Windows (WinAppSDK) L’application utilise WinUI 3 ou d’autres API WinAppSDK Versions du SDK d’application Windows sur GitHub

Correctif pour le développement : lors d’une installation locale via Add-AppxPackage, ajoutez le paramètre -DependencyPackages ou installez d’abord les packages d’infrastructure :

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

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

Correctif pour la distribution : si vous distribuez en dehors du Windows Store, incluez des packages d’infrastructure dans votre .appinstaller fichier sous <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>

Note

Lors de la distribution via le Microsoft Store, les dépendances d’infrastructure sont automatiquement téléchargées et installées. La gestion manuelle des dépendances est nécessaire uniquement pour le chargement latéral et les déploiements d’entreprise.

SignTool introuvable dans CI/CD

Symptom : le pipeline CI/CD (GitHub Actions, Azure DevOps) échoue avec une erreur telle que 'signtool' is not recognized as an internal or external command ou SignTool.exe: not found.

Applies à : Windows 10 et versions ultérieures, Windows 11 (machine de signature)

Cause : SignTool fait partie du Kit de développement logiciel (SDK) Windows et n’est pas inclus dans les images d’exécuteur CI standard par défaut.

Fixes:

Option 1 : installez Windows SDK dans le pipeline (GitHub Actions) :

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

Option 2 : utilisez l’interface CLI WinApp (la plus simple pour la signature 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 }}

Option 3 : Utilisez la signature d'artefacts Azure (recommandé pour la production) :

- 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

Note

L’action GitHub est nommée azure/trusted-signing-action (l’ancien nom du service). Il s'agit de l'action officielle, indépendamment du changement de nom en Artifact Signing.

Pour obtenir une procédure pas à pas complète de la configuration de la signature CI/CD, consultez Le guide de signature de votre package MSIX - de bout en bout.

Comportement du runtime et de la virtualisation

Les packages MSIX s’exécutent à l’intérieur d’un conteneur d’application léger. Certains comportements qui semblent être des bogues sont en fait par conception : le conteneur intercepte les opérations de fichier et de Registre pour protéger le reste du système.

Pourquoi les écritures de fichiers semblent disparaître (redirection de fichiers VFS)

Symptôme : l’application écrit un fichier dans un chemin d’accès tel qu’au C:\Program Files\MyApp\config.ini moment de l’exécution, mais le fichier n’y apparaît pas. L’application lit correctement la valeur, mais d’autres processus ou utilisateurs ne le voient pas.

Applies à : Windows 10 et versions ultérieures, Windows 11

Explication : MSIX utilise la redirection VFS (Virtual File System). Les écritures dans les chemins système protégés sont redirigées de manière transparente vers un conteneur propre à l’utilisateur :

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

C'est intentionnellement conçu pour empêcher les applications MSIX de modifier les emplacements du système partagé, afin de faciliter une désinstallation propre.

Options :

  • Utilisez plutôt des dossiers de données d’application : écrire dans ApplicationData.Current.LocalFolder (WinRT) ou %LocalAppData%\Packages\<PFN>\LocalState\ pour les données par utilisateur qui doivent être conservées.
  • Utiliser AppData\Roaming pour les données qui doivent se déplacer sur les appareils.
  • Inspectez le conteneur VFS pour afficher les fichiers redirigés : %LocalAppData%\Packages\<PackageFamilyName>\LocalCache\

Pour plus d’informations sur les chemins d’accès virtualisés, consultez Résoudre les problèmes d’exécution dans un conteneur MSIX.

Pourquoi les écritures de Registre semblent disparaître (virtualisation du Registre)

Symptôme : l’application écrit sur HKEY_LOCAL_MACHINE\Software\MyApp\ au moment de l’exécution, mais la valeur n’est pas visible pour d’autres processus et ne survit pas à une réinstallation.

Applies à : Windows 10 et versions ultérieures, Windows 11

Explication : MSIX intercepte les écritures HKLM\Software et les redirige vers une ruche de registre par package isolée du reste du système. Lors de la désinstallation, la ruche est supprimée.

Options :

  • Écrivez les paramètres par utilisateur dans HKEY_CURRENT_USER\Software\<AppName> : ceux-ci ne sont pas virtualisés et persistants.
  • Utilisez les API Windows ApplicationData pour le stockage de paramètres structurés.
  • Déclarez les entrées de Registre qui doivent être partagées entre les utilisateurs ou les processus dans AppxManifest.xml à l’aide du mécanisme <Extensions> / <com:Extension>.

Pour plus d’informations sur le comportement du conteneur MSIX, consultez Understand comment les applications de bureau empaquetées s’exécutent sur Windows.

Limitations de Windows 10 MSIX

Certaines fonctionnalités MSIX nécessitent Windows 11 ou une version Windows 10 spécifique. Si vous effectuez un déploiement sur des appareils Windows 10, tenez compte des éléments suivants.

Fonctionnalités qui nécessitent Windows 10, version 2004 (build 19041) ou ultérieure

Fonctionnalité Version minimale
Schéma de mise à jour automatique 2021 (ShowPrompt, UpdateBlocksActivation) Windows 10 2004 (19041)
Renforcement de l’intégrité du paquet (uap10:PackageIntegrity) Windows 10 2004 (19041)
Réparation automatique d’App Installer Windows 10 2004 (19041)
Il n’existe pas de paramètre distinct de stratégie de chargement indépendant pour l’installation de packages d’applications approuvés. Consultez Activer votre appareil pour le développement pour connaître les exigences actuelles. Windows 10 2004 (19041)

Fonctionnalités qui nécessitent Windows 11

Fonctionnalité Remarques
Identité de package partiel sans empaquetage complet Nécessite Windows 11
Prise en charge de MSIX pour les applications non empaquetées avec un emplacement externe (prise en charge complète de la plateforme) Certaines API ont été améliorées dans Windows 11
Amélioration des performances d’installation par ordinateur MSIX optimisations de Windows 11

Windows 10 appareils antérieurs à la version 1709

MSIX n’est pas pris en charge en mode natif sur Windows 10 versions antérieures à 1709 (Fall Creators Update). Pour déployer des packages MSIX sur ces appareils, utilisez MSIX Core, qui fournit une couche de compatibilité pour les versions de Windows 10 de bas niveau.

Extensions de manifeste

Certaines extensions d’espace de noms AppxManifest.xml sont Windows 11 uniquement. Les déclarer sur un package ciblant Windows 10 peut échouer à la validation du schéma lors de l’empaquetage, ou être rejeté lors de l’installation. Vérifiez la référence du schéma du manifeste du package d’application pour chaque MinOSVersion extension répertoriée.

Conseil de débogage

Pour vérifier les fonctionnalités MSIX disponibles sur une build de Windows 10 spécifique, consultez la page MSIX et plateformes prises en charge qui répertorie la disponibilité des fonctionnalités par version du système d’exploitation.

  • Dernière mise à jour :