Freigeben über

Behandeln von Problemen beim Starten von PowerShell

Manchmal kann PowerShell Probleme haben, bevor es einsatzbereit ist. Startprobleme können schwierig zu beheben sein, insbesondere wenn Sie PowerShell als Hilfsmittel zur Problembehebung verwenden möchten. Es gibt drei Hauptphasen des Starts:

  1. Prozesserstellung
  2. PowerShell SessionState-Initialisierung
  3. Profilverarbeitung

Zu den häufigsten Problemen gehören:

  • Lange Startzeit oder langsame Leistung
  • Errors
  • Abstürze

Die Schritte der Startsequenz

Es ist hilfreich, die Schritte zu verstehen, die PowerShell beim Start durchläuft. Auf diese Weise können Sie den Ort einschränken, an dem das Problem auftritt.

Schritt 1: Prozesserstellung

Die Prozesserstellung umfasst einige Schritte:

  1. Erstellen eines Hostfensters

    Unter Windows kann der Host Windows Terminal, der Windows-Konsolenhost, Visual Studio Code oder eine andere Hostinganwendung sein. Probleme, die hier auftreten, sind in der Regel nicht mit PowerShell verbunden, aber auch extrem selten.

  2. Starten des Prozesshostprozesses

    Probleme, die hier auftreten, werden in der Regel durch eine beschädigte ausführbare Datei oder ein Problem im Betriebssystem verursacht.

  3. Bereite .NET vor.

    PowerShell ist .NET-basiert und muss vollständig geladen werden. Je nachdem, welche PowerShell-Version Sie starten möchten, erhalten Sie entweder das vollständige, windows-integrierte .NET Framework mit Windows PowerShell 5.1 oder das neuere .NET, das in PowerShell 7 enthalten ist.

    Während des ersten Starts von PowerShell führen PowerShell und .NET Optimierungsaufgaben aus. Diese Optimierungsaufgabe wird nur einmal ausgeführt, während des ersten Starts nach installation, upgraden oder wenn der Cache leer ist. Der Start dauert während dieser erstmaligen Optimierung länger. Fehler während der Optimierung können einen beschädigten Cache erstellen. Ein beschädigter PowerShell-Cache kann Zu Problemen beim Laden von Befehlen und Moduls führen.

Schritt 2: Initialisierung von PowerShell SessionState

Das Laden der PowerShell-Binärdateien und das Initialisieren des Moduls umfasst die Verarbeitung der PowerShell-Konfiguration und einiger zwischengespeicherter Daten.

  1. Konfigurationsdateien für Prozesse: powershell.config.json und PSSession-Konfigurationsdateien, die von JEA und anderen Remotingszenarien verwendet werden. Diese Dateien können Einstellungen enthalten, die sich auf den Sprachmodus, verfügbare Befehle und Module und einige Richtlinieneinstellungen auswirken können.
  2. Überprüfen Sie Gruppenrichtlinien und Windows-Sicherheitsrichtlinien. Windows-Gruppenrichtlinien können Einstellungen in der powershell.config.json. Sicherheitsrichtlinien können Features wie WDAC (Windows Defender Application Control) aktivieren, wodurch auch der verfügbare Sprachmodus eingeschränkt werden kann.
  3. Laden Sie die Standardmodule (Microsoft.PowerShell.Core und PSReadLine) und alle Module und Assemblys, die in der PSSession-Konfiguration definiert sind.

Weitere Informationen zu PowerShell-Sicherheitsfeatures finden Sie in den folgenden Artikeln:

Schritt 3: Profilverarbeitung

Schließlich führt PowerShell die verfügbaren Profildateien aus. Profilskripts werden in der folgenden Reihenfolge ausgeführt:

  1. Alle Hosts aller Benutzer
  2. Aktueller Host für alle Benutzer
  3. Alle Hosts aktueller Benutzer
  4. Aktueller Host Aktueller Benutzer

Hinweis

Profilskripts werden für Remotesitzungen nicht ausgeführt.

Weitere Informationen zu Profilen finden Sie unter about_Profiles.

Einschränken des Umfangs des Problems

