MSIX-Handbuch zur Problembehandlung

In diesem Handbuch werden die häufigsten MSIX-Fehler bei der Installation, Signatur, Übermittlung des App-Installers, fehlende Abhängigkeiten und Laufzeitverhalten behandelt. Jeder Abschnitt enthält das Symptom, die Ursache und die Auflösung.

Für ein vollständiges Protokoll der Bereitstellungsereignisse öffnen Sie Ereignisanzeige, und navigieren Sie zu: Applications and Services Logs → Microsoft → Windows → AppxDeployment-Server → Operational

Installationsfehler

0x80070005 – Zugriff verweigert

Symptom: Add-AppxPackage oder Der App-Installer schlägt mit Fehlercode 0x80070005fehl.

Gilt für: Windows 10 und höher, Windows 11

Ursachen und Korrekturen:

Paketinstallation blockiert, da die App verwendet wird

Symptom: Update oder erneute Installation schlägt mit einem Fehler fehl, der angibt, dass das Paket verwendet wird. In Ereignisanzeige sehen Sie, dass der Bereitstellungsvorgang abgelehnt wurde.

Gilt für: Windows 10 und höher, Windows 11

Fix: Schließen Sie alle laufenden Instanzen der App, bevor Sie aktualisieren. Wenn es sich bei der App um einen Hintergrunddienst handelt oder eine Hintergrundaufgabe registriert ist, müssen Sie diese möglicherweise auch beenden:

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

Berücksichtigen Sie bei Unternehmensbereitstellungen die Planung von Updates während der Wartungsfenster mithilfe von Intune oder Konfigurations-Manager.

MinVersion oder Architekturkonflikt

Symptom: Die Installation schlägt mit einem Fehler wie "Das Paket konnte nicht installiert werden, da es nicht mit dieser Version von Windows kompatibel ist" oder "Das Paket gilt nicht für diesen Computer."

Gilt für: Windows 10 und höher

Ursachen und Korrekturen:

Add-AppxPackage erfolgreich ist, die App fehlt jedoch im Startmenü.

Symptom: PowerShell meldet Erfolg, aber die App wird nicht in der Startmenü- oder App-Liste angezeigt.

Gilt für: Windows 10 und höher, Windows 11

Häufige Ursachen:

• Installation pro Benutzer und Computer: Add-AppxPackage Wird nur für den aktuellen Benutzer installiert. Wenn Sie als Administrator angemeldet sind, die App jedoch für einen anderen Benutzer vorgesehen ist, verwenden Sie stattdessen.
• Paket registriert, aber Kachel nicht angeheftet: Die App ist installiert, aber das Startmenü wurde nicht aktualisiert. Melden Sie sich ab und wieder an, oder überprüfen Sie die Einstellungen → Apps , um die Installation zu bestätigen.
• Fehlender Startmenüeintrag im Manifest: Überprüfen Sie, ob das <Application> Element AppxManifest.xml einen VisualElements Eintrag mit einem gültigen Square150x150LogoEintrag enthält.
• Konflikt mit doppelten Paketfamiliennamen: Wenn bereits eine neuere oder ältere Version der App mit demselben Paketfamiliennamen installiert ist, kann die neue Installation sie automatisch ersetzen. Überprüfen mit Get-AppxPackage -Name "YourPackageFamilyName".

Signatur- und Zertifikatfehler

Zertifikat nicht vertrauenswürdig (0x800B0109)

Symptom: Installation schlägt fehl mit dem Fehler 0x800B0109 — "Eine Zertifikatskette wurde verarbeitet, aber endete in einem Stammzertifikat, das vom Vertrauensanbieter nicht vertrauenswürdig ist."

Gilt für: Windows 10 und höher, Windows 11

Ursache: Das zum Signieren des Pakets verwendete Zertifikat befindet sich nicht in den vertrauenswürdigen Zertifikatspeichern des Geräts. Dies ist üblich, wenn sie selbstsignierte Zertifikate für die Entwicklung verwenden.

Behebung: Importieren Sie das Signaturzertifikat in den lokalen Computer des Geräts → Speicher für vertrauenswürdige Personen (nicht den aktuellen Benutzerspeicher – Der App-Installer überprüft nur den Computerspeicher):

# 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

Verwenden Sie für Produktions-Apps ein Zertifikat, das von einer vertrauenswürdigen Zertifizierungsstelle oder Azure Artifact Signing (früher Vertrauenswürdige Signatur) ausgestellt wurde, die mit der Microsoft Identitätsüberprüfungs-Stammzertifizierungsstelle verkettet ist – standardmäßig auf Windows 10 Version 1809 und höher, Windows 11.

Publisher Namenskonflikt (0x8007000B, Ereignis-ID 150)

Symptom: SignTool schlägt mit 0x8007000B fehl, und Ereignisanzeige (AppxPackagingOM-Betriebsprotokoll) zeigt 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).

