Partager via

Résoudre les problèmes de démarrage de PowerShell

Parfois, PowerShell peut rencontrer des problèmes avant même qu’il soit prêt à être utilisé. Les problèmes de démarrage peuvent être difficiles à résoudre, en particulier lorsque vous souhaitez utiliser PowerShell pour vous aider. Il existe trois phases principales de démarrage :

  1. Création de processus
  2. Initialisation de PowerShell SessionState
  3. Traitement de profil

Les problèmes les plus courants sont les suivants :

  • Temps de démarrage long ou performances lentes
  • Errors
  • Collisions

Étapes de la séquence de démarrage

Il est utile de comprendre les étapes de démarrage de PowerShell. De cette façon, vous pouvez limiter l’endroit où se produit le problème.

Étape 1 : Création de processus

La création du processus comporte quelques étapes :

  1. Créer une fenêtre Hôte

    Sur Windows, l’hôte peut être le terminal Windows, l’hôte de console Windows, Visual Studio Code ou toute autre application d’hébergement. Les problèmes qui se produisent ici ne sont généralement pas liés à PowerShell, mais aussi extrêmement rares.

  2. Démarrer le processus hôte

    Les problèmes qui se produisent ici sont généralement causés par un exécutable endommagé ou un problème dans le système d’exploitation.

  3. Préparer .NET

    PowerShell est basé sur .NET et doit être entièrement chargé. Selon la version de PowerShell que vous essayez de démarrer, vous obtenez le .NET Framework intégré à Windows avec Windows PowerShell 5.1 ou le .NET plus récent inclus dans PowerShell 7.

    Au démarrage de PowerShell, PowerShell et .NET exécutent des tâches d’optimisation. Cette tâche d’optimisation n’est exécutée qu’une seule fois, au cours du premier démarrage après l’installation, la mise à niveau ou si le cache est vide. Le démarrage prendra plus de temps pendant cette première optimisation. Une défaillance pendant l’optimisation peut créer un cache endommagé. Un cache PowerShell endommagé peut entraîner des problèmes de détection de commandes et de chargement de module.

Étape 2 : Initialisation de PowerShell SessionState

Le chargement des fichiers binaires PowerShell et l’initialisation du moteur implique le traitement de la configuration PowerShell et de certaines données mises en cache.

  1. Traiter les fichiers de configuration : powershell.config.json et les fichiers de configuration PSSession utilisés par JEA et d’autres scénarios de communication à distance. Ces fichiers peuvent contenir des paramètres qui peuvent affecter le mode de langage, les commandes disponibles et les modules, ainsi que certains paramètres de stratégie.
  2. Vérifiez les stratégies de groupe et les stratégies de sécurité Windows. Les stratégies de groupe Windows peuvent remplacer les paramètres dans le powershell.config.json. Les stratégies de sécurité peuvent activer des fonctionnalités telles que WDAC (Windows Defender Application Control), qui peuvent également limiter le mode de langage disponible.
  3. Chargez les modules par défaut (Microsoft.PowerShell.Core et PSReadLine) et tous les modules et assemblys définis dans la configuration PSSession.

Pour plus d’informations sur les fonctionnalités de sécurité PowerShell, consultez les articles suivants :

Étape 3 : Traitement du profil

Enfin, PowerShell exécute les fichiers de profil disponibles. Les scripts de profil sont exécutés dans l’ordre suivant :

  1. Tous les hôtes et tous les utilisateurs
  2. Tous les utilisateurs de l'hôte actuel
  3. Tous les hôtes de l’utilisateur actuel
  4. Hôte actuel Utilisateur actuel

Note

Les scripts de profil ne sont pas exécutés pour les sessions à distance.

Pour plus d’informations sur les profils, consultez about_Profiles.

Restreindre l’étendue du problème

Il est utile de supprimer des variables et de limiter l’étendue spécifique de l’endroit où le problème se produit. La variable la plus simple à éliminer est le profil. Le profil contient souvent du code personnalisé, en particulier dans les scripts de profil spécifiques à l’utilisateur.

Essayez d’exécuter PowerShell avec le profil désactivé :

# PS 5.1:
powershell -NoProfile

# PS 7.*:
pwsh -NoProfile

Ensuite, vous devez voir si le problème est spécifique à la version. Essayez d’exécuter votre profil dans Windows PowerShell 5.1 et PowerShell 7. Windows PowerShell et PowerShell 7 stockent le profil à différents emplacements. Votre profil peut ne pas être identique pour les deux versions. Comparez les fichiers pour comprendre les différences. Vous pouvez essayer d’installer votre profil PowerShell dans Windows PowerShell 5.1. Toutefois, sachez que certaines commandes et modules PowerShell 7 ne sont pas compatibles avec Windows PowerShell 5.1.