Es ist hilfreich, Variablen zu entfernen und den spezifischen Bereich einzugrenzen, in dem das Problem auftritt. Die einfachste Variable, die entfernt werden kann, ist das Profil. Das Profil enthält häufig benutzerdefinierten Code, insbesondere in den benutzerspezifischen Profilskripts.

Führen Sie PowerShell mit deaktiviertem Profil aus:

# PS 5.1:
powershell -NoProfile

# PS 7.*:
pwsh -NoProfile

Als Nächstes sollten Sie sehen, ob das Problem versionsspezifisch ist. Versuchen Sie, Ihr Profil sowohl in Windows PowerShell 5.1 als auch in PowerShell 7 auszuführen. Windows PowerShell und PowerShell 7 speichern das Profil an verschiedenen Speicherorten. Ihr Profil ist für beide Versionen möglicherweise nicht identisch. Vergleichen Sie die Dateien, um die Unterschiede zu verstehen. Sie können versuchen, Ihr PowerShell-Profil in Windows PowerShell 5.1 zu installieren. Beachten Sie jedoch, dass einige PowerShell 7-Befehle und -Module nicht mit Windows PowerShell 5.1 kompatibel sind.

Sie können Ihr PowerShell 7-Profil in Windows PowerShell 5.1 testen, ohne Ihr vorhandenes Profil zu überschreiben.

  1. Starten Sie Windows PowerShell 5.1 mit deaktivierten Profilen.

  2. Stellen Sie Ihre PowerShell 7-Profildatei manuell in die Windows PowerShell 5.1-Sitzung ein.

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

  3. Beobachten Sie, ob das Problem auftritt.

Wenn das Problem weiterhin besteht, wissen Sie, dass das Problem ein Umweltproblem außerhalb des Profils ist.

Versuchen Sie, das Profil auf einem anderen Gerät auszuführen. Wenn das Profil auf einem anderen Gerät ordnungsgemäß funktioniert, wissen Sie, dass das Problem für Ihr ursprüngliches Gerät spezifisch ist.

Behandeln häufiger Umweltprobleme

Abstürze während des Starts

Wenn die PowerShell-Konsole während des Starts abstürzt, insbesondere frühzeitig und ohne Feedback, könnten Sie einen beschädigten Prozesscache haben. Dies ist eine seltene Bedingung, die Sie beheben können, indem Sie den Cache löschen. Es gibt zwei Cachespeicherorte, die gelöscht werden können:

  • Benutzercache: $env:LOCALAPPDATA\Microsoft\Windows\Caches
  • Systemcache: $env:windir\System32\Config\SystemProfile\AppData\Local\Microsoft\Windows\Caches

Löschen Sie zuerst den Inhalt des Benutzercacheordners, und starten Sie PowerShell erneut. Wenn das Problem weiterhin besteht, löschen Sie den Inhalt des Systemcaches, und versuchen Sie es erneut.

Möglicherweise müssen Sie auch den PowerShell-Analysecache löschen. Sie finden die Cachedateien an den folgenden Speicherorten:

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

Löschen Sie nur die folgenden Dateimuster:

  • ModuleAnalysisCache-*
  • StartupProfileData-*

Die zwischengespeicherten Daten werden beim nächsten Starten von PowerShell neu erstellt.

Wenn das Problem in Windows PowerShell 5.1 weiterhin besteht, müssen Sie möglicherweise die .NET Framework-Installation reparieren. Weitere Informationen finden Sie unter Reparieren von .NET Framework.

Behandeln Sie häufig auftretende Profilprobleme

In diesem Abschnitt werden einige häufige Probleme beschrieben, die während des PowerShell-Starts auftreten können und wie Sie diese beheben können.

Das Profil dauert zu lange, bis es ausgeführt wird.