Gilt für: Windows 10 und höher, Windows 11

Cause: Das attribut Publisher in AppxManifest.xml muss exakt mit dem namen subject name des Signaturzertifikats übereinstimmen, einschließlich aller distinguished name fields in derselben Reihenfolge.

Korrektur:

1. Rufen Sie den genauen Betreffnamen aus dem Zertifikat ab.

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

2. Aktualisieren Sie AppxManifest.xml, um genau übereinzustimmen.

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

3. Erneut mit MakeAppx.exe verpacken und signieren.

Fehler des App-Installers und der Webübermittlung

Schemaversionskonflikt in appinstaller-Datei

Symptom: Das App-Installationsprogramm analysiert oder verarbeitet die .appinstaller Datei nicht, häufig mit einem generischen Fehler bei einer ungültigen Datei oder einem nicht unterstützten Schema.

Gilt für: Windows 10 und höher (versionsabhängig — siehe Tabelle)

Cause: Das attribut Uri des stammelements <AppInstaller> gibt eine Schemaversion an, die von der installierten Version von Windows nicht unterstützt wird.

Schema-Versionen nach Windows Release:

Fix: Legen Sie den Schema-URI in Ihrer .appinstaller Datei auf die Mindestversion fest, für die das unterste unterstützte Betriebssystem erforderlich ist:

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

Vermeiden Sie die Verwendung der neuesten Schemaversion, wenn Sie ältere Windows 10 Versionen unterstützen müssen.

Dateien, die mit falschem MIME-Typ oder fehlender Inhaltslänge bereitgestellt werden

Symptom: Der App-Installer schlägt beim Installieren von einem HTTP/HTTPS-Endpunkt fehl. Der Fehler kann generisch sein, z 0x80072F76 . B. ("Unbekannter Fehler") oder "Fehler bei der App-Installation".

Gilt für: Windows 10 und höher

Ursache: Der Webserver liefert die .msix, .msixbundle oder .appinstaller Datei mit einer falschen Content-Type-Kopfzeile oder lässt die Content-Length-Kopfzeile weg.

Fix: Konfigurieren Sie Ihren Webserver so, dass MSIX-bezogene Dateien mit den richtigen MIME-Typen bedient werden:

Stellen Sie außerdem sicher, dass jede Antwort einen gültigen Content-Length Header enthält – dies gilt sowohl für GET als auch für HEAD Anforderungen.

Fügen Sie für IIS MIME-Typzuordnungen in web.config hinzu. Für Azure Static Web Apps oder GitHub Seiten benötigen MIME-Typen für diese Erweiterungen möglicherweise eine explizite Konfiguration oder eine benutzerdefinierte Hostinglösung.

Fehlende Abhängigkeiten

Framework-Paket nicht installiert (VCLibs, .NET, Windows App SDK)

Symptom: Die App wird erfolgreich installiert, aber beim Start abstürzt, oder die Installation schlägt mit einem Abhängigkeitsfehler fehl, der auf einen Paketfamiliennamen wie Microsoft.VCLibs, Microsoft.WindowsAppRuntime oder Microsoft.NET.Native verweist.

Gilt für: Windows 10 und höher, Windows 11

Allgemeine Frameworks und wo sie abgerufen werden:

Fix für die Entwicklung: Fügen Sie bei lokaler Installation den -DependencyPackages Parameter hinzu, oder installieren Sie zuerst die -DependencyPackages Framework-Pakete:

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

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

Fix für verteilung: Wenn Sie außerhalb des Store verteilen, schließen Sie Frameworkpakete in Ihre .appinstaller Datei ein unter <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 in CI/CD nicht gefunden

Symptom: CI/CD-Pipeline (GitHub Actions, Azure DevOps) schlägt mit einem Fehler wie 'signtool' is not recognized as an internal or external command oder SignTool.exe: not found fehl.

Gilt für: Windows 10 und höher, Windows 11 (Signaturcomputer)

Cause: SignTool ist Teil des Windows SDK und ist standardmäßig nicht in standardmäßigen CI-Läuferbildern enthalten.

Fixes:

Option 1 – Installieren Sie Windows SDK in der Pipeline (GitHub Actions):

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

Option 2 – Verwenden Sie die WinApp CLI (am einfachsten für die MSIX-Signatur):

- 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 – Verwenden Sie Azure Artefaktsignierung (empfohlen für die Produktion):

- 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

Eine vollständige Anleitung zur CI/CD-Signiereinrichtung finden Sie unter Signieren Ihres MSIX-Pakets – End-to-End-Handbuch.

Laufzeit- und Virtualisierungsverhalten

MSIX-Pakete werden in einem einfachen App-Container ausgeführt. Einige Verhaltensweisen, die scheinbar Fehler sind, sind eigentlich beabsichtigt – der Container fängt Datei- und Registrierungsvorgänge ab, um den Rest des Systems zu schützen.