Vous pouvez tester votre profil PowerShell 7 dans Windows PowerShell 5.1 sans remplacer votre profil existant.

  1. Démarrez Windows PowerShell 5.1 avec le profil désactivé.

  2. Sourcez manuellement votre fichier de profil PowerShell 7 dans la session Windows PowerShell 5.1.

    . $env:USERPROFILE\Documents\PowerShell\Microsoft.PowerShell_profile.ps1

  3. Observez si le problème se produit.

Si le problème persiste, vous savez que le problème est un problème environnemental en dehors du profil.

Essayez d’exécuter le profil sur un autre appareil. Si le profil fonctionne correctement sur un autre appareil, vous savez que le problème est spécifique à votre appareil d’origine.

Résoudre les problèmes environnementaux courants

Pannes au démarrage

Si la console PowerShell se bloque au démarrage, en particulier au début et sans commentaires, vous pourriez avoir un cache de processus endommagé. Il s’agit d’une condition rare que vous pouvez résoudre en désactivant le cache. Il existe deux emplacements de cache qui peuvent être effacés :

  • Cache utilisateur : $env:LOCALAPPDATA\Microsoft\Windows\Caches
  • Cache système : $env:windir\System32\Config\SystemProfile\AppData\Local\Microsoft\Windows\Caches

Supprimez d’abord le contenu du dossier du cache utilisateur, puis réessayez de démarrer PowerShell. Si le problème persiste, supprimez le contenu du cache système et réessayez.

Vous devrez peut-être également supprimer le cache d’analyse PowerShell. Vous trouverez les fichiers de cache dans les emplacements suivants :

  • Windows PowerShell : $env:windir\System32\Config\SystemProfile\AppData\Local\Microsoft\Windows\PowerShell
  • PowerShell 7 : $env:LOCALAPPDATA\Microsoft\PowerShell

Supprimez uniquement les modèles de fichiers suivants :

  • ModuleAnalysisCache-*
  • StartupProfileData-*

Les données mises en cache sont recréées la prochaine fois que vous démarrez PowerShell.

Si le problème persiste dans Windows PowerShell 5.1, vous devrez peut-être réparer l’installation du .NET Framework. Pour plus d’informations, consultez Réparer le .NET Framework.

Résoudre les problèmes de profil courants

Cette section décrit certains problèmes courants qui peuvent se produire au démarrage de PowerShell et comment les résoudre.

Le profil prend beaucoup de temps à s'exécuter

Tout d’abord, vous devez définir ce qui est « trop long ». PowerShell ne fait que ce que les scripts lui indiquent de faire. Vérifiez tous les chemins d’accès au profil. Plusieurs scripts de profil peuvent être exécutés. Passez en revue le code pour comprendre qu’il tente de le faire.

  • Déterminer où se produit le délai

    S’il existe des scripts de profil pour l’étendue AllUsers , vous ne pourrez peut-être pas modifier ces fichiers. Collaborez avec votre administrateur système pour passer en revue ces fichiers. Pour les scripts de profil d’étendue CurrentUser, modifiez ces fichiers pour ajouter des messages de chronométrage afin de vous aider à identifier l'emplacement du délai. Par exemple, vous pouvez ajouter la ligne suivante à différents points dans votre script de profil.

    Write-Host "$(Get-Date -Format 'HH:mm:ss.fff') | Profile: Step X"

  • Réduire les dépendances

    Réduisez le nombre de modules à charger pour exécuter votre profil. Exécutez Get-Module après l’exécution du profil pour voir les modules qui ont été chargés au démarrage. Par défaut, PowerShell charge les modules Microsoft.PowerShell.Core et PSReadLine. Tous les modules supplémentaires ont été chargés par vos scripts de profil.

    Les modules peuvent être chargés explicitement à l’aide Import-Module ou implicitement à l’aide de commandes définies dans ces modules. Déterminez si vous avez besoin d’une commande ou d’un module chargé au démarrage.

  • Éviter d’installer des modules dans un dossier redirigé

    Dans de nombreuses situations sur Windows, votre Documents dossier peut être redirigé vers un partage de fichiers réseau ou vers OneDrive. L'accès aux fichiers réseau peut être lent, en particulier si le réseau est congestionné ou si le serveur est sous une charge importante. Selon la configuration de OneDrive, il peut également introduire des retards ou provoquer des erreurs lors de l’exécution du profil.

    Vous avez quelques options pour atténuer ce problème :

    • Ne redirigez pas votre Documents dossier, mais cela peut ne pas être souhaité
    • Configurez votre Modules dossier dans OneDrive pour qu’il soit toujours conservé sur le disque. Cela empêche les erreurs et les temps de chargement retardés.
    • Installez des modules dans l’étendue AllUsers , qui se trouve en dehors du dossier de profil utilisateur.

  • Mesurer les performances réelles

    Si vous ne savez pas combien de temps votre profil prend pour s’exécuter, vous ne pouvez pas déterminer s’il est trop long. L’applet Measure-Command de commande peut indiquer la durée d’exécution d’une commande ou d’un bloc de script.

    Steve Lee, le Gestionnaire de développement PowerShell, a un billet de blog qui explique comment mesurer les performances de votre profil. Il inclut des instructions pour établir une base de référence pour les performances, obtenir des informations de minutage détaillées et des façons d’optimiser votre profil. Consultez Optimisation de votre $Profile.