Zuerst müssen Sie definieren, was "zu lang" ist. PowerShell tut nur, was die Skripts tun müssen. Überprüfen Sie alle Profilpfade. Möglicherweise werden mehrere Profilskripts ausgeführt. Überprüfen Sie den Code, um zu verstehen, was er versucht zu bewirken.

  • Ermitteln, wo die Verzögerung auftritt

    Wenn es Profilskripts für den Bereich "AllUsers " gibt, können Sie diese Dateien möglicherweise nicht bearbeiten. Arbeiten Sie mit Ihrem Systemadministrator zusammen, um diese Dateien zu überprüfen. Bearbeiten Sie die Dateien für die CurrentUser-Geltungsbereich-Profilskripte, um Zeitprotokollmeldungen hinzuzufügen, damit Sie feststellen können, wo die Verzögerung auftritt. Sie können beispielsweise die folgende Zeile an verschiedenen Stellen in Ihrem Profilskript hinzufügen.

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

  • Reduzieren von Abhängigkeiten

    Verringern Sie die Anzahl der Module, die geladen werden müssen, um Ihr Profil auszuführen. Führen Sie Get-Module nach dem Ausführen des Profilvorgangs aus, um die Module anzuzeigen, die beim Start geladen wurden. Standardmäßig lädt PowerShell die Module "Microsoft.PowerShell.Core" und "PSReadLine". Alle zusätzlichen Module wurden von Ihren Profilskripts geladen.

    Module können explizit durch die Verwendung von Import-Module oder implizit durch die Nutzung von Befehlen geladen werden, die in diesen Modulen definiert sind. Überlegen Sie, ob beim Start ein Befehl oder ein Modul geladen werden muss.

  • Vermeiden der Installation von Modulen in einem umgeleiteten Ordner

    In vielen Situationen unter Windows kann Ihr Documents Ordner zu einer Netzwerkdateifreigabe oder zu OneDrive umgeleitet werden. Der Zugriff auf Netzwerkdateien kann langsam sein, insbesondere, wenn das Netzwerk überlastet ist oder der Server stark belastet wird. Je nachdem, wie OneDrive konfiguriert ist, kann es auch Verzögerungen verursachen oder Fehler während der Profilexctution verursachen.

    Sie haben einige Optionen, um dieses Problem zu beheben:

    • Leiten Sie Ihren Documents Ordner nicht um, aber dies ist möglicherweise nicht gewünscht.
    • Konfigurieren Sie Ihren Modules Ordner in OneDrive so, dass er immer auf dem Datenträger gespeichert wird. Dadurch werden Fehler und verzögerte Ladezeiten verhindert.
    • Installieren Sie Module im Bereich "AllUsers ", die sich außerhalb des Benutzerprofilordners befinden.

  • Messen der tatsächlichen Leistung

    Wenn Sie nicht wissen, wie lange die Ausführung Ihres Profils dauert, können Sie nicht ermitteln, ob es zu lang ist. Das Measure-Command Cmdlet kann anzeigen, wie lange ein Befehl oder Skriptblock ausgeführt werden kann.

    Steve Lee, der PowerShell Dev Manager, hat einen Blogbeitrag, der beschreibt, wie die Leistung Ihres Profils gemessen wird. Es enthält Anweisungen zum Einrichten einer Basislinie für die Leistung, zum Abrufen detaillierter Zeitangaben und Möglichkeiten zur Optimierung Ihres Profils. Siehe Optimieren Ihrer $Profile.

PowerShell 7 beginnt langsam in einem isolierten Netzwerk.

In diesem Szenario befindet sich Ihr Windows-Computer in einem Netzwerk, das nicht mit dem Internet verbunden ist. Bei interaktiven PowerShell-Sitzungen lädt PowerShell das PSReadLine-Modul automatisch. PSReadLine ist ein signiertes Modul. PowerShell muss die digitale Signatur des Moduls überprüfen. Diese Überprüfung kann zu Verzögerungen in einer getrennten Umgebung führen. Starten Sie PowerShell 7 im nicht interaktiven Modus, um diese Theorie zu testen:

pwsh.exe -noninteractive

