Welche PowerShell-, WMF- und .NET-Fehlermeldung bedeutet was – und welche Komponente ist tatsächlich die Ursache?

Fehlerquellen und Zuständigkeiten: PowerShell-Engine, WMF/WinRM/WMI/CIM und .NET-Runtime im Zusammenspiel

Fehlermeldungen aus PowerShell-Umgebungen entstehen selten in einer einzelnen Schicht. Die sichtbare Meldung wird zwar von der aufrufenden Oberfläche (Konsole, Host, Remoting-Client, Scheduled Task) ausgegeben, ihre Ursache liegt jedoch häufig in einer darunterliegenden Laufzeit- oder Infrastrukturkomponente: PowerShell-Engine (Parser, Binder, Pipeline), Windows Management Framework (WMF) als Bereitstellungsschicht für Windows PowerShell, WinRM/WSMan als Transport für Remoting, WMI/CIM als Management-Provider sowie die .NET-Runtime (CLR) als Ausführungsumgebung für den Großteil des Codes. Für eine korrekte Zuordnung entscheidet weniger der Wortlaut als der Ursprung: Exception-Typ, FullyQualifiedErrorId, CategoryInfo, innere Exceptions und HRESULT- bzw. Win32-Codes.

Die gleiche Textzeile kann aus unterschiedlichen Pfaden stammen: Ein Remoting-Fehler kann als System.Management.Automation.Remoting.PSRemotingTransportException erscheinen, intern aber eine WSMan-Fehlernummer oder einen HTTP-Status kapseln; ein CIM-Fehler kann als Microsoft.Management.Infrastructure.CimException auftreten und wiederum ein DCOM- oder Provider-Problem transportieren. Deshalb muss stets geklärt werden, welche Komponente die Meldung erzeugt und welche Komponente nur „weiterreicht“.

Schichtenmodell: Wer erzeugt die Meldung, wer transportiert sie?

Die PowerShell-Engine erzeugt Fehler, wenn Parsing, Parameterbindung oder Pipelineausführung scheitern. Solche Fehler sind typischerweise script-level oder engine-level, auch wenn sie bei Cmdlets sichtbar werden. Cmdlet-Autoren können Fehler als Write-Error (nicht-terminierend) oder als Exception (terminierend) auslösen; daraus entstehen unterschiedliche ErrorRecords. Darüber liegen Host-spezifische Aspekte wie Ausgabecodierung, Interaktivität oder der Umgang mit $ErrorActionPreference, die das Erscheinungsbild beeinflussen, nicht aber die Ursache.

WMF (insbesondere für Windows PowerShell 5.1) liefert PowerShell selbst sowie Management- und Remoting-Komponenten. WinRM/WSMan ist dabei der Transport, der Authentifizierung, Verschlüsselung und Sessionverwaltung übernimmt. WMI und CIM sind Abstraktionen zur Abfrage von Managementdaten: klassisches WMI nutzt häufig DCOM/RPC, CIM in PowerShell bevorzugt WSMan, kann aber je nach Konfiguration und Cmdlet auch andere Pfade berühren. Die .NET-Runtime bildet schließlich die Basis: zahlreiche Fehler, die als PowerShell-Fehler erscheinen, sind in Wirklichkeit CLR-Exceptions, die nur in ErrorRecords verpackt wurden.

PowerShell-Engine: Parsing, Binding und Pipeline als Fehlergeneratoren

Engine-seitige Fehler entstehen oft deterministisch aus dem Skripttext oder dem aktuellen Session State. Parserfehler wie System.Management.Automation.ParseException treten vor jeder Ausführung auf; sie hängen nicht von Zielsystemen ab, sondern von Syntax, Tokenisierung und AST-Aufbau. Parameterbindungsfehler wie System.Management.Automation.ParameterBindingException entstehen nach dem Parsing, wenn die Engine Argumente in Parameterwerte konvertiert, Default Parameter Sets auflöst und Validierungsattribute ausführt. Das erklärt, warum dieselbe Cmdletzeile einmal funktioniert und einmal nicht: Der Unterschied kann in Culture-Einstellungen (Zahl-/Datumsformat), in geladenen Typkonvertern, in einem anderen $PSDefaultParameterValues oder in einem abweichenden Modulstand liegen.