Warum Dateischreibvorgänge scheinbar verschwinden (VFS-Dateiumleitung)

Symptom: Die App schreibt eine Datei in einen Pfad wie C:\Program Files\MyApp\config.ini zur Laufzeit, aber die Datei wird dort nicht angezeigt. Die App liest den Wert richtig zurück, aber andere Prozesse oder Benutzer sehen ihn nicht.

Gilt für: Windows 10 und höher, Windows 11

Erläuterung: MSIX verwendet die VFS-Umleitung (Virtual File System ). Schreibvorgänge in geschützte Systempfade werden stillschweigend an einen benutzerspezifischen Container umgeleitet.

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

Dies ist beabsichtigt – es verhindert, dass MSIX-Apps gemeinsam genutzte Systemspeicherorte ändern und eine saubere Deinstallation unterstützen.

Optionen:

• Verwenden Sie stattdessen App-Datenordner: Schreiben in ApplicationData.Current.LocalFolder (WinRT) oder %LocalAppData%\Packages\<PFN>\LocalState\ für Benutzerdaten, die beibehalten werden sollen.
• Verwenden AppData\Roaming für Daten, die geräteübergreifend übertragen werden sollen.
• Überprüfen Sie den VFS-Container , um umgeleitete Dateien anzuzeigen: %LocalAppData%\Packages\<PackageFamilyName>\LocalCache\

Weitere Informationen dazu, welche Pfade virtualisiert werden, finden Sie unter "Behandeln von Laufzeitproblemen in einem MSIX-Container".

Warum Registrierungsschreibvorgänge scheinbar verschwinden (Registrierungsvirtualisierung)

Symptom: Die App schreibt zur Laufzeit in HKEY_LOCAL_MACHINE\Software\MyApp\, aber der Wert ist für andere Prozesse nicht sichtbar und übersteht eine Neuinstallation nicht.

Gilt für: Windows 10 und höher, Windows 11

Erläuterung: MSIX fängt Schreibvorgänge an HKLM\Software ab und leitet sie an einen pro Paket erstellten Registry-Hive um, der vom Rest des Systems isoliert ist. Bei der Deinstallation wird das Hive gelöscht.

Optionen:

• Schreiben Sie einstellungen pro Benutzer in HKEY_CURRENT_USER\Software\<AppName> – diese werden nicht virtualisiert und beibehalten.
• Verwenden Sie die Windows ApplicationData-APIs für den Speicher strukturierter Einstellungen.
• Deklarieren Sie Registrierungseinträge, die über Benutzer oder Prozesse hinweg freigegeben werden müssen, indem Sie den AppxManifest.xml<Extensions> / <com:Extension> Mechanismus verwenden.

Einen vertieften Einblick in das Verhalten von MSIX-Containern finden Sie unter Verstehen, wie verpackte Desktop-Apps unter Windows laufen.

Windows 10 MSIX-Einschränkungen

Einige MSIX-Features erfordern Windows 11 oder eine bestimmte Windows 10 Version. Wenn Sie auf Windows 10 Geräten bereitstellen, beachten Sie Folgendes.

Features, die Windows 10, Version 2004 (Build 19041) oder höher erfordern

Features, die Windows 11 erfordern

Windows 10 Geräte, die älter als Version 1709 sind

MSIX wird in Windows 10 Versionen vor 1709 (Fall Creators Update) nicht nativ unterstützt. Verwenden Sie zum Bereitstellen von MSIX-Paketen auf diesen Geräten MSIX Core, die eine Kompatibilitätsebene für Windows 10 Versionen auf down-level-Ebene bereitstellt.

Manifesterweiterungen

Einige AppxManifest.xml Namespaceerweiterungen sind nur für Windows 11. Wenn Sie sie in einem Paket deklarieren, das auf Windows 10 abzielt, kann die Schemaüberprüfung während des Verpackens fehlschlagen oder es kann während der Installation abgelehnt werden. Überprüfen Sie die Schemareferenz für das App-Paketmanifest für die MinOSVersion aufgeführten Erweiterungen.

Debugtipp

Um zu überprüfen, welche MSIX-Features in einem bestimmten Windows 10 Build verfügbar sind, überprüfen Sie die features MSIX-Features und unterstützte Plattformen Seite, auf der die Featureverfügbarkeit nach Betriebssystemversion aufgeführt wird.

Verwandte Ressourcen

• Signieren einer MSIX-Paketübersicht
• Signieren Ihres MSIX-Pakets – End-to-End-Leitfaden
• Bekannte Probleme und Problembehandlung für SignTool
• Behandeln von Problemen mit dem App-Installationsprogramm
• Behandeln von Laufzeitproblemen in einem MSIX-Container
• Fehlerbehebung bei der Verpackung, Bereitstellung und Abfrage von Windows-Apps