Wenn PowerShell schnell im nicht interaktiven Modus gestartet wird, wird das Problem wahrscheinlich durch Überprüfungen der Zertifikatsperrliste (Certificate Revocation List, CRL) verursacht. Im Rahmen des Prozesses zur Überprüfung einer digitalen Signatur überprüft die .NET-Laufzeit die CRL, um sicherzustellen, dass das Signaturzertifikat noch gültig ist. In einer getrennten Umgebung kann Ihr Computer nicht auf die CRL im Internet zugreifen. Das Standardtimeout für CRL-Prüfungen beträgt 15 Sekunden. Dies bedeutet, dass jedes Mal, wenn PowerShell ein signiertes Modul lädt, es bis zu 15 Sekunden dauern kann, bis ein Timeout auftritt.

Für dieses Problem gibt es drei mögliche Problemumgehungen:

  • Firewall- oder Proxyausnahme

    Durch das Zulassen des direkten Internetzugriffs für die CRL-Überprüfung wird das Problem verhindert. In einer Umgebung, in der Sie den Zugriff auf das Internet steuern können, können Sie Ihre Firewall oder Ihren Proxy konfigurieren, um den Zugriff auf die CRL-URLs zu ermöglichen. Dies ist die einfachste Lösung mit den geringsten Auswirkungen. Die Firewallprotokolle sollten die URL anzeigen, die PowerShell zu erreichen versuchte.

  • CRL-Timeout reduzieren

    Das Verringern der CRL-Nachschlagedauer ist möglich, jedoch besteht das Risiko, dass andere Abfragen fehlschlagen, die in der angegebenen Zeit nicht abgeschlossen werden können. Ausführliche Informationen zum Ändern des Timeouts finden Sie unter Verwalten der Netzwerkabruf- und Pfadüberprüfung.

  • CRL-Überprüfung entfernen

    Die CRL-Überprüfungseinstellungen werden von Gruppenrichtlinien verwaltet. Weitere Informationen finden Sie unter Verwalten vertrauenswürdiger Herausgeber.

    Warnung

    Es ist jedoch möglich, die CRL-Prüfung zu deaktivieren, es wird jedoch nicht empfohlen. Durch Deaktivieren der CRL-Überprüfung wird verhindert, dass Sie kompromittierte Zertifikate tatsächlich widerrufen.

FEHLER: Dieser Befehl kann nicht dot-gesourct werden, da er in einem anderen Sprachmodus definiert wurde.

PowerShell funktioniert mit Anwendungssteuerungssystemen wie AppLocker und Windows Defender Application Control (WDAC), indem sie automatisch im EingeschränktenLanguage-Modus ausgeführt wird. Der eingeschränkte Modus "Language" schränkt einige Features ein, die potenziell gefährlich sind. Es gibt jedoch Situationen, in denen Sie den FullLanguage-Modus benötigen, um bestimmte Befehle oder Features zu verwenden. Skripts können im Modus "FullLanguage " ausgeführt werden, wenn sie von der Richtlinie als vertrauenswürdig eingestuft werden. Die Vertrauensstellung kann über die Dateisignierung oder andere Richtlinienmechanismen angegeben werden, die in AppLocker oder WDAC konfiguriert sind.

Wenn Sie eine PowerShell-Sitzung starten, die unter Anwendungssteuerung verwaltet wird, wird die folgende Fehlermeldung angezeigt:

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.

Unter Anwendungssteuerung wird PowerShell im EingeschränktenSprach-Modus ausgeführt. Dieser Fehler tritt auf, wenn ihr Profilskript ausgenommen oder im Volllanguagemodusausgeführt werden soll. Wenn PowerShell im ConstrainedLanguage-Modus ausgeführt wird, kann es keinen Code aus Quellen ausführen, der im FullLanguage-Modus vertrauenswürdig ist.

Um das Problem zu beheben, müssen Sie die Ausnahme oder Signatur aus dem Profilskript entfernen. Wenn Sie Code benötigen, der während Ihres Profils im Volllanguagemodus ausgeführt werden muss, verschieben Sie ihn in eine andere Skriptdatei, die ausgenommen oder signiert ist. Rufen Sie diese Skriptdatei aus Ihrem Profil auf (keine Punktquelle).

Weitere Informationen zu diesem Problem finden Sie im PowerShell-Modus mit eingeschränkter Sprache und im Dot-Source-Operator.

Weiterführende Lektüre

  • Last updated on