Während der Pipelineausführung entstehen Fehler als ErrorRecords. Nicht-terminierende Fehler können nachgelagerte Pipelineelemente erreichen oder durch -ErrorAction Stop in terminierende Fehler umgewandelt werden. Zusätzlich kapselt die Engine viele Ausnahmen in System.Management.Automation.CmdletInvocationException, wodurch der sichtbare Exception-Typ nicht der ursprüngliche ist. Der relevante Ursprung steht dann in $_.Exception.InnerException oder in $_.Exception.ErrorRecord. Diese Kapselung führt dazu, dass identische Meldungen in interaktiver Ausführung anders wirken als in Jobs, Scheduled Tasks oder Remoting, weil der Host Fehler anders formatiert und weil Termination-Semantik je nach Kontext variiert.

• Syntax-/Parserfehler: System.Management.Automation.ParseException (typisch bei fehlenden Klammern, ungültigen Tokens); Quelle ist der Parser, nicht das Cmdlet.
• Parameterbindung: System.Management.Automation.ParameterBindingException oder Cannot process argument transformation on parameter; Ursache sind Binder, Typkonvertierung, Validierungsattribute oder Parameter-Set-Auflösung.
• Cmdlet-Kapselung: System.Management.Automation.CmdletInvocationException; die fachliche Ursache steht regelmäßig in $_.Exception.InnerException und ist häufig eine .NET-Exception oder ein Providerfehler.
• Provider-/Pfadfehler: Meldungen wie Cannot find path sind oft ItemNotFoundException, können aber im Remoting-Kontext auf ein anderes Dateisystem (Remote Session, anderes Laufwerks-Mapping) verweisen.

WMF/WinRM/WSMan: Remoting-Transport, Authentifizierung und Kontextverschiebung

Bei PowerShell-Remoting liegt die sichtbare Fehlermeldung häufig in einer PowerShell-Exception, die WSMan-Details transportiert. Typisch sind Ausnahmen wie System.Management.Automation.Remoting.PSRemotingTransportException mit Meldungen der Form The WinRM client cannot process the request. Ursache sind dabei oft erreichbarkeits- und vertrauensbezogene Faktoren (Dienststatus, Listener, Firewall, DNS, SPN/Kerberos, Zertifikatsvertrauen bei HTTPS) statt „PowerShell-Probleme“. Besonders fehlerträchtig ist die Kontextverschiebung: In einer Remote Session gelten andere Umgebungsvariablen, ein anderes Profil, andere Laufwerkszuordnungen und häufig andere Berechtigungsgrenzen (Double-Hop, Delegation). Identische Datei- oder Registry-Fehlertexte können dadurch auf fehlende Delegation statt auf fehlende Objekte hinweisen.

Auch die Fehlerbehandlung unterscheidet sich. Remote Errors werden serialisiert und als „deserialized“ Objekte zurückgegeben; dabei können Typinformationen fehlen oder vereinfacht werden. Die ursprüngliche Exception-Kette kann gekürzt sein, während WSMan-Fehlernummern und Transporthinweise erhalten bleiben. Für die Zuständigkeitszuordnung zählt daher, ob CategoryInfo Remoting-spezifisch ist, ob die Exception eine TransportMessage enthält und ob die Meldung auf WSMan/WinRM verweist.

WMI/CIM: Provider, Namespace und Zugriffskontrolle als Ursache hinter „Management“-Fehlern

WMI- und CIM-Fehler wirken oft wie Datenfehler, sind aber häufig Struktur- oder Berechtigungsprobleme. Bei WMI treten klassisch System.Management.ManagementException und COM-basierte Fehler auf; bei CIM/MI erscheinen Microsoft.Management.Infrastructure.CimException. Der entscheidende Unterschied liegt im Transport und im Provider-Stack: CIM-Cmdlets wie Get-CimInstance nutzen standardmäßig WSMan, während ältere WMI-Ansätze (oder lokale Aufrufe) andere Sicherheitskontexte und Protokolle berühren. Dasselbe Abfrageziel kann lokal funktionieren, remote jedoch scheitern, wenn der Provider remote nicht zugelassen ist, wenn DCOM/WSMan blockiert wird oder wenn Namespace-Berechtigungen fehlen.

