Débogage et résolution des problèmes liés à l’outil WinGet

Si WinGet n’apparaît pas correctement installé, procédez comme suit à partir d’une invite de commandes PowerShell :

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

Lorsque les commandes WinGet échouent, il est parfois nécessaire d’examiner les fichiers journaux pour mieux comprendre le comportement.

Journaux de WinGet

Le Gestionnaire de package Windows crée par défaut des fichiers journaux au moment de l’exécution des commandes. Ces journaux contiennent des informations qui peuvent faciliter la résolution des problèmes avec WinGet. Le comportement de nettoyage des fichiers journaux est configurable via les paramètres de journalisation dans votre fichier de paramètres. Par défaut, les fichiers journaux antérieurs à 7 jours ou dépassant le total de 128 Mo sont automatiquement supprimés et les fichiers journaux individuels sont encapsulés à 16 Mo. Utilisez les logging.file paramètres pour ajuster ces limites.

Utilisez la commande winget --info pour rechercher le chemin d’accès au répertoire de vos fichiers journaux WinGet. Le chemin d’accès par défaut pour les fichiers journaux WinGet est le suivant :

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

Vous pouvez inclure l’option --logs ou --open-logs à n’importe quelle commande pour ouvrir le répertoire des journaux une fois la commande terminée. Voici quelques exemples d’utilisation de l’option --logs :

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

--verbose-logs

Si vous avez besoin de fichiers journaux plus complets, qui fournissent une communication complète avec les CDN et les sources, incluez également --verbose ou --verbose-logs sur la ligne de commande. Voici quelques exemples d’utilisation de l’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

paramètres

Vous pouvez spécifier le niveau de journalisation par défaut pour WinGet à utiliser dans votre fichier Paramètres WinGet. La commande paramètres ouvre le fichier settings.json dans votre éditeur JSON par défaut.

Exemple avec journalisation détaillée :

{
    "$schema": "https://aka.ms/winget-settings.schema.json",
    "logging": {
        "level": "verbose"
    }
}

Problèmes connus

Une liste de problèmes connus liés aux sources et aux comportements est tenue à jour dans le dépôt du client Gestionnaire de package Windows. Si vous rencontrez des problèmes durant l’utilisation de l’outil WinGet, vous trouverez ici des informations sur leur résolution.

Codes de sortie

L’outil WinGet retourne des codes de sortie pour indiquer la réussite ou l’échec de la commande. Recherchez une table des codes de sortie et leurs significations dans le fichier « Codes de retour » du référentiel client du Gestionnaire de package Windows.

La commande error de WinGet accepte les erreurs provenant des « codes de sortie » et affiche une description des codes d’erreur connus pour les installateurs WinGet, MSIX et MSI. De nombreux programmes d’installation basés sur .exeont des codes d’erreur non standard et peuvent ne pas être affichés.

> winget error 1603

Étendue pour un utilisateur spécifique ou à l'échelle du système

Les programmes d’installation ne prennent pas tous en charge de manière cohérente l’installation en mode « utilisateur » ou en mode « machine ».

• Packages basés sur MSIX : Comportement WinGet fiable.
• Les packages basés sur MSI prennent généralement en charge les configurations WinGet fiables, mais dans certains cas, ils sont imbriqués dans un programme d’installation basé sur .exe, ce qui peut entraîner plus d’instabilité.
• Le comportement des programmes d’installation basés sur EXE autour de l’étendue n’est pas nécessairement déterministe. Dans certains cas, les arguments permettant de spécifier l’étendue ne sont pas disponibles, tandis que dans d’autres cas, le programme d’installation peut déterminer si l’utilisateur est membre du groupe Administrateurs local. Les paquets installés dans le cadre du compte utilisateur peuvent tout de même nécessiter l'autorisation du Contrôle de compte d'utilisateur (UAC) d'un administrateur.

Pour plus d’informations sur les problèmes liés aux étendues, consultez le dépôt de produits WinGet sur GitHub.

Erreur 403 : Accès refusé

Une erreur 403 Interdit peut se produire lors de la tentative de téléchargement d’un package à l’aide de l’outil WinGet. Ce problème peut survenir si un fournisseur de logiciels indépendant (ISV) choisit de ne pas faire distribuer son produit par un service de gestionnaire de paquets tel que WinGet.

Le serveur responsable du lancement du téléchargement recherche généralement une chaîne d’agent utilisateur incluse dans la demande de téléchargement pour identifier l’appareil ou le client (par exemple, navigateur, WinGet). Si vous pouvez télécharger le programme d’installation à l’aide de votre navigateur, mais rencontrez des problèmes avec WinGet, il est possible que l’éditeur de logiciels indépendants ait bloqué la chaîne d’agent utilisateur de WinGet.

La chaîne de l’agent utilisateur pour WinGet a le format suivant :

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

Exemple :

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

Contexte système

WinGet est fourni via le programme d’installation d’application en tant qu’application empaquetée. Les applications MSIX (empaquetées) dépendent d’un alias d’exécution d’application à résoudre sur la variable d’environnement PATH. L’interface CLI WinGet n’est pas prise en charge dans le contexte système. Le module PowerShell Microsoft.WinGet.Client peut être utilisé dans le contexte système avec des applications installées à l’échelle de l’ordinateur.