Der Add-AppxPackage-Fehler 0x80073D02, auch als ERROR_PACKAGES_IN_USE bezeichnet, bedeutet, dass Windows eine AppX-/MSIX-Bereitstellung nicht abschließen kann, weil ein laufender Prozess Ressourcen verwendet, die der Paketvorgang ändern muss. Der Fehler kann bei Installationen, Aktualisierungen, Entfernungen und erneuten Registrierungen unter Windows 10 und Windows 11 auftreten. Am sichersten ist es, zuerst in der Fehlerausgabe nach der genannten App oder dem genannten Paket zu suchen, alle sichtbaren Instanzen dieser App zu schließen und denselben Vorgang erneut auszuführen.

Was der Add-AppxPackage-Fehler 0x80073D02 bedeutet

Die vollständige Fehlermeldung kann mit Deployment failed with HRESULT: 0x80073D02 beginnen oder darauf hinweisen, dass das Paket nicht installiert werden konnte, weil die zu ändernden Ressourcen derzeit verwendet werden. Der genaue Wortlaut kann je nach Windows-Version und Sprache variieren. Laut der Microsoft-Referenz zur Problembehandlung bei AppX-Bereitstellungen steht der Code ausdrücklich dafür, dass ein Paket verwendet wird.

Die Ressource kann von einer sichtbaren App-Instanz, einer mit der App verknüpften Hintergrundaufgabe oder einem Dienst oder von einer geöffneten Datei in den App-Daten, beispielsweise einer Protokolldatei, belegt sein. Deshalb genügt es in manchen Fällen, ein sichtbares Fenster zu schließen, aber nicht in allen.

Detail Bedeutung
0x80073D02 Die Bereitstellung wurde abgelehnt, weil Paketressourcen verwendet werden.
Genannte App oder genanntes Paket Der erste Ansatzpunkt bei der Suche nach dem Prozess, der die Ressource belegt.
ActivityID, falls ausgegeben Eine Referenz, die zur Prüfung des zugehörigen Bereitstellungsprotokolls verwendet werden kann.

Diese Anleitung gilt nicht für Bereitstellungsfehler mit einem anderen Code oder für einen Windows Update-Fehler. Solche Fehler müssen getrennt diagnostiziert werden.

Zu schließende App oder zu schließendes Paket ermitteln

Wann dies zutrifft: Verwenden Sie dieses Verfahren, wenn in der Fehlerausgabe eine App oder Paketfamilie genannt wird oder wenn die Meldung besagt, dass eine oder mehrere Apps geschlossen werden müssen.

Voraussetzung: Halten Sie die ursprüngliche Fehlerausgabe bereit, damit Sie den dort genannten App- oder Paketnamen mit den überprüften Prozessen vergleichen können.

  1. Lesen Sie die vollständige Bereitstellungsausgabe und nicht nur die erste HRESULT-Zeile.
  2. Suchen Sie nach der App oder Paketfamilie, die als verwendet gemeldet wird. In der Ausgabe können die zu schließenden Apps ausdrücklich genannt sein.
  3. Schließen Sie alle sichtbaren Fenster der genannten App.
  4. Öffnen Sie den Task-Manager und suchen Sie nach einer weiterhin laufenden Instanz derselben App.
  5. Wenn Sie den zugehörigen Prozessnamen bereits kennen, können Sie außerdem mit Get-Process prüfen, ob der Prozess noch aktiv ist.

Erwartetes Ergebnis: Sie ermitteln einen Prozess, der eindeutig der in der Fehlermeldung genannten App oder dem Paket entspricht, oder bestätigen, dass kein offensichtlich passender Prozess mehr ausgeführt wird.

Risiko und Warnung: Die Überprüfung ist mit einem geringen Risiko verbunden. Für die Zuordnung von Paketfamiliennamen zu Prozessnamen gibt es jedoch keine allgemeingültige dokumentierte Regel. Raten Sie nicht anhand eines unbekannten Paketnamens, beenden Sie nicht alle ähnlich benannten Prozesse und beenden Sie keinen nicht zugehörigen Systemprozess. Die Bezeichnungen im Task-Manager können je nach Windows-Build leicht abweichen.

Das MSIX-Handbuch zur Problembehandlung von Microsoft empfiehlt, mit dem Task-Manager oder Get-Process nach laufenden Instanzen zu suchen.

Bestätigten Blockierer schließen und Paketvorgang wiederholen

Wann dies zutrifft: Verwenden Sie diese Lösung, nachdem anhand der Ausgabe oder der Prozessprüfung die App ermittelt wurde, die das Paket verwendet.