Providerfehler werden außerdem häufig als generische „Invalid class“-, „Not found“- oder „Access denied“-Texte gemeldet, obwohl der eigentliche Fehler eine beschädigte Repository-Struktur, eine inkonsistente MOF-Registrierung oder ein deaktivierter Dienst ist. Für die Zuordnung ist wichtig, ob die Meldung auf root\cimv2, eine konkrete Klasse oder einen Provider verweist und ob ein COM/HRESULT oder MI-Errorcode enthalten ist. Diese Codes stammen nicht aus PowerShell, sondern aus der Management-Infrastruktur.

.NET-Runtime: Loader, Assemblies, HRESULTs und Sicherheitsgrenzen unter PowerShell

Die PowerShell-Engine läuft auf einer .NET-Runtime; unter Windows PowerShell 5.1 ist das die .NET Framework CLR, unter PowerShell 7+ die .NET (Core) Runtime. Zahlreiche Fehler sind deshalb CLR-Loader- und Bindingfehler, die als PowerShell-Fehler erscheinen. Klassisch sind System.IO.FileNotFoundException (Assembly oder native Abhängigkeit nicht gefunden), System.IO.FileLoadException (gefunden, aber nicht ladbar, etwa wegen Version, Signatur, Sperren), System.BadImageFormatException (Architektur/Format passt nicht) und System.TypeLoadException (Typ vorhanden erwartet, aber nicht auflösbar). In solchen Fällen ist die „zuständige“ Komponente der CLR Loader; PowerShell ist der Auslöser, nicht der Ursprung.

HRESULTs sind dabei das Bindeglied zwischen .NET, COM und Win32. Viele Exceptions tragen einen HResult, der tieferliegende Ursachen codiert, etwa Zugriffsprobleme oder COM-Aktivierungsfehler. Der sichtbare Text kann je nach Culture, Host oder Serialisierung variieren, der Code bleibt jedoch stabil. Gleichzeitig kann derselbe HRESULT in verschiedenen Kontexten entstehen: Ein E_ACCESSDENIED kann eine fehlende Dateiberechtigung, eine UAC-Token-Grenze, eine fehlende Remoting-Delegation oder eine restriktive DCOM-/WMI-Namespace-ACL bedeuten. Die Zuständigkeit ergibt sich erst aus Stacktrace, InnerException und dem betroffenen Ressourcenpfad.

• Modul-/Assembly-Binding: Fehlerbilder mit System.IO.FileNotFoundException oder Textteilen wie Could not load file or assembly deuten auf CLR-Assemblyauflösung; typische Auslöser sind fehlende Abhängigkeiten im Modulpfad ($env:PSModulePath) oder falsche Runtime-Zielplattform (Windows PowerShell vs. PowerShell 7).
• Native Abhängigkeiten: System.DllNotFoundException oder BadImageFormatException verweisen häufig auf fehlende VC++-Runtime, falsche Bitness (x86/x64/ARM64) oder nicht auffindbare DLLs im Suchpfad des Prozesses.
• HRESULT-Weitergabe: COM-/Win32-nahe Fehler werden in .NET häufig als System.Runtime.InteropServices.COMException oder Win32Exception sichtbar; die technische Ursache steht im HRESULT bzw. im nativen Fehlercode, nicht in der PowerShell-Oberfläche.
• Sicherheitsgrenzen: System.UnauthorizedAccessException und System.Security.SecurityException können identische Texte tragen, aber unterschiedliche Zuständigkeiten haben (Dateisystem-ACL, Token/UAC, Remoting-Kontext, AppLocker/WDAC-Blockade).

Das Zusammenspiel der Schichten entscheidet letztlich über die Diagnose: PowerShell formt ErrorRecords, WMF-Komponenten transportieren und kontextualisieren (Remoting, Management), und die .NET-Runtime liefert die konkrete technische Ausnahme samt Codes. Nur wenn die Meldung einer Schicht zugeordnet wird, lässt sich der „Fehler“ als Symptom eines Systemzustands erkennen: falsche Ausführungsumgebung, inkonsistente Abhängigkeiten, restriktive Sicherheitskonfiguration oder ein Infrastrukturdefekt.

PowerShell-Fehlermeldungen präzise zuordnen: Parser-/Binderfehler, Cmdlet-Fehler, Remoting, Module, Richtlinien und Berechtigungen

