WinGet-Fehler beheben wird einfacher, wenn du zuerst klärst, an welcher Stelle der Ablauf scheitert. Findet WinGet das Paket nicht? Ist eine Paketquelle nicht erreichbar? Oder startet der Installer, bricht das Update aber ab? Diese Fälle sehen in der Konsole ähnlich aus, haben jedoch unterschiedliche Ursachen.

Diese Anleitung führt dich durch die Fehlersuche in einer sinnvollen Reihenfolge: erst WinGet selbst prüfen, dann Quellen und Paket-ID kontrollieren und zuletzt das fehlgeschlagene Update anhand der Protokolle untersuchen. Die grundlegenden Befehle zum Suchen, Installieren und Aktualisieren findest du in unserem Beitrag Alles, was du über die Kommandozeilenfunktion von WinGet wissen musst.

WinGet-Fehler beheben: Zuerst den Fehler eingrenzen

Wiederhole nicht sofort winget upgrade --all. Suche zunächst das betroffene Programm und führe das Update einzeln aus. So siehst du, ob der Fehler an einer bestimmten Anwendung, ihrer Paketquelle oder am WinGet-Client liegt.

winget --info
winget source list
winget upgrade

winget --info zeigt unter anderem Informationen zum installierten Client und den Pfad der Protokolle. winget source list zeigt die eingerichteten Paketquellen. winget upgrade listet verfügbare Aktualisierungen auf, ohne sie bereits zu installieren.

Notiere die genaue Fehlermeldung und gegebenenfalls den Fehlercode. Entscheidend ist auch, ob die Meldung vor dem Download, während des Downloads oder nach dem Start des Installers erscheint.

Problem 1: Eine WinGet-Quelle ist nicht erreichbar

WinGet verwendet Paketquellen, um Anwendungen und ihre Installationsdateien zu finden. Zu den Standardquellen gehören der WinGet-Katalog und msstore für den Microsoft Store. Welche Quellen bei dir eingerichtet sind, zeigt:

winget source list

Wenn eine Suche oder ein Update an einer Quelle scheitert, aktualisiere zunächst ihre Metadaten:

winget source update

Du kannst auch nur eine bestimmte Quelle aktualisieren:

winget source update --name winget

Prüfe danach erneut die Suche oder das Update. Scheitert ausschließlich eine bestimmte Quelle, kannst du den Suchbereich mit --source eingrenzen. Damit stellst du fest, ob das Paket im WinGet-Katalog verfügbar ist, ohne gleichzeitig andere Quellen abzufragen:

winget search PowerToys --source winget

Bei Quellenfehlern solltest du außerdem Internetverbindung, Proxy und gegebenenfalls die Netzwerkregeln deiner Organisation prüfen. Fordert eine Quelle die Zustimmung zu ihren Nutzungsbedingungen, muss diese zunächst erteilt werden. In unbeaufsichtigten Abläufen gibt es dafür die Option --accept-source-agreements. Verwende sie nur, wenn die Bedingungen für deinen Einsatz geprüft wurden.

Quellen zurücksetzen: Erst als letzter Schritt

Ein Zurücksetzen kann bei beschädigten Quelleinstellungen helfen, ist aber kein guter erster Versuch. winget source reset --force entfernt zusätzlich eingerichtete Quellen und stellt die Standardquellen wieder her. In einer Umgebung mit eigenen Unternehmensquellen kann das weitere Probleme verursachen. Dokumentiere solche Quellen deshalb vor einem Reset und kläre, ob ihre Einrichtung zentral verwaltet wird.

Problem 2: Paket nicht gefunden oder mehrere Treffer

Ein Programmname ist nicht immer eindeutig. Eine Suche nach einem kurzen Begriff kann mehrere Editionen, Hersteller oder Quellen liefern. Suche zunächst nach dem Namen und lies die Spalten Name, ID und Quelle:

winget search PowerToys

Verwende für die weitere Fehlersuche die Paket-ID aus dem Ergebnis. Im folgenden Beispiel lautet sie Microsoft.PowerToys:

winget show --id Microsoft.PowerToys --exact --source winget

Mit --id suchst du gezielt nach der Paket-ID, --exact verlangt eine exakte Übereinstimmung und --source legt die Quelle fest. Das verhindert, dass WinGet versehentlich ein ähnlich benanntes Paket auswählt.

Prüfe zusätzlich, wie das Programm auf deinem Rechner erkannt wird:

winget list --id Microsoft.PowerToys --exact

Wichtig: winget list kann auch Programme anzeigen, die ursprünglich außerhalb von WinGet installiert wurden. Ein Eintrag in dieser Liste bedeutet daher nicht automatisch, dass die Anwendung damals über WinGet installiert wurde. Für ein Update muss WinGet die vorhandene Installation außerdem einem passenden Paket zuordnen können.

Problem 3: Das Update wird nicht angeboten

Wenn winget upgrade ein erwartetes Update nicht anzeigt, vergleiche zuerst die installierte Version mit der im Katalog angebotenen Version. Prüfe danach, ob das Paket angeheftet wurde oder WinGet die installierte Versionsnummer überhaupt erkennen kann.

Manche Anwendungen melden keine eindeutig auswertbare Versionsnummer. WinGet kann dann nicht zuverlässig entscheiden, ob eine neuere Version vorhanden ist. Solche Programme werden bei winget upgrade --all normalerweise nicht einfach mit aktualisiert. Die Option --include-unknown nimmt auch Pakete ohne bekannte installierte Version auf. Setze sie gezielt ein, nachdem du das betroffene Paket geprüft hast, statt sie vorsorglich auf alle Programme anzuwenden.