Voraussetzungen: Speichern Sie Ihre Arbeit in der betroffenen App und bestätigen Sie, dass der zu schließende Prozess zu der genannten App gehört. Wenn die Zuordnung unklar ist, verwenden Sie die Bereitstellungsprotokolle im nächsten Abschnitt, statt den Prozess zu beenden.

  1. Schließen Sie alle sichtbaren Fenster der genannten App.
  2. Prüfen Sie im Task-Manager oder mit Get-Process, ob noch eine Instanz ausgeführt wird.
  3. Beenden Sie ausschließlich den passenden Prozess, sofern dies gefahrlos möglich ist.
  4. Vergewissern Sie sich, dass die App nicht mehr ausgeführt wird.
  5. Wiederholen Sie denselben Add-AppxPackage-, Installations-, Aktualisierungs-, Entfernungs- oder Registrierungsauftrag, der ursprünglich fehlgeschlagen ist. Ersetzen Sie ihn nicht durch einen allgemeinen Befehl zur Paketreparatur.
  6. Wenn 0x80073D02 erneut auftritt, prüfen Sie die Ausgabe und die Protokolle auf einen weiteren Blockierer.

Erwartetes Ergebnis: Windows kann fortfahren, sobald kein Prozess mehr die für den Paketvorgang benötigten Ressourcen belegt. Bei einem erneuten Versuch kann jedoch ein weiterer Blockierer sichtbar werden, weshalb der Erfolg nicht garantiert ist.

Risiko und Rückgängigmachen: Beim Beenden eines Prozesses können nicht gespeicherte Änderungen in der App verloren gehen. Öffnen Sie die App nach Abschluss der Bereitstellung oder nach dem Ende der Problembehandlung erneut. Die offizielle Referenz zu Add-AppxPackage dokumentiert den Bereitstellungsbefehl. Verwenden Sie erneut den für Ihre ursprüngliche Aufgabe vorgesehenen Vorgang, ohne nicht dokumentierte Parameter hinzuzufügen.

AppX-Bereitstellungsprotokolle prüfen, wenn der Blockierer unklar ist

Protokolle sind hilfreich, wenn die Fehlermeldung unvollständig ist, die sichtbare App bereits geschlossen wurde oder der Fehler nach dem Entfernen des offensichtlichen Blockierers erneut auftritt. Das Lesen dieser Protokolle dient nur der Diagnose und repariert die Bereitstellung nicht selbst.

AppxDeployment-Server-Protokoll in der Ereignisanzeige prüfen

Wann dies zutrifft: Verwenden Sie die Ereignisanzeige, wenn Sie weitere Informationen dazu benötigen, warum Windows die Bereitstellung abgelehnt hat.

Voraussetzung: Sie müssen die Ereignisanzeige öffnen können. Hier wird keine Administratorberechtigung vorausgesetzt, da dies von der jeweiligen Umgebung abhängen kann.

  1. Öffnen Sie die Ereignisanzeige.
  2. Wechseln Sie zu Anwendungs- und Dienstprotokolle > Microsoft > Windows > AppxDeployment-Server > Betriebsbereit.
  3. Prüfen Sie die Details zur Ablehnung der Bereitstellung, die mit dem fehlgeschlagenen Vorgang zusammenhängen.
  4. Ermitteln Sie die relevante App, das Paket, den Prozess, die Hintergrundaufgabe, den Dienst oder die geöffnete Ressource, ohne aus einem nicht eindeutig zugeordneten Paketnamen auf einen Prozess zu schließen.
  5. Schließen Sie ausschließlich den bestätigten Blockierer und wiederholen Sie anschließend den ursprünglichen Paketvorgang.

Erwartetes Ergebnis: Das Protokoll liefert genauere Informationen zur Bereitstellung, mit denen sich der relevante Blockierer von nicht zugehörigen laufenden Prozessen unterscheiden lässt.

Risiko und Rückgängigmachen: Das Lesen des Protokolls verändert das System nicht. Ein Rückgängigmachen ist daher nicht erforderlich. Löschen oder verändern Sie die Protokolle bei diesem Verfahren nicht.

Get-AppxLog für die fehlgeschlagene Bereitstellung verwenden

Wann dies zutrifft: Verwenden Sie Get-AppxLog nach einem fehlgeschlagenen Add-AppxPackage- oder Remove-AppxPackage-Vorgang, insbesondere wenn in der Ausgabe eine ActivityID zurückgegeben wurde.

Voraussetzungen: Zugriff auf PowerShell und, sofern vorhanden, die ActivityID aus der Fehlerausgabe.

  1. Verwenden Sie Get-AppxLog für die letzte Bereitstellung oder für die verfügbare ActivityID.
  2. Lesen Sie die protokollierten Fehler und Warnungen.
  3. Ermitteln Sie anhand dieser Angaben das Paket oder den Prozess, das beziehungsweise der die benötigten Ressourcen belegt.
  4. Schließen Sie ausschließlich den bestätigten Blockierer.
  5. Wiederholen Sie denselben Vorgang und prüfen Sie das Protokoll erneut, falls der Fehler wiederkehrt.