PowerShell erzeugt Fehlermeldungen aus mehreren Schichten: dem Parser (Syntax), dem Binder (Namens- und Typauflösung), der Engine (Pipeline und Invocation), dem Cmdlet-/Provider-Layer sowie optionalen Transport- und Sicherheitskomponenten (Remoting, WinRM, WSMan, Kerberos/NTLM). Der identische Wortlaut kann je nach Host (Konsole, ISE, VS Code, Scheduled Task, Dienstkonto) und je nach Runspace-Konfiguration (ExecutionPolicy-Scope, Constrained Language Mode, Profilskripte, Modulpfade) unterschiedliche Ursachen haben. Für eine belastbare Zuordnung muss klar sein, ob ein Fehler vor der Ausführung (Parsing/Binden), während der Pipeline-Ausführung (nicht terminierend/terminierend), oder außerhalb des Runspaces (Transport/Authentifizierung/Policy) entsteht.

Parser- und Binderfehler: Syntax, Tokens, Parameterbindung und Typkonvertierung

Parserfehler entstehen, bevor ein Command überhaupt aufgelöst wird. Typische Meldungen beginnen mit ParserError und treten auch dann auf, wenn ein Skript nie in die Ausführung gelangt (etwa beim Laden eines Profils). Binderfehler dagegen entstehen, wenn PowerShell einen Befehlsnamen, Parameter oder Argumenttypen nicht eindeutig zuordnen kann. Das ist keine reine „Cmdlet-Fehlfunktion“, sondern Ergebnis der Command-Discovery (Alias, Funktion, Cmdlet, Script, Anwendung) und der Parameterbindung (ByName/ByPosition, PipelineBinding, ArgumentTransformationAttributes).

• Syntaxfehler (Parser): ParserError: Unexpected token '…' in expression or statement. — Tokenisierung/AST-Bildung scheitert, häufig durch nicht geschlossene Klammern/Strings oder falsch platzierte Scriptblocks.
• Unvollständige Konstrukte (Parser): ParserError: Missing closing '}' in statement block or type definition. — Blockstruktur im AST bleibt offen; Ursache oft in verschachtelten if/try/class-Blöcken.
• Befehl nicht gefunden (Binder/Discovery): The term 'X' is not recognized as the name of a cmdlet, function, script file, or operable program. — Discovery findet keinen passenden Command; in Remote-Sitzungen zusätzlich möglich bei fehlendem Modul auf dem Ziel oder abweichendem $env:PATH/$env:PSModulePath.
• Mehrdeutige Parameter (Binder): ParameterBindingException: A parameter cannot be found that matches parameter name '…'. oder ParameterBindingException: Parameter set cannot be resolved using the specified named parameters. — Parametername existiert nicht oder Parameter-Sets kollidieren; Kontext ist das Cmdlet-Metadatenmodell (ParameterAttribute/ParameterSetName).
• Typkonvertierung (Binder): Cannot convert value "…" to type "System.Int32". Error: "Input string was not in a correct format." — Conversion via ETS/.NET TypeConverter scheitert; identischer Text kann je nach Kulturinfo ([cultureinfo]::CurrentCulture) durch Dezimaltrennzeichen ausgelöst werden.

Cmdlet-Fehler: nicht terminierend vs. terminierend, ErrorRecord und Kategorien

Cmdlets berichten Fehler über ErrorRecord-Objekte. Nicht terminierende Fehler werden über Write-Error ausgegeben und lassen die Pipeline fortlaufen; terminierende Fehler (Exceptions oder ThrowTerminatingError) unterbrechen den aktuellen Ausführungspfad und lassen sich mit try/catch abfangen. Ob ein Fehler terminierend wirkt, hängt außerdem von -ErrorAction, $ErrorActionPreference und spezifischen Cmdlet-Implementierungen ab. Deshalb ist derselbe Fehlertext im Output nicht gleichbedeutend mit identischem Kontrollfluss.

Für die eindeutige Zuordnung sind die Metadaten wichtiger als der sichtbare Text: $Error[0].FullyQualifiedErrorId, $Error[0].CategoryInfo und $Error[0].Exception.GetType().FullName verankern den Fehler in Engine, Cmdlet oder .NET-Layer. Remoting und Hintergrundjobs serialisieren ErrorRecords; dabei kann der Exception-Typ auf der Empfängerseite als „RemoteException“ erscheinen, während die Originaldetails im Property SerializedRemoteException bzw. in den ErrorDetails stecken.

Remoting-Fehler: WSMan/WinRM, Authentifizierung, Delegation und Sitzungszustand