Ist ein Paket in WinGet angeheftet, kann das ebenfalls erklären, warum es bei einem Sammelupdate fehlt. Prüfe in diesem Fall die vorhandenen Pins und entscheide bewusst, ob die festgelegte Version weiterhin benötigt wird.

Problem 4: Ein einzelnes Update schlägt fehl

Starte das Update für genau ein Paket und aktiviere ausführliche Protokolle:

winget upgrade --id Microsoft.PowerToys --exact `
  --source winget --verbose-logs

Ersetze Microsoft.PowerToys durch die ID des tatsächlich betroffenen Programms. Läuft der Befehl bis zum Installer und scheitert erst dort, liegt die Ursache möglicherweise beim Installationsprogramm und nicht bei der WinGet-Suche.

Typische Gründe sind:

  • Das Programm oder eine zugehörige Datei wird noch verwendet.
  • Der Installer benötigt erhöhte Rechte oder einen Neustart.
  • Eine andere Installation läuft bereits.
  • Die vorhandene Installation verwendet einen anderen Installationsbereich, etwa nur für den Benutzer statt für den gesamten Rechner.
  • Der Hersteller hat den Installer oder seine Download-Adresse geändert.

Schließe die betroffene Anwendung und starte das einzelne Update erneut. Prüfe bei einer verwalteten Arbeitsumgebung außerdem, ob Richtlinien oder Sicherheitssoftware die Installation verhindern. Führe WinGet nicht pauschal als Administrator aus: Ein anderes Benutzerkonto oder ein anderer Installationsbereich kann die Zuordnung zur vorhandenen Installation verändern.

WinGet-Protokolle lesen statt Fehlercodes zu raten

WinGet legt bei der Ausführung Protokolldateien an. Den Speicherort findest du mit:

winget --info

Du kannst das Protokollverzeichnis nach einem fehlgeschlagenen Befehl auch direkt öffnen:

winget upgrade --id Microsoft.PowerToys --exact `
  --source winget --verbose-logs --open-logs

Suche in der neuesten Protokolldatei nach der Paket-ID, dem Download-Vorgang und dem Rückgabecode des Installers. WinGet stellt außerdem einen Befehl bereit, der bekannte Fehlercodes erläutert:

winget error 1603

Der Beispielcode 1603 ist ein allgemeiner MSI-Installationsfehler. Die Erklärung des Codes allein nennt noch nicht die konkrete Ursache auf deinem Rechner. Dafür brauchst du den Zusammenhang aus WinGet-Protokoll, Installer-Meldung und gegebenenfalls weiteren Installationslogs.

Wenn ein Download mit 403 Forbidden scheitert, kann auch der Downloadserver des Herstellers die Anfrage ablehnen. Dass dieselbe Datei im Browser heruntergeladen werden kann, beweist in diesem Fall nicht, dass WinGet Zugriff erhält. Prüfe die Protokolle und ob für das Paket bereits ein bekannter Fehler gemeldet wurde.

Wenn der Befehl „winget“ gar nicht gefunden wird

WinGet wird unter Windows über das Paket App Installer bereitgestellt. Wird winget nicht als Befehl erkannt, prüfe zuerst, ob App Installer für deinen Benutzer installiert und aktuell ist. Starte nach einer Installation oder Aktualisierung ein neues Terminalfenster und versuche es erneut.

In einer Unternehmensumgebung können Bereitstellung und Nutzung von App Installer durch Richtlinien beeinflusst werden. Prüfe dort die vorgesehenen Installationswege, bevor du den Client manuell ersetzt. Microsoft beschreibt weitere Schritte in der offiziellen WinGet-Fehlersuche.

Sammelupdates erst nach der Einzelprüfung ausführen

Ein winget upgrade --all ist bequem, erschwert aber die Diagnose: Mehrere Installer können nacheinander starten, und am Ende musst du herausfinden, welcher davon gescheitert ist. Gehe bei Problemen deshalb in dieser Reihenfolge vor:

  1. Mit winget upgrade verfügbare Updates anzeigen.
  2. Die ID des betroffenen Pakets mit winget search und winget list prüfen.
  3. Das einzelne Paket mit --id, --exact und gegebenenfalls --source aktualisieren.
  4. Bei einem Fehlschlag ausführliche Protokolle öffnen und den Installer-Code prüfen.
  5. Erst danach erneut ein Sammelupdate starten, falls es für deinen Rechner sinnvoll ist.

Vermeide bei der Fehlersuche Abkürzungen wie --force oder das Ignorieren einer fehlgeschlagenen Hash-Prüfung. Sie können wichtige Hinweise überdecken. Ein Hash-Fehler verdient eine genaue Prüfung der Quelle und des heruntergeladenen Installers.

Fazit

WinGet-Fehler beheben gelingt am zuverlässigsten mit einer klaren Trennung der Ursachen. Quellenfehler untersuchst du mit winget source list und winget source update. Bei falschen oder mehrdeutigen Treffern helfen die Paket-ID, --exact und eine gezielt gewählte Quelle. Scheitert erst die Installation, liefern die WinGet-Protokolle und der Rückgabecode des Installers die wichtigsten Anhaltspunkte.

Starte bei Problemen mit einem einzelnen Paket. So kannst du nach jeder Änderung sehen, ob sie tatsächlich geholfen hat, und vermeidest zusätzliche Fehler durch ein vorschnelles Sammelupdate.

Weiterführende Microsoft-Dokumentation