L’erreur Add-AppxPackage 0x80073D02, également identifiée sous le nom ERROR_PACKAGES_IN_USE, signifie que Windows ne peut pas terminer un déploiement AppX/MSIX, car un processus en cours d’exécution utilise des ressources que l’opération sur le package doit modifier. Elle concerne les opérations d’installation, de mise à jour, de suppression et de réinscription sous Windows 10 et Windows 11. La première mesure, et la plus sûre, consiste à lire le message d’échec pour repérer l’application ou le package indiqué, à fermer toutes les instances visibles de cette application, puis à relancer la même opération.

Signification de l’erreur Add-AppxPackage 0x80073D02

Le message d’échec complet peut commencer par Deployment failed with HRESULT: 0x80073D02 ou indiquer que le package n’a pas pu être installé, car des ressources qu’il modifie sont en cours d’utilisation. Le libellé exact peut varier selon la langue et la version de Windows. Selon la documentation Microsoft sur la résolution des problèmes de déploiement AppX, ce code correspond précisément à une situation dans laquelle un package est en cours d’utilisation.

La ressource peut être occupée par une instance visible de l’application, une tâche ou un service en arrière-plan associé à celle-ci, ou encore un fichier ouvert dans les données de l’application, par exemple un fichier journal. Fermer une fenêtre visible peut donc suffire dans certains cas, mais pas dans tous.

Détail Ce qu’il permet d’établir
0x80073D02 Le déploiement a été refusé, car des ressources du package sont en cours d’utilisation.
Application ou package indiqué Le premier élément à examiner pour trouver le processus qui utilise la ressource.
ActivityID, s’il est renvoyé Une référence utilisable pour consulter le journal de déploiement associé.

Ce guide ne s’applique pas à un échec de déploiement portant un autre code ni à une erreur de Windows Update. Ces situations nécessitent un diagnostic distinct.

Identifier l’application ou le package à fermer

Quand utiliser cette procédure : appliquez-la lorsque le message d’erreur indique une application ou une famille de packages, ou précise qu’une ou plusieurs applications doivent être fermées.

Prérequis : conservez le message d’erreur d’origine afin de pouvoir comparer le nom de l’application ou du package avec les processus examinés.

  1. Lisez l’intégralité du message de déploiement, et pas uniquement la première ligne contenant le code HRESULT.
  2. Recherchez l’application ou la famille de packages signalée comme étant en cours d’utilisation. Le message peut indiquer explicitement les applications à fermer.
  3. Fermez toutes les fenêtres visibles appartenant à l’application indiquée.
  4. Ouvrez le Gestionnaire des tâches et recherchez une instance toujours active de cette même application.
  5. Si vous connaissez déjà le nom du processus correspondant, vous pouvez également utiliser Get-Process pour vérifier s’il est toujours actif.

Résultat attendu : vous identifiez un processus qui correspond clairement à l’application ou au package signalé par l’échec, ou vous confirmez qu’aucun processus correspondant évident n’est encore actif.

Risque et avertissement : cette vérification présente peu de risques, mais il n’existe pas de correspondance universelle documentée entre les noms de familles de packages et les noms de processus. Ne faites pas de déduction à partir d’un nom de package inconnu, ne terminez pas tous les processus portant un nom similaire et n’arrêtez pas un processus système sans rapport. Les libellés du Gestionnaire des tâches peuvent également varier légèrement selon la version de Windows.

Le guide Microsoft de résolution des problèmes MSIX recommande de rechercher les instances en cours d’exécution à l’aide du Gestionnaire des tâches ou de Get-Process.

Fermer l’élément bloquant confirmé et relancer l’opération sur le package

Quand utiliser cette correction : appliquez-la une fois que le message d’erreur ou l’examen des processus a permis d’identifier l’application qui utilise le package.

Prérequis : enregistrez votre travail dans l’application concernée et vérifiez que le processus à fermer lui appartient bien. Si cette relation reste incertaine, consultez les journaux de déploiement présentés dans la section suivante au lieu de terminer le processus.

  1. Fermez toutes les fenêtres visibles de l’application indiquée.
  2. Recherchez une instance restante dans le Gestionnaire des tâches ou avec Get-Process.
  3. Arrêtez uniquement le processus correspondant s’il peut être fermé sans danger.
  4. Vérifiez que l’application n’est plus en cours d’exécution.
  5. Relancez exactement la même opération Add-AppxPackage, d’installation, de mise à jour, de suppression ou de réinscription que celle qui avait échoué. Ne la remplacez pas par une commande générale de réparation des packages.
  6. Si le code 0x80073D02 réapparaît, recherchez un autre élément bloquant dans le message et les journaux.

Résultat attendu : Windows peut poursuivre l’opération lorsqu’aucun processus n’utilise les ressources nécessaires au package. Une nouvelle tentative peut toutefois révéler un autre élément bloquant ; la réussite n’est donc pas garantie.

Risque et retour à l’état initial : fermer un processus peut entraîner la perte du travail non enregistré dans l’application. Rouvrez celle-ci une fois le déploiement terminé ou après avoir interrompu le dépannage. La documentation officielle d’Add-AppxPackage décrit la commande de déploiement ; réutilisez l’opération adaptée à votre tâche d’origine sans ajouter de paramètres non documentés.

Consulter les journaux de déploiement AppX si l’élément bloquant n’est pas clair