PowerShell 7 démarre lentement dans un réseau isolé

Dans ce scénario, votre ordinateur Windows se trouve sur un réseau qui n’est pas connecté à Internet. Pour les sessions PowerShell interactives, PowerShell charge automatiquement le module PSReadLine. PSReadLine est un module signé. PowerShell doit vérifier la signature numérique du module. Cette vérification peut entraîner des retards dans un environnement déconnecté. Pour tester cette théorie, démarrez PowerShell 7 en mode non interactif :

pwsh.exe -noninteractive

Si PowerShell démarre rapidement en mode non interactif, le problème est probablement dû aux vérifications de liste de révocation de certificats (CRL). Dans le cadre du processus de vérification d’une signature numérique, l'environnement d'exécution .NET vérifie la liste de révocation de certificats (CRL) pour s'assurer que le certificat de signature est toujours valide. Dans un environnement déconnecté, votre ordinateur ne peut pas accéder à la liste de révocation de certificats sur Internet. Le délai d’expiration par défaut pour les vérifications de liste de révocation de certificats est de 15 secondes. Cela signifie que chaque fois que PowerShell charge un module signé, le délai d’expiration peut prendre jusqu’à 15 secondes.

Il existe trois solutions de contournement possibles pour ce problème :

  • Exemption de pare-feu ou de proxy

    L’autorisation d’accès direct à Internet pour la vérification de la liste de révocation de certificats empêche le problème. Dans un environnement où vous pouvez contrôler l’accès à Internet, vous pouvez configurer votre pare-feu ou votre proxy pour autoriser l’accès aux URL de la liste de révocation de certificats. Il s’agit de la solution la plus simple avec le moins d’impact. Les journaux du pare-feu doivent afficher l’URL que PowerShell a tenté d’atteindre.

  • Réduire le délai d’expiration de la liste de révocation de certificats (CRL)

    La réduction du délai d’attente pour la recherche de la liste de révocation de certificats est possible, mais cela risque de faire échouer d'autres recherches, risquant de ne pas se terminer dans le temps spécifié. Pour plus d’informations sur la modification du délai d’expiration, consultez Gérer la récupération du réseau et la validation du chemin d’accès.

  • Supprimer la vérification de la liste de révocation de certificats

    Les paramètres de vérification de la CRL (liste de révocation de certificats) sont gérés par la stratégie de groupe. Pour plus d’informations, consultez Gérer les serveurs de publication approuvés.

    Avertissement

    Il est possible de désactiver la vérification de la liste de révocation de certificats, toutefois, cela n'est pas recommandé. La désactivation de la vérification de la liste de révocation de certificats vous empêche de révoquer réellement des certificats compromis.

ERREUR : Impossible de mettre à la source cette commande, car elle a été définie en mode de langage différent

PowerShell fonctionne avec des systèmes de contrôle d’application, tels que AppLocker et Windows Defender Application Control (WDAC), en s’exécutant automatiquement en mode ContrainteLanguage . Le mode ConstrainedLanguage restreint certaines fonctionnalités potentiellement dangereuses. Toutefois, il existe des moments où vous avez besoin du mode FullLanguage pour utiliser certaines commandes ou fonctionnalités. Les scripts peuvent s’exécuter en mode FullLanguage lorsqu’ils sont approuvés par la stratégie. L’approbation peut être indiquée par le biais de la signature de fichiers ou d’autres mécanismes de stratégie configurés dans AppLocker ou WDAC.

Lorsque vous démarrez une session PowerShell gérée sous contrôle d’application, vous obtenez l’erreur suivante :

Cannot dot-source this command because it was defined in a different language mode. To invoke this
command without importing its contents, omit the '.' operator.

Sous contrôle d’application, PowerShell s’exécute en mode ContrainteLanguage . Cette erreur se produit quand et que votre script de profil est exempté ou est signé pour s’exécuter en mode FullLanguage . Lorsque PowerShell s'exécute en mode LangageContrainte, il ne peut pas exécuter de code source pointé ayant l'autorisation de s'exécuter en mode LangageComplet.

Pour résoudre le problème, vous devez supprimer l’exemption ou la signature du script de profil. Si vous avez besoin de code qui doit s’exécuter en mode FullLanguage pendant votre profil, déplacez-le dans un autre fichier de script exempté ou signé. Appelez (ne pas dot-source) ce fichier de script à partir de votre profil.

Pour plus d’informations sur ce problème, consultez le mode langage contrainte PowerShell et l’opérateur Dot-Source.

Lectures complémentaires

  • Last updated on