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

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 :

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

Symptôme : La mise à jour ou la réinstallation échoue avec une erreur indiquant que le package est en cours d’utilisation. Dans observateur d'événements, vous voyez que l’opération de déploiement a été rejetée.

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

Correctif : fermez toutes les instances en cours d’exécution de l’application avant la mise à jour. Si l’application est un service en arrière-plan ou qu’une tâche en arrière-plan est inscrite, vous devrez peut-être également les arrêter :

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

Pour les déploiements d’entreprise, envisagez de planifier des mises à jour pendant les fenêtres de maintenance à l’aide d’Intune ou de Configuration Manager.

Incompatibilité de minVersion ou d’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 :

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

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

Pour les applications de production, utilisez un certificat émis par une autorité de certification approuvée ou Signature des artefacts Azure (anciennement Signature approuvée), qui fait partie de la chaîne de certification de l'autorité racine de vérification d'identité de Microsoft, approuvée par défaut sur Windows 10 version 1809 et ultérieure et 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 de l’objet à 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. Re-empaqueter et MakeAppx.exe réinscrire.

Erreurs du programme d'installation d'application et de la livraison 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 :

Correction : Définissez l'URI du schéma de votre fichier .appinstaller sur la version minimale requise par votre système d'exploitation le plus bas 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, .msixbundle, ou .appinstaller avec un en-tête incorrect Content-Type, ou en omettant l’en-tête Content-Length.

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

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

Correctif pour le développement : lors de l’installation localement via Add-AppxPackage, ajoutez le paramètre -DependencyPackages d’abord ou installez d'abord les packages du framework :

# 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>

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

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 en mode silencieux vers un conteneur par 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 <Extensions> / <com:Extension> mécanisme.

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és qui nécessitent 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.

Ressources associées

• Vue d’ensemble d’un package MSIX
• Signer votre paquet MSIX - Guide de bout en bout
• Problèmes connus et résolution des problèmes pour SignTool
• Résoudre les problèmes liés au programme d’installation d’applications
• Résoudre les problèmes d’exécution dans un conteneur MSIX
• Dépannage de l'emballage, du déploiement et de l'interrogation des applications Windows