Les journaux sont utiles lorsque le message d’erreur est incomplet, que l’application visible est déjà fermée ou que l’échec se reproduit après la suppression de l’élément bloquant évident. Leur lecture sert au diagnostic et ne répare pas le déploiement à elle seule.

Examiner le journal AppxDeployment-Server dans l’Observateur d’événements

Quand utiliser cette procédure : utilisez l’Observateur d’événements lorsque vous avez besoin de plus de détails sur la raison pour laquelle Windows a refusé le déploiement.

Prérequis : vous devez pouvoir ouvrir l’Observateur d’événements. Aucune exigence relative aux droits d’administrateur n’est indiquée ici, car elle peut varier selon l’environnement examiné.

  1. Ouvrez l’Observateur d’événements.
  2. Accédez à Journaux des applications et des services > Microsoft > Windows > AppxDeployment-Server > Opérationnel.
  3. Examinez les détails du refus de déploiement associés à l’opération ayant échoué.
  4. Identifiez l’application, le package, le processus, la tâche en arrière-plan, le service ou la ressource ouverte concernée, sans déduire un processus à partir d’un nom de package incertain.
  5. Fermez uniquement l’élément bloquant confirmé, puis relancez l’opération d’origine sur le package.

Résultat attendu : le journal fournit des informations de déploiement plus précises permettant de distinguer l’élément bloquant des processus en cours d’exécution sans rapport.

Risque et retour à l’état initial : la lecture du journal ne modifie pas le système ; aucun retour à l’état initial n’est donc nécessaire. N’effacez pas et ne modifiez pas les journaux dans le cadre de cette procédure.

Utiliser Get-AppxLog pour le déploiement ayant échoué

Quand utiliser cette procédure : utilisez Get-AppxLog après un échec d’Add-AppxPackage ou de Remove-AppxPackage, en particulier si le message a renvoyé un ActivityID.

Prérequis : un accès à PowerShell et, s’il est disponible, l’ActivityID figurant dans le message d’échec.

  1. Utilisez Get-AppxLog pour le déploiement le plus récent ou pour l’ActivityID disponible.
  2. Lisez les erreurs et les avertissements consignés.
  3. Utilisez ces informations pour identifier le package ou le processus qui utilise les ressources requises.
  4. Fermez uniquement l’élément bloquant confirmé.
  5. Relancez la même opération et consultez de nouveau le journal si l’erreur réapparaît.

Résultat attendu : le journal de déploiement fournit des éléments sur l’opération ayant échoué et peut révéler un blocage qui n’était pas évident dans le message d’origine.

Risque et retour à l’état initial : il s’agit d’une étape de diagnostic en lecture seule qui ne nécessite aucun retour à l’état initial. La présence d’un nom de processus similaire ne constitue pas à elle seule une preuve suffisante pour le terminer.

Gérer un composant de l’interface Windows qui redémarre automatiquement

Quand utiliser cette solution de repli : utilisez-la uniquement lorsque l’élément bloquant confirmé est un composant de l’interface Windows ou un composant en arrière-plan qui se relance automatiquement et ne reste pas fermé assez longtemps pour terminer l’opération sur le package.

Prérequis : enregistrez votre travail dans toutes les applications ouvertes et vérifiez, à partir du message d’erreur ou des journaux de déploiement, que le composant qui se relance est bien à l’origine du blocage.

  1. Déconnectez-vous de Windows, puis reconnectez-vous, ou redémarrez Windows.
  2. Après vous être reconnecté, relancez l’opération de déploiement d’origine.
  3. Si le même composant réapparaît et que l’opération renvoie encore 0x80073D02, consultez de nouveau le journal AppxDeployment-Server ou Get-AppxLog.

Résultat attendu : une déconnexion ou un redémarrage peut mettre fin aux instances exécutées pendant la session précédente et offrir une nouvelle possibilité d’effectuer le déploiement. Un composant de l’interface peut toutefois se relancer ; cette solution de repli ne résout donc pas tous les cas.

Risque et retour à l’état initial : une déconnexion ou un redémarrage ferme les applications et peut entraîner la perte du travail non enregistré. Enregistrez d’abord votre travail, puis rouvrez vos applications après vous être reconnecté. Ne terminez pas de manière répétée les processus de l’interface Windows.

Corrections non prises en charge pour 0x80073D02

Les recommandations de Microsoft propres à cette erreur consistent à fermer le processus qui utilise le package et à examiner les journaux de déploiement. Les sources fournies ne permettent pas de considérer les actions suivantes comme des corrections de ERROR_PACKAGES_IN_USE :

  • Réinitialiser par défaut le cache du Microsoft Store.
  • Réinscrire en bloc tous les packages AppX ou les packages de tous les utilisateurs.
  • Assouplir la stratégie d’exécution PowerShell.
  • Modifier le Registre.
  • Réinitialiser ou restaurer Windows.
  • Terminer des processus sans rapport au seul motif que leur nom ressemble à celui d’une famille de packages.

Ces actions générales ne corrigent pas le problème confirmé, à savoir qu’une ressource requise par le package est en cours d’utilisation, et peuvent provoquer des problèmes supplémentaires. Si l’échec concerne plutôt un refus d’accès dans Windows Update, consultez un guide distinct consacré à l’erreur Windows Update 0x80070005 ; elle n’est pas équivalente à cette erreur AppX/MSIX.