Debuggen und Beheben von Problemen mit dem WinGet-Tool

Wenn WinGet nicht ordnungsgemäß installiert wird, führen Sie die folgenden Schritte aus einer PowerShell-Eingabeaufforderung aus:

Install-PackageProvider -Name NuGet -Force | Out-Null
Install-Module -Name Microsoft.WinGet.Client -Force -Repository PSGallery | Out-Null
Repair-WinGetPackageManager -Force -Latest

Wenn WinGet-Befehle fehlschlagen, ist es manchmal notwendig, die Protokolldateien zu betrachten, um das Verhalten besser zu verstehen.

WinGet-Protokolle

Windows-Paket-Manager erstellt beim Ausführen von Befehlen standardmäßig Protokolldateien. Diese Protokolle enthalten Informationen, die beim Debuggen von Problemen mit WinGet helfen können. Es gibt keine maximale Größe für die Protokolldateien. Sie sind in der Regel nur wenige KB groß. Wenn die Anzahl der Protokolldateien im Verzeichnis 100 überschreitet, werden die ältesten Protokolldateien gelöscht. Es gibt keine zeitbasierte Entfernung von Protokollen, und diese Einstellungen können nicht konfiguriert werden. Wenn Sie die Kapazität von 100 Dateiprotokollen erreicht haben, verschieben Sie einfach alle WinGet-Protokolle, die Sie behalten möchten, in ein anderes Verzeichnis.

Verwenden Sie den Befehl winget --info, um den Verzeichnispfad zu Ihren WinGet-Protokolldateien zu finden. Der Standardpfad für WinGet-Protokolldateien lautet:

%LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir

Sie können die Option --logs oder --open-logs in einen beliebigen Befehl einschließen, um das Protokollverzeichnis nach Abschluss des Befehls zu öffnen. Im Folgenden finden Sie einige Beispiele für die Verwendung der Option --logs:

> winget list --logs
> winget source update --open-logs

--verbose-logs

Wenn Sie komplexere Protokolldateien benötigen, die die vollständige Kommunikation mit den CDNs und Quellen bereitstellen, geben Sie in der Befehlszeile auch --verbose oder --verbose-logs an. Im Folgenden finden Sie einige Beispiele für die Verwendung der Option --verbose-logs:

> winget install vscode --verbose-logs
> winget search -n visual --verbose-logs
> winget source add -n mysource -t Microsoft.REST -a https://www.contoso.org --verbose

Bekannte Probleme

Eine Liste bekannter Probleme mit Quellen und Verhaltensweisen wird im Repository des Windows-Paket-Manager-Clients auf dem neuesten Stand gehalten. Wenn bei der Verwendung des WinGet-Tools Probleme auftreten, finden Sie hier Informationen zur Problembehandlung.

Exitcodes

Das WinGet-Tool gibt Exitcodes zurück, um den Erfolg oder Fehler des Befehls anzuzeigen. Suchen Sie eine Tabelle mit Exitcodes und deren Bedeutungen in der Datei „Return codes“ des Windows-Paket-Manager-Client-Repositorys.

Bereich für bestimmte Benutzer*innen im Vergleich zum computerweiten Bereich

Nicht alle Installationsprogramme unterstützen konsistent die Installation in den Bereichen „Benutzer“ und „Computer“.

• MSIX-basierte Pakete: Zuverlässiges WinGet-Verhalten.
• MSI-basierte Pakete unterstützen in der Regel zuverlässige WinGet-Konfigurationen, werden jedoch in einigen Fällen in einem EXE-basierten Installationsprogramm geschachtelt, sodass die Variabilität erhöht werden kann.
• Das Verhalten von EXE-basierten Installationsprogrammen in Bezug auf den Bereich ist nicht unbedingt deterministisch. In einigen Fällen sind die Argumente zum Angeben des Bereichs nicht verfügbar, und in anderen Fällen kann das Installationsprogramm die Bestimmung abhängig davon vornehmen, ob der Benutzer bzw. die Benutzerin Mitglied der lokalen Administratorgruppe ist. Pakete, die im Benutzerbereich installiert sind, erfordern möglicherweise weiterhin UAC-Autorisierung (User Account Control, Benutzerkontensteuerung) von einem*r Administrator*in.

Weitere Details zu bereichsbezogenen Problemen finden Sie im WinGet-Produktrepository auf GitHub.

Fehler 403 „Unzulässig“

Beim Versuch, ein Paket mithilfe des WinGet-Tools herunterzuladen, tritt möglicherweise ein 403 Verbotener Fehler auf. Dieses Problem kann auftreten, wenn ein unabhängiger Softwareanbieter (ISV) sein Produkt nicht über einen Paket-Manager-Dienst wie WinGet verteilt hat.

Der Server, der zum Initiieren des Downloads aufforderbar ist, sucht in der Regel nach einer Benutzer-Agent-Zeichenfolge, die in der Downloadanforderung enthalten ist, um das Gerät oder den Client zu identifizieren (z. B. Browser, WinGet). Wenn Sie das Installationsprogramm mithilfe Ihres Browsers herunterladen können, aber probleme mit WinGet auftreten, ist es möglich, dass der ISV die WinGet-Benutzer-Agent-Zeichenfolge blockiert hat.

Die Benutzer-Agent-Zeichenfolge für WinGet weist das folgende Format auf:

winget-cli WindowsPackageManager/{Client Version} DesktopAppInstaller/Microsoft.DesktopAppInstaller {AppInstaller Version}

Beispiel:

winget-cli WindowsPackageManager/1.9.25200 DesktopAppInstaller/Microsoft.DesktopAppInstaller v1.24.25200.0