Erwartetes Ergebnis: Das Bereitstellungsprotokoll liefert Nachweise zum fehlgeschlagenen Paketvorgang und kann einen Blockierer offenlegen, der in der ursprünglichen Ausgabe nicht offensichtlich war.

Risiko und Rückgängigmachen: Dieser Diagnoseschritt ist schreibgeschützt und muss nicht rückgängig gemacht werden. Betrachten Sie einen ähnlich klingenden Prozessnamen nicht als ausreichenden Beleg dafür, dass der Prozess beendet werden darf.

Automatisch neu gestartete Windows-Shell-Komponente behandeln

Wann dies zutrifft: Verwenden Sie diese Ausweichlösung nur, wenn als bestätigter Blockierer eine Windows-Shell- oder Hintergrundkomponente ermittelt wurde, die automatisch neu startet und nicht lange genug geschlossen bleibt, um den Paketvorgang abzuschließen.

Voraussetzungen: Speichern Sie Ihre Arbeit in allen geöffneten Anwendungen und bestätigen Sie anhand der Fehlermeldung oder der Bereitstellungsprotokolle, dass die neu gestartete Komponente tatsächlich der Blockierer ist.

  1. Melden Sie sich von Windows ab und anschließend wieder an oder starten Sie Windows neu.
  2. Wiederholen Sie nach der Anmeldung den ursprünglichen Bereitstellungsvorgang.
  3. Wenn dieselbe Komponente erneut ausgeführt wird und der Vorgang wieder 0x80073D02 meldet, prüfen Sie das AppxDeployment-Server-Protokoll oder Get-AppxLog erneut.

Erwartetes Ergebnis: Durch das Abmelden oder den Neustart können laufende Instanzen der vorherigen Sitzung beendet werden. Dadurch entsteht eine weitere Gelegenheit, die Bereitstellung auszuführen. Eine Shell-Komponente kann jedoch erneut gestartet werden, sodass diese Ausweichlösung nicht jeden Fall behebt.

Risiko und Rückgängigmachen: Beim Abmelden oder Neustarten werden Anwendungen geschlossen, wodurch nicht gespeicherte Arbeit verloren gehen kann. Speichern Sie zuerst und öffnen Sie Ihre Anwendungen nach der erneuten Anmeldung wieder. Beenden Sie Shell-Prozesse nicht wiederholt.

Nicht unterstützte Lösungen für 0x80073D02

Die fehlerspezifischen Hinweise von Microsoft konzentrieren sich darauf, den Prozess zu schließen, der das Paket verwendet, und die Bereitstellungsprotokolle zu untersuchen. Die vorliegenden Nachweise stützen die folgenden Maßnahmen nicht als Lösungen für ERROR_PACKAGES_IN_USE:

  • Den Microsoft Store-Cache standardmäßig zurücksetzen.
  • Alle AppX-Pakete oder die Pakete aller Benutzer gesammelt erneut registrieren.
  • Die PowerShell-Ausführungsrichtlinie lockern.
  • Die Registrierung bearbeiten.
  • Windows zurücksetzen oder wiederherstellen.
  • Nicht zugehörige Prozesse beenden, nur weil ihre Namen einer Paketfamilie ähneln.

Diese weitreichenden Maßnahmen beheben nicht den bestätigten Zustand, dass eine benötigte Paketressource verwendet wird, und können zusätzliche Probleme verursachen. Ein Fehler mit verweigertem Zugriff bei Windows Update ist nicht mit diesem AppX-/MSIX-Fehler gleichzusetzen und muss separat diagnostiziert werden.

Häufig gestellte Fragen

Was bedeutet der Fehler 0x80073D02 bei Add-AppxPackage?

Der Code 0x80073D02 beziehungsweise ERROR_PACKAGES_IN_USE bedeutet, dass ein laufender Prozess Ressourcen verwendet, die Windows für den AppX-/MSIX-Paketvorgang ändern muss.

Reicht es aus, das sichtbare App-Fenster zu schließen?

Manchmal. Die Ressource kann jedoch auch von einer Hintergrundaufgabe, einem Dienst oder einer geöffneten Datei belegt sein. Prüfen Sie deshalb den Task-Manager oder die Bereitstellungsprotokolle, wenn der Fehler erneut auftritt.

Sollte ich alle ähnlich benannten Prozesse beenden?

Nein. Beenden Sie nur einen Prozess, der eindeutig der in der Fehlermeldung oder im Bereitstellungsprotokoll genannten App zugeordnet werden kann. Ein ähnlicher Name ist kein ausreichender Nachweis.

Behebt Get-AppxLog den Fehler?

Nein. Get-AppxLog ist ein schreibgeschützter Diagnoseschritt. Das Protokoll kann dabei helfen, das betroffene Paket oder den blockierenden Prozess zu ermitteln.