PowerShell-Remoting über New-PSSession/Invoke-Command basiert (Windows PowerShell und PowerShell 7 unter Windows) typischerweise auf WSMan/WinRM. Fehlermeldungen wirken oft „netzwerkartig“, sind aber häufig Ausdruck lokaler Richtlinien, fehlender Listener, Authentifizierungsrestriktionen oder SPN/Delegationsproblemen. Der exakte Wortlaut enthält meist eine WSMan-Fehler-ID, die der Transportkomponente zugeordnet ist, nicht dem aufgerufenen Cmdlet.

• WinRM nicht erreichbar/konfiguriert: WinRM cannot process the request. — WSMan-Client erhält keine gültige Antwort; Ursachen sind deaktivierter WinRM-Dienst, fehlender Listener (winrm enumerate winrm/config/listener) oder blockierte Firewallregel (Enable-PSRemoting -Force setzt Standardkonfiguration, scheitert aber ohne administrative Rechte).
• TrustedHosts/HTTP ohne Kerberos: The WinRM client cannot process the request. If the authentication scheme is different from Kerberos, or if the client computer is not joined to a domain, then HTTPS transport must be used or the destination machine must be added to the TrustedHosts configuration setting. — Transportpolicy des WSMan-Clients; typischer Kontext: Workgroup, IP-Adresse statt Hostname, oder Cross-Domain ohne Vertrauensstellung.
• Doppelte Hop-/Delegationsgrenze: Access is denied. oder The server has rejected the client credentials. bei Zugriff auf dritte Systeme aus einer Session — Kerberos-Delegation/CredSSP/Resource-Based Constrained Delegation; Ursache liegt in Authentifizierungsfluss, nicht im Zielcmdlet.
• Session Capability/Endpoint: The syntax is not supported by this runspace. oder This command cannot be run due to the error: … — Einschränkungen durch JEA-Endpunkte, LanguageMode oder Endpoint-Konfiguration; sichtbar als Remoting-Fehler, technisch aber SessionConfiguration/AuthorizationManager.

Module, Autoloading und Abhängigkeiten: PSModulePath, Signaturen und Assembly-Ladevorgänge

Fehler im Modulkontext werden oft fälschlich als „Cmdlet nicht vorhanden“ interpretiert. PowerShell lädt Module automatisch, wenn ein Command aufgelöst wird, sofern Autoloading aktiv ist. Damit sind Modulpfade, Side-by-Side-Installationen und Abhängigkeiten (NestedModules, RequiredAssemblies, RequiredModules) unmittelbare Fehlerursachen. In restriktiven Umgebungen kommen Signatur- und Katalogprüfungen hinzu, die wie Laufzeitfehler wirken, technisch aber aus dem Policy- bzw. Security-Layer stammen.

• Modul nicht gefunden: Import-Module : The specified module 'X' was not loaded because no valid module file was found in any module directory. — Discovery scheitert entlang $env:PSModulePath; in 32/64-Bit-Kontexten und in Remoting-Sessions kann der Pfad abweichen.
• Abhängige Assembly fehlt: Could not load file or assembly 'X, Version=…' or one of its dependencies. The system cannot find the file specified. — .NET-Assembly-Load innerhalb des Moduls; Ursache sind fehlende DLLs, falsche Architektur (x86/x64/ARM64) oder Load-Context-Konflikte bei gemischten PowerShell-/Runtime-Versionen.
• Modul geladen, Typ nicht verfügbar: Unable to find type [X]. — TypeResolver findet die Klasse nicht; häufig, weil das Modul zwar importiert, aber die Assembly nicht geladen wurde oder der Typ in einem anderen Namespace liegt.
• Signatur/Publisher blockiert: File … cannot be loaded because running scripts is disabled on this system. oder … is not digitally signed. You cannot run this script on the current system. — ExecutionPolicy/Authenticode-Entscheid, oft getriggert durch Zone.Identifier (Mark-of-the-Web) bei Dateien aus dem Internet.

Richtlinien und Berechtigungen: ExecutionPolicy, Language Mode, UAC und Dateisystem/Registry

Richtlinienmeldungen werden häufig als „PowerShell blockiert“ zusammengefasst, obwohl mehrere Mechanismen wirken: ExecutionPolicy (Client-seitige Skriptausführungsregeln), Application Control (z. B. WDAC/AppLocker), sowie Constrained Language Mode über Device Guard/UMCI. Daneben erzeugen Berechtigungsprobleme klassische Ausnahmen aus .NET und Win32, die von Cmdlets lediglich weitergereicht werden. Der Ausführungskontext entscheidet: Ein erhöht gestarteter Host besitzt ein anderes Zugriffstoken als ein nicht erhöhter, ein Scheduled Task kann ohne Benutzerprofil laufen, und Remoting verwendet ein separates Logon-Szenario.

• ExecutionPolicy-Blockade: … cannot be loaded because running scripts is disabled on this system. — ausgelöst beim Laden von .ps1/.psm1/.psd1; Diagnose über Get-ExecutionPolicy -List und Scope-Priorität (MachinePolicy/UserPolicy > Process > CurrentUser > LocalMachine).
• UAC/Token-Rechte: Requested registry access is not allowed. — meist .NET SecurityException/UnauthorizedAccessException beim Zugriff auf geschützte Schlüssel; Kontextwechsel zwischen administrativem Mitgliedschaftstoken und erhöhtem Token ist entscheidend.
• Constrained Language Mode: Method invocation is supported only on core types in this language mode. — PowerShell-Sprachmodus beschränkt .NET-Aufrufe; Ursache ist typischerweise eine Application-Control-Policy, nicht ein Skriptfehler.
• Datei „in Benutzung“: The process cannot access the file '…' because it is being used by another process. — Win32-Sharing-Violation, häufig bei Logfiles, MSI-Operations oder AV-Scanner; erscheint in PowerShell als IOException-Text, kann aber aus unterschiedlichen Cmdlets stammen (Remove-Item, Set-Content, Move-Item).

.NET-Exceptions und Codes in PowerShell-Kontexten: typische Exception-Typen, HRESULT/Win32-Codes, Loader- und Abhängigkeitsfehler

PowerShell läuft auf einer .NET-Runtime und setzt für nahezu alle nichttrivialen Operationen auf Managed Code: Cmdlets instanziieren .NET-Typen, Parameterbindung nutzt Reflection, Pipeline-Objekte sind .NET-Instanzen, und viele Fehler entstehen als .NET-Exceptions, bevor PowerShell sie in ein ErrorRecord-Objekt überführt. Dabei bleibt der ursprüngliche .NET-Typ häufig erhalten (z. B. System.UnauthorizedAccessException), wird aber je nach Fehlerquelle als terminierender oder nicht terminierender Fehler ausgegeben. Zusätzlich tauchen native Fehlerdomänen auf: HRESULT-Werte aus COM/WinRT, Win32-Fehlercodes aus dem Kernel oder dem Service Control Manager sowie Loader-Statuscodes aus dem PE- und Assembly-Ladeprozess.

Wie .NET-Exceptions in PowerShell sichtbar werden

In PowerShell werden Ausnahmen in der Regel als System.Management.Automation.RuntimeException oder spezifischer als CmdletInvocationException „umhüllt“. Das umschließende Objekt enthält unter $_ bzw. $PSItem die Felder Exception, FullyQualifiedErrorId, CategoryInfo und ErrorDetails. Die eigentliche Ursache steckt oft in $_.Exception.InnerException oder tiefer in einer Kette von InnerExceptions, insbesondere bei Reflection- und Loader-Problemen.

Dass identische Fehltexte unterschiedliche Ursachen haben, liegt am Kontext: Ein Cmdlet kann dieselbe .NET-Exception auslösen wie ein Skriptblock, aber ein anderes Fehlerverhalten zeigen (terminierend vs. nicht terminierend). Ebenso kann Remoting die Exception serialisieren; der Empfänger sieht dann häufig eine System.Management.Automation.RemoteException mit Text der Originalausnahme, während Stacktraces, Typinformationen oder HResults gekürzt oder als SerializedRemoteException abstrahiert werden.

Typische .NET-Exception-Typen im PowerShell-Alltag und ihre technische Bedeutung

Viele Fehler lassen sich stabil über den Exception-Typ einordnen, weil er direkt die verantwortliche Subsystemschicht reflektiert: IO-Stack (System.IO), Security/ACL (System.UnauthorizedAccessException), Reflection/Loader (System.Reflection, System.Runtime.Loader) oder Netzwerk/Remoting (System.Net). Der sichtbare Text ist dagegen oft nur eine Oberfläche; entscheidend sind zusätzliche Eigenschaften wie HResult, FusionLog (falls aktiviert) oder LoaderExceptions bei ReflectionTypeLoadException.

• Zugriff/ACL: System.UnauthorizedAccessException („Zugriff verweigert.“) entsteht bei fehlenden NTFS-/Registry-Rechten, UAC-Token-Einschränkungen oder Policy-bedingten Blockaden; in PowerShell häufig zusammen mit CategoryInfo : PermissionDenied und einem HResult, der auf 0x80070005 (E_ACCESSDENIED) bzw. Win32 5 verweist.
• Datei/Verzeichnis: System.IO.FileNotFoundException („Die Datei … wurde nicht gefunden.“) und System.IO.DirectoryNotFoundException signalisieren fehlende Pfade, aber auch falsche Working-Directory-Annahmen im Hostprozess; relevante Diagnose liefern $_.Exception.FileName und bei Loaderfehlern eher System.IO.FileLoadException („Die Datei oder Assembly … konnte nicht geladen werden.“).
• Typ-/Assembly-Laden: System.TypeLoadException („Der Typ … konnte nicht geladen werden.“) und System.MissingMethodException („Methode nicht gefunden: …“) deuten auf Versionskonflikte hin, etwa wenn ein Modul gegen eine andere Assembly-Version gebaut wurde; häufig tritt dies nach Updates auf, wenn mehrere Kopien derselben DLL im Suchpfad liegen.
• Reflection-Sammelfehler: System.Reflection.ReflectionTypeLoadException („Mindestens ein Typ in der Assembly konnte nicht geladen werden.“) sammelt mehrere Loaderfehler; die eigentlichen Ursachen stehen in $_.Exception.LoaderExceptions und sind oft Mischungen aus FileNotFoundException, FileLoadException und BadImageFormatException.
• Plattform/Bitness: System.BadImageFormatException („… ist keine gültige Win32-Anwendung.“) entsteht bei 32/64-Bit-Mismatch, falschem Ziel-Framework oder nativen Abhängigkeiten, die nicht zur Prozessarchitektur passen; im PowerShell-Kontext besonders relevant, wenn powershell.exe (Windows PowerShell, ggf. 32-bit) und pwsh.exe (PowerShell 7+, 64-bit) parallel existieren.
• Netzwerk/TLS: System.Net.WebException sowie System.Security.Authentication.AuthenticationException treten bei Proxys, Zertifikatsproblemen oder TLS-Aushandlung auf; in PowerShell erscheinen sie oft hinter Cmdlets wie Invoke-RestMethod oder beim Moduldownload, wobei zusätzliche Informationen in $_.Exception.Status und $_.Exception.InnerException stecken.

HRESULT- und Win32-Codes: Mapping, Lesbarkeit und typische Codes

Viele .NET-Exceptions tragen einen HResult-Wert, der die Fehlerdomäne präzisiert. Häufig handelt es sich um einen „verpackten“ Win32-Code: 0x80070000 | Win32Code. Beispiel: Win32 5 (Access is denied) entspricht oft HRESULT 0x80070005. COM-Fehler erscheinen typischerweise als System.Runtime.InteropServices.COMException mit HRESULT, bei WinRT zusätzlich als System.Exception-Varianten aus der Windows Runtime Projection.

Die gleiche HRESULT-Zahl kann je nach aufrufender Schicht unterschiedliche Ursachen haben. 0x80070005 kann etwa aus dem Dateisystem kommen, aus DCOM-Konfiguration, aus dem Zertifikatspeicher oder aus einem API-Aufruf, der intern Rechteprüfung für einen anderen Ressourcenpfad durchführt. Deshalb ist die Kombination aus Exception-Typ, HResult und Kontext (welche API, welches Cmdlet, welcher Prozess-Token) entscheidend.

Loader- und Abhängigkeitsfehler: Assembly Load Context, Native DLLs, Modulgrenzen

Abhängigkeitsfehler entstehen im PowerShell-Kontext auf mindestens drei Ebenen: (1) PowerShell-Modulauflösung (Import-Module, Modulmanifest, RequiredModules), (2) Managed Assembly Load (CLR-Loader, Assembly Load Context), (3) native Abhängigkeiten (Windows Loader, LoadLibrary). In Windows PowerShell (auf .NET Framework) und PowerShell 7+ (auf .NET) unterscheiden sich die Lade- und Isolationsmechanismen; zugleich verschiebt sich die Fehleroberfläche: Ein fehlendes natives DLL-Dependency kann als FileNotFoundException auf eine Managed DLL erscheinen, obwohl die Datei vorhanden ist, weil erst eine transitive native Abhängigkeit scheitert.

• Manifest-/Modulabhängigkeiten: Fehler wie „Das angegebene Modul ‚X‘ wurde nicht geladen, da kein gültiges Moduldatei gefunden wurde“ entstehen auf PowerShell-Ebene; Prüfung über Get-Module -ListAvailable
$env:PSModulePath -split ';' und Auflösung des Modulwurzelpfads (Version-Unterordner, .psd1, RootModule).
• Managed Assembly nicht gefunden: System.IO.FileNotFoundException beim Laden einer Assembly trotz existierender Datei deutet häufig auf eine fehlende transitive Abhängigkeit oder falschen Load-Kontext; Diagnose über Add-Type -Path C:\Pfad\Lib.dll (liefert oft präzisere Loaderdetails) und Auflösen der InnerExceptions.
• Assembly vorhanden, aber blockiert oder inkompatibel: System.IO.FileLoadException tritt u. a. bei Signatur-/Policy-Sperren, gesperrten Dateien oder Binding-Konflikten auf; relevante Indikatoren sind $_.Exception.HResult und bei Windows-Downloads ein vorhandenes Zone-Tag (MOTW), entfernbar über Unblock-File -Path C:\Pfad\Lib.dll.
• Native Abhängigkeit fehlt: System.DllNotFoundException („Unable to load DLL ‚X‘: …“) oder BadImageFormatException bei P/Invoke zeigt Probleme im nativen Suchpfad, fehlende VC++-Runtime oder Architektur-Mismatch; Kontextprüfung über [Environment]::Is64BitProcess
$env:PATH und die Bitness des Hosts (pwsh.exe vs. powershell.exe).
• Typinitialisierung und Side Effects: System.TypeInitializationException („Der Typeninitialisierer … hat eine Ausnahme verursacht.“) verdeckt häufig IO/Registry/Interop-Fehler im statischen Konstruktor; die Ursache steht fast immer in $_.Exception.InnerException, nicht in der äußeren Meldung.

Bei Versionskonflikten ist die Fehlinterpretation besonders verbreitet: „Methode nicht gefunden“ kann eine echte API-Inkompatibilität sein, aber ebenso ein Indiz dafür, dass eine andere Assembly-Version aus einem unerwarteten Pfad geladen wurde. In PowerShell treten solche Situationen häufig auf, wenn Module eigene bin-Verzeichnisse mitbringen und mehrere Module denselben Abhängigkeitsnamen enthalten. Dann entscheidet der Load-Kontext beziehungsweise die Reihenfolge der ersten Bindung, welche DLL im Prozess „gewinnt“.

Diagnose im PowerShell-Kontext: reproduzierbar, komponentenbezogen, ohne Fehlinterpretationen

Eine belastbare Analyse folgt der Kette: PowerShell-Wrapper → .NET-Exception-Typ → InnerException → Code (HResult/Win32) → verantwortliche Komponente (Modulauflösung, CLR-Loader, Windows Loader, COM). Die Meldung allein ist selten stabil, da sie lokalisiert sein kann und sich je nach Host (Konsole, ISE, VS Code, Task Scheduler, Dienstkonto, Remoting) ändert. Aussagen zur Ursache sollten sich daher auf Typ, Code und Kontextparameter stützen: Prozessarchitektur, Token/Rechte, Suchpfade und geladene Module/Assemblies.

• ErrorRecord zerlegen: $e = $_
$e.Exception.GetType().FullName
$e.Exception.HResult
$e.Exception.InnerException zur Trennung von PowerShell-Hülle und .NET-Ursache.
• Loader-Sammelfehler auswerten: $e.Exception.LoaderExceptions | ForEach-Object { $_.GetType().FullName + ': ' + $_.Message } bei System.Reflection.ReflectionTypeLoadException, um jede einzelne fehlende Abhängigkeit sichtbar zu machen.
• Kontextparameter festhalten: $PSVersionTable
[Environment]::Version
[Environment]::Is64BitProcess
whoami /groups zur Einordnung, ob ein Fehler durch Runtime-/Host-Unterschiede, Bitness oder Berechtigungen getrieben ist.