Welche Windows-Fehlercodes bedeuten was – und wie ordnet man sie in Windows 10/11 systemisch ein?

Fehlerquellen und Ebenen in Windows: Kernel, Treiber, Dienste, Benutzer- und Anwendungskontext sowie Logging-Pfade

Windows 10 und Windows 11 melden Fehler nicht „aus einem Guss“, sondern entlang klar abgegrenzter Schichten. Jede Schicht nutzt eigene Statusmodelle, Protokollierungswege und Darstellungsformen: Im Kernel dominieren NTSTATUS-Rückgaben und Bugchecks, auf Win32-Ebene GetLastError() und Systemfehlermeldungen, in COM/.NET-Kontexten HRESULT, während Dienste, Treiber und sicherheitsrelevante Subsysteme Ereignisse im Windows Event Log mit spezifischen Quellen und Event-IDs schreiben. Für eine korrekte Einordnung entscheidet daher weniger der „Text“ einer Meldung als der Kontext: Prozess, Token, Session, Treiber-Stack, Transportprotokoll, Zeitquelle und Trust Chain.

Schichtmodell: Wo Fehler entstehen und wie sie nach oben „übersetzt“ werden

Im Kernel- und Treiberpfad entstehen Fehler häufig als NTSTATUS (z. B. STATUS_ACCESS_DENIED oder STATUS_IN_PAGE_ERROR). Sobald ein Kernel-API-Aufruf über den User-Mode-Übergang konsumiert wird, kann Windows diese Zustände in Win32-Fehlercodes (z. B. ERROR_ACCESS_DENIED bzw. 5) übersetzen. Bei COM, WMI, Windows Update, Store- und vielen Management-APIs wird derselbe Sachverhalt häufig als HRESULT repräsentiert, oft mit Facility-Angaben (z. B. 0x8007xxxx für Win32-Mapping oder 0x80070005 als Access Denied aus Win32).

Diese Übersetzung ist keine bloße Formalität: Bei I/O-Fehlern kann der ursprüngliche NTSTATUS weitere Ursacheninformation tragen (Stack, Paging, Storage-Stack), die im Win32-/HRESULT-Mapping verloren geht. Umgekehrt kann eine Anwendung zwar ERROR_LOGON_FAILURE oder 0x8009030C melden, während die primäre Ursache in Zeitabweichungen (Kerberos), Zertifikatsvalidierung (Schannel) oder Namensauflösung (DNS) liegt. Das „gleiche“ Symptom kann daher aus verschiedenen Ebenen gespeist werden.

Primärursache vs. Sekundärsymptom: typische Kaskaden über Ebenen hinweg

Windows koppelt Subsysteme eng: Netzwerk, Zeitdienst, Kryptografie, Identität, Update- und Policy-Infrastruktur hängen voneinander ab. Dadurch erscheinen primäre Störungen oft als „falsche“ Fehlermeldung in einer höheren Schicht. Ein klassisches Muster ist ein Authentifizierungsfehler in der UI, der tatsächlich aus einem TLS-Handshakefehler (Schannel) oder aus einer nicht erreichbaren Domänencontroller-Infrastruktur resultiert. Ebenso kann ein Profil-Ladefehler (User Profile Service) durch I/O-Fehler auf dem Systemlaufwerk oder durch gesperrte Registry-Hives ausgelöst werden, obwohl die Benutzeroberfläche nur eine generische Anmeldung- bzw. Profilmeldung anzeigt.

Für die Einordnung zählt daher die Kausalitätskette: Welche Komponente beobachtet den Fehler zuerst, welche nur die Folge? Ereigniszeiten, korrelierende Provider und die Richtung der Übersetzung (z. B. NTSTATUS → Win32 → HRESULT) sind meist aussagekräftiger als der sichtbare Code allein. Besonders bei Netzwerk-/Sicherheitsproblemen verschleiern Retries, Fallbacks (z. B. Kerberos → NTLM) und Policy-getriebene Blockaden (SmartScreen, WDAC, Defender) den Ursprung.

• Zeitdrift als Anmelde-/Ticketproblem: Kerberos kann bei zu großer Zeitabweichung scheitern; Symptome reichen von The security database on the server does not have a computer account for this workstation trust relationship bis zu Security-Events wie 4625 mit Substatus, während die Primärursache über w32time bzw. NTP/Domain Time entsteht.
• DNS/Erreichbarkeit als „Zertifikatsfehler“: Fehlende Namensauflösung oder Blockaden (Proxy, Firewall) führen zu TLS-Handshakeabbrüchen; Anwendungen melden oft nur 0x80072F8F oder SEC_E_UNTRUSTED_ROOT, während Schannel im Event Log detaillierter protokolliert.
• Storage/I/O als Profil- oder Updatefehler: Defekte Sektoren, Timeout im Storage-Stack oder Filtertreiber können STATUS_IN_PAGE_ERROR verursachen; in höheren Schichten erscheinen dann ERROR_READ_FAULT, Profil-Ladeabbrüche oder Update-Rollbacks.
• Treiberinstabilität als Anwendungsabsturz: Ein GPU-Reset (TDR) oder ein fehlerhafter Filtertreiber kann Benutzerprozesse beenden; sichtbar wird ein AppCrash in WER, die Primärspur liegt jedoch häufig in System-Events der Display-/Kernel-Power-/WHEA-Provider.

Logging-Pfade: Von ETW über Event Logs bis WER und Dump-Dateien

Windows protokolliert entlang mehrerer Kanäle, die unterschiedliche Detailgrade und Zielgruppen haben. Das klassische Windows Event Log (Kanäle System, Application, Security) basiert zunehmend auf ETW-Providern (Event Tracing for Windows), die zusätzlich in „Applications and Services Logs“ veröffentlichen. Viele sicherheits- und netzwerknahe Diagnosen liegen nicht im Application-Log, sondern in spezialisierten Kanälen, etwa für Schannel, GroupPolicy, SMBClient, WinRM, TaskScheduler oder Defender. Parallel erfasst Windows Error Reporting (WER) Abstürze und Hangs, und im Kernelpfad liefern Speicherdumps die niedrigste, aber präziseste Sicht auf Stopcodes und Treiberstacks.

Die operative Einordnung gelingt nur, wenn Logpfade sauber getrennt werden: UI-Dialoge und „Fehlercode in der App“ sind meist Endpunkte. Dagegen enthalten providerbasierte Logs häufig die primären Parameter (Status, Ziel, Handshake-Phase, Policy-Entscheidung). Bei Dienstproblemen ist zudem zu unterscheiden, ob der Dienst selbst einen Fehler zurückgibt oder ob der Service Control Manager den Start abbricht (Timeout, Abhängigkeit, Logon-Problem). Bei Treibern und PnP treten Setup- und Installationsfehler oft als Geräte-Manager-Status auf, während die eigentliche Kette in SetupAPI- und PnP-Events nachvollziehbar wird.

• Event Log (klassisch): Kernkanäle System, Application, Security; Abfrage z. B. mit Get-WinEvent -LogName System oder wevtutil qe System /c:50 /rd:true /f:text.
• Providerbasierte Kanäle: „Applications and Services Logs“ (ETW-Provider), z. B. Pfade unter Microsoft-Windows-*; zielgenaue Abfrage mit Get-WinEvent -LogName "Microsoft-Windows-Schannel/Operational" (falls aktiviert).
• Windows Error Reporting (WER): Benutzer- und Systemreports unter %LOCALAPPDATA%\Microsoft\Windows\WER\ sowie %PROGRAMDATA%\Microsoft\Windows\WER\; korreliert AppCrash/Hang mit Modulen und Ausnahme-Codes.
• Dump-/Crash-Artefakte: Kernel-/Minidumps typischerweise in %SystemRoot%\Minidump oder %SystemRoot%\MEMORY.DMP; relevante Ereignisse häufig via Kernel-Power und Bugcheck-Logging im System-Kanal.

Kontextgrenzen: Session, Token, Integrität, Container und Remote-Pfade

Viele Fehlklassifikationen entstehen, wenn Kontextgrenzen ignoriert werden. Ein identischer Win32-Code kann aus unterschiedlichen Identitäts- und Ausführungsmodellen stammen: Interaktive Session vs. Dienstsession (Session 0), lokales Konto vs. Domänenidentität, Standardtoken vs. elevierter Token (UAC), AppContainer/LowBox vs. klassischer Desktop-Prozess. Auch Remote-Zugriffe verändern die Fehleroberfläche: SMB liefert eigene NTSTATUS/SMB-Status, WinRM/HTTP transportiert Fehler in andere Codes, und RDP kann Grafik- oder Geräteumleitungen als lokale Geräteprobleme erscheinen lassen.

Für die systemische Einordnung ist deshalb zu klären, welche Ebene tatsächlich entscheidet: Blockiert eine Richtlinie (z. B. WDAC/AppLocker) den Prozessstart, scheitert eine COM-Aktivierung wegen DCOM-Rechten, verhindert ein Filtertreiber den Zugriff, oder liegt ein Kernelzustand vor, der Anwendungen nur indirekt trifft? Erst die Kombination aus Kontext (wer, wo, wie gestartet), Übersetzungsrichtung (welcher Code stammt von welcher Ebene) und Logging-Pfad (welcher Provider hat zuerst protokolliert) ergibt eine belastbare Fehlerzuordnung.

Codefamilien und Originalmeldungen korrekt lesen: Win32, NTSTATUS, HRESULT, klassische Systemmeldungen, Eventlog-Ereignisse und Bugcheck-Stopcodes

Windows-Client-Fehler erscheinen je nach Meldeschicht als numerische Codes, als zusammengesetzte Hexwerte oder als lokalisiertes Klartext-Dialogfeld. Die technische Einordnung beginnt mit der Codefamilie: Win32-Fehler (System Error Codes), NTSTATUS (Kernel- und I/O-Status), HRESULT (COM/.NET/Windows Runtime und viele APIs), Eventlog-Ereignisse (Provider, Event-ID, Keywords, Task) sowie Bugcheck-Stopcodes (Kernel-Fatals). Ohne diese Zuordnung entstehen schnell Fehlschlüsse, weil derselbe Sachverhalt in unterschiedlichen Schichten jeweils anders kodiert und anders „gerahmt“ wird.

Win32-Fehlercodes: System Error Codes und ihre typische Oberfläche

Win32-Fehlercodes sind die klassischen Rückgabewerte vieler Windows-APIs und erscheinen häufig als Dezimalzahlen oder als Hexwerte im Format 0x00000057. Sie stammen aus der Systemfehler-Tabelle (u. a. ERROR_*) und werden über GetLastError() bereitgestellt. In der Oberfläche treten sie oft als „Fehler 5: Zugriff verweigert“ (entspricht ERROR_ACCESS_DENIED (5)) oder „Das System kann die angegebene Datei nicht finden“ (ERROR_FILE_NOT_FOUND (2)) auf. Wichtig ist der Kontext: Ein Win32-Code kann ein Symptom eines tieferliegenden NTSTATUS sein, der an der Schnittstelle in Win32 übersetzt wurde (z. B. Dateisystem- oder Netzwerk-Redirector-Fehler).

Bei Win32 ist die Trennung zwischen Ursache und Symptom oft am „Call Site“ erkennbar: Ein Prozess meldet ERROR_BAD_NETPATH (53), obwohl primär DNS oder Routing fehlerhaft ist; ein Dienst startet nicht und liefert ERROR_SERVICE_SPECIFIC_ERROR (1066), während die eigentliche Ursache nur im Dienst-Log oder im Eventlog steht. Win32-Codes eignen sich daher gut zur Kategorisierung (Zugriff, Pfad, Netzwerk, Dienst), aber selten als alleinige Wurzelursache.

NTSTATUS: Kernel-Semantik, FACILITY_NTWIN32 und typische Übersetzungen

NTSTATUS-Codes stammen aus der NT-Kernelwelt (z. B. Speicherverwaltung, Security Reference Monitor, I/O-Manager, Dateisystemtreiber) und werden als 32-bit Hexwerte wie 0xC0000005 (Zugriffsverletzung) oder 0xC0000034 (Objektname nicht gefunden) dargestellt. Sie erscheinen in Crashdumps, im Kernel-Eventlog, in Treiberdiagnosen oder in Tools, die direkt NT-APIs verwenden. Viele NTSTATUS-Werte werden an User-Mode-Grenzen in Win32 oder HRESULT umgewandelt; dadurch kann derselbe primäre Kernelzustand in unterschiedlichen Oberflächen „anders“ aussehen.

Eine Sonderform ist FACILITY_NTWIN32 innerhalb von HRESULT: Hier wird ein Win32-Fehler in HRESULT-Verpackung transportiert. Der sichtbare Hexwert beginnt typischerweise mit 0x8007, wobei die unteren 16 Bits den Win32-Code enthalten (z. B. 0x80070005 entspricht Win32 5). Diese Form begegnet häufig bei Installer-, COM- und Updatepfaden, die intern Win32 nutzen, aber HRESULT zurückgeben.

HRESULT: Struktur, Schweregrad und häufige Fehlinterpretationen

HRESULT ist ein 32-bit Rückgabecode mit definierter Bitstruktur (Severity, Facility, Code). Er transportiert nicht nur „Fehler“, sondern auch Erfolg und Warnungen. Viele Windows-Subsysteme geben HRESULT zurück, obwohl intern Win32 oder NTSTATUS verwendet wird. Präzise Einordnung gelingt über Facility und Code: 0x80070005 deutet auf einen Win32-Zugriffsfehler hin, 0x80072EE7 ist ein WinINet/WinHTTP-naher Namensauflösungsfehler in HRESULT-Form, und 0x80004005 (E_FAIL) ist bewusst unspezifisch und zwingt zur Kontextanalyse (Provider-Log, Stack, Eventlog-Korrelation).

Ein häufiger Fehler besteht darin, HRESULTs ausschließlich als „Updatefehler“ oder „Appfehler“ zu lesen. Tatsächlich codieren sie oft sekundäre Symptome: Zeitabweichungen oder fehlende Vertrauenskette führen zu TLS-Fehlern, die wiederum als Download- oder Aktivierungsfehler erscheinen. In solchen Fällen ist der HRESULT korrekt, aber nicht die primäre Ursache. Eine belastbare Diagnose benötigt deshalb die Komponente, die den HRESULT emittiert (z. B. Update-Client, Store, WMI-Provider) und deren begleitende Ereignisse.

• Win32 aus HRESULT ableiten: 0x80070005 entspricht Win32 5 (ERROR_ACCESS_DENIED); typisch bei COM-Aktivierung, Dienstkonten, DCOM-Berechtigungen.
• Unspezifische HRESULTs richtig behandeln: 0x80004005 (E_FAIL) ist ohne Provider-Kontext nicht ursachenfähig; Korrelation über Event Viewer nach Provider/Task und zeitlicher Nähe ist zwingend.
• Netzwerk in HRESULT-Form: 0x80072EE7 deutet auf Namensauflösung hin; Abgleich mit ipconfig /all
Resolve-DnsName <host>
netsh winhttp show proxy

Klassische Systemmeldungen: Originalwortlaut, Lokalisierung und „Fehler X“

Klassische Systemmeldungen sind lokalisierte Texte, die aus Message-Tabellen von Systemkomponenten geladen werden. Der sichtbare Wortlaut kann sich je nach Sprache, Build und UI-Host unterscheiden, während der zugrunde liegende Code identisch bleibt. Deshalb ist die Originalquelle wichtiger als die Formulierung: Ein Explorer-Dialog kann denselben Win32-Code anders phrasiert darstellen als robocopy oder ein MSI-Log. Für die technische Einordnung zählt die Kombination aus Code, aufrufender Komponente (Prozess/Modul) und Objektkontext (Pfad, UNC, SID, Dienstname).

Bei Meldungen im Stil „Der Vorgang wurde erfolgreich beendet“ trotz Fehlerverhalten lohnt der Blick auf Warn- und Success-Codes: Nicht jeder nicht-null Rückgabewert ist ein Fehler, und manche Tools geben eigene Exitcodes aus, die nicht den Win32-Systemcodes entsprechen. Ein konsistenter Abgleich erfordert daher die jeweilige Dokumentation des Tools sowie die Beobachtung, ob Windows-intern tatsächlich ein Fehlerstatus propagiert wurde.

Eventlog: Event-ID, Provider, Kanal und die Bedeutung von „Keywords“

Eventlog-Einträge sind keine „Codefamilie“ im engen Sinn, sondern ein Metamodell: Der Provider definiert, wie eine Event-ID zu interpretieren ist, welche Felder (EventData/UserData) enthalten sind und ob ein eingebetteter Statuscode (Win32/NTSTATUS/HRESULT) vorliegt. Dieselbe Event-ID kann in verschiedenen Kanälen (z. B. System, Application, Microsoft-Windows-* unter „Applications and Services Logs“) auftauchen, mit abweichender Detailtiefe. „Level“ (Error/Warning/Information) ist nur eine Priorisierung; die technische Relevanz entsteht durch Provider, Task, Opcode und Keywords.

Systemische Fehldeutung entsteht häufig, wenn ein Event nur das Opfer protokolliert: Ein Anmeldefehler kann als Status: 0xC000006D erscheinen, obwohl die primäre Störung Kerberos/PKINIT, Zeitdrift, fehlende CRL-Erreichbarkeit oder ein defekter DC-Locator-Pfad ist. In solchen Fällen sind korrelierende Ereignisse aus Microsoft-Windows-Kerberos-Key-Distribution-Center, Microsoft-Windows-Schannel, Microsoft-Windows-Time-Service oder DNS-Client-Logs entscheidender als das „sichtbare“ Security-Event.

• Provider und Kanal identifizieren: Get-WinEvent -LogName "System" -MaxEvents 20 | Select-Object TimeCreated,ProviderName,Id,LevelDisplayName
• Statuscode aus Eventdaten extrahieren: Get-WinEvent -FilterHashtable @{LogName="System"; StartTime=(Get-Date).AddHours(-2)} | Select-Object -First 50 | Format-List *
• Gezielt nach Provider suchen: Get-WinEvent -ListLog * | Where-Object {$_.LogName -like "Microsoft-Windows-Schannel/*"}

Bugcheck-Stopcodes: Stopcode, Parameter und Treiberbezug

Bugcheck-Stopcodes sind Kernel-Fatalfehler, die den laufenden Betrieb abbrechen und einen Speicherabbild erzeugen. Der sichtbare Stopcode (z. B. IRQL_NOT_LESS_OR_EQUAL, PAGE_FAULT_IN_NONPAGED_AREA, DPC_WATCHDOG_VIOLATION) ist eine benannte Oberfläche; entscheidend sind Bugcheck-Code (numerisch) und die vier Parameter, die je nach Bugcheck-Typ unterschiedliche Bedeutung haben. In Windows 10 und Windows 11 wird der mutmaßlich beteiligte Treiber oft angezeigt, ist aber nicht automatisch die primäre Ursache: Ein Filtertreiber kann nur der Auslöser sein, während Speicherfehler, DMA-Probleme oder ein fehlerhafter Geräte-Firmwarezustand die eigentliche Ursache liefern.

Die korrekte Lesart verbindet Bugcheck-Daten (Code/Parameter), den Stack aus dem Dump und korrelierende Systemereignisse unmittelbar vor dem Absturz (z. B. WHEA-Hardwarefehler, Storport/NVMe-Resets, Display-Treiber-Resets). Stopcodes stehen damit am Ende einer Kausalkette; sie sind die zuverlässigste Aussage über „wo“ der Kernel gestorben ist, aber selten allein die Antwort auf „warum“.

Systemische Einordnung typischer Fehlerbilder: Anmeldung/Profil, Dateisystem und Storage, Treiber/Hardware, Berechtigungen/Sicherheit, Netzwerk/Authentifizierung und dienstbezogene Abbrüche

Typische Windows-Client-Störungen wirken an der Oberfläche oft eindeutig („Anmeldung fehlgeschlagen“, „Zugriff verweigert“, „Gerät kann nicht gestartet werden“), sind intern jedoch häufig Kaskaden aus Primärursache und Folgefehlern. Windows trennt Kernel-, Treiber-, Dienst-, Sicherheits- und Anwendungsebene strikt; Fehlercodes werden je nach Übergabepfad in andere Code-Familien übersetzt (z. B. NTSTATUS nach Win32 oder HRESULT). Für die Einordnung zählt daher weniger die sichtbare Meldung als die Komponente, die den Fehler ursprünglich erzeugt, und der Kontext, in dem er protokolliert wird (Kernel-Bugcheck, Event Log, API-Returncode, Geräte-Manager-Status).

Anmeldung und Benutzerprofil: LSA, Kerberos/NTLM, Profildienst und Zeit/Zertifikate

Anmeldefehler sind besonders häufig sekundäre Symptome. Die interaktive Anmeldung (Winlogon, Credential Provider) ruft LSA/SSPI auf; dort entstehen NTSTATUS-Codes, die als Win32-Meldung erscheinen. Bei Domänenkonten kommt Kerberos hinzu, bei lokalen Konten dominiert SAM/LSA mit NTLM. Ein scheinbar „falsches Kennwort“ kann tatsächlich von Zeitabweichungen, fehlenden Vertrauensstellungen, gesperrten Konten oder fehlgeschlagenen Pre-Authentication-Schritten herrühren. Profilprobleme entstehen nach erfolgreicher Authentifizierung, wenn der Profildienst (ProfSvc) den Benutzer-Hive nicht laden oder das Profil nicht erstellen kann; dann erscheinen Meldungen wie „Der Benutzerprofildienst konnte die Anmeldung nicht durchführen“ oder temporäre Profile.

• Kennwort/Anmeldezustand (LSA/LogonUI): STATUS_LOGON_FAILURE (0xC000006D) wird in der Oberfläche oft als „Benutzername oder Kennwort ist falsch“ dargestellt; häufig begleitet von Substatus STATUS_WRONG_PASSWORD (0xC000006A) oder STATUS_ACCOUNT_RESTRICTION (0xC000006E).
• Kontosperre/Deaktivierung: STATUS_ACCOUNT_LOCKED_OUT (0xC0000234) bzw. STATUS_ACCOUNT_DISABLED (0xC0000072); Win32-seitig typischerweise ERROR_ACCOUNT_LOCKED_OUT (1909) oder ERROR_ACCOUNT_DISABLED (1331) in Anwendungs-/Dienstlogs.
• Zeit/Realm (Kerberos): KRB_AP_ERR_SKEW äußert sich in Domänenumgebungen oft als generischer Anmeldefehler; Primärdiagnostik über Ereignisanzeige unter Applications and Services Logs\Microsoft\Windows\Kerberos sowie Zeitquelle über w32tm /query /status.
• Profilhive/NTUSER.DAT: STATUS_CANNOT_LOAD_REGISTRY_FILE (0xC0000218) kann als Profil- oder „Temporäres Profil“-Problem sichtbar werden; Ursache liegt häufig in I/O-Fehlern, Sperren durch Filtertreiber oder inkonsistenten Berechtigungen unter C:\Users\<Name>.
• Roaming/Netzwerkprofile: ERROR_BAD_NETPATH (53) oder ERROR_ACCESS_DENIED (5) beim Laden eines serverbasierten Profils führt sekundär zu Profilerstellungs- und Richtlinienproblemen; Primärursache liegt dann im Namensdienst, SMB oder in der Authentifizierung zum Dateiserver.

Dateisystem und Storage: NTFS/ReFS, Volumes, Filtertreiber und I/O-Pfade

Datei- und Storagefehler sind stark schichtabhängig: Anwendungen sehen Win32-Fehler wie ERROR_SHARING_VIOLATION (32) oder ERROR_DISK_FULL (112), während der Kernel über NTSTATUS (z. B. STATUS_IO_DEVICE_ERROR (0xC0000185)) arbeitet. Der Übergang erfolgt über I/O-Manager und Dateisystemtreiber; darunter wirken Storport/NTStor, Miniports und ggf. Verschlüsselung (fvevol.sys) oder Antimalware-/DLP-Filter. Folgefehler treten oft weit entfernt vom Ursprung auf: Ein sporadischer Datenträger-Timeout kann als Profilfehler, Datenbankkorruption oder „App reagiert nicht“ erscheinen, obwohl die Primärursache ein Storage-Reset ist.

Für die Trennung von Ursache und Symptom ist der Blick auf korrelierende Kernel-/Storport-/Disk-Ereignisse und die zeitliche Korrelation mit Anwendungsausfällen entscheidend. Ein „Datei beschädigt“ ist selten ein Dateisystemproblem allein; häufig ist es das erste sichtbare Ergebnis von Timeouts, fehlerhaften USB-Bridges, aggressiven Energiesparzuständen oder Filtertreibern, die I/O-Pfade verändern.

Treiber und Hardware: PnP, Geräte-Manager, Bugchecks und WHEA

Treiberfehler zeigen sich an drei Stellen: im Plug-and-Play-Status (Geräte-Manager), im Ereignisprotokoll (SetupAPI/Kernel-PnP) und im Extremfall als Bugcheck. Geräte-Manager-Codes sind keine NTSTATUS/Win32-Codes, sondern PnP-Konfigurationszustände, die häufig auf Treibersignatur, Ressourcen-/Firmwarezustand oder fehlende Startabhängigkeiten verweisen. Bluescreens (Bugcheck-Stopcodes) hingegen entstehen im Kernel, oft durch Speicherzugriffsverletzungen in Treibern oder durch Hardwarefehler, die über WHEA gemeldet werden.

• Geräte-Manager Code 10: „Dieses Gerät kann nicht gestartet werden.“ Typisch bei fehlerhaft initialisierenden Kernelmodustreibern oder Firmware-Inkompatibilität; Primärdaten liefern Ereignisse unter Microsoft-Windows-Kernel-PnP und der Treiberladepfad (C:\Windows\System32\drivers\).
• Geräte-Manager Code 28: „Für dieses Gerät sind keine Treiber installiert.“ Ursache ist PnP-Treiberzuordnung/INF-Fehlen; sekundär können Anmelde- oder Netzwerkprobleme auftreten, wenn NIC/Storage betroffen ist.
• Bugcheck 0x9F: DRIVER_POWER_STATE_FAILURE, häufig im Kontext von Standby/Modern Standby; Primärursache ist ein Treiber, der Power-IRPs nicht termingerecht verarbeitet.
• WHEA-Fehler: Hardwarefehler werden über Microsoft-Windows-WHEA-Logger protokolliert und können sekundär als zufällige Dateikorruption oder Treiberabstürze erscheinen; Einordnung erfordert die Unterscheidung zwischen korrigierten und nicht korrigierbaren Fehlern sowie die betroffene Komponente (CPU, PCIe, Speicher).

Berechtigungen und Sicherheit: Token, UAC, SRM, LSASS und Richtlinien

„Zugriff verweigert“ ist ein Sammelsymptom. Auf NT-Objektebene entscheidet der Sicherheitsreferenzmonitor anhand des Zugriffstokens (SIDs, Privilegien, Integritätslevel) und der DACL/SACL. Identische sichtbare Codes (ERROR_ACCESS_DENIED (5) oder HRESULT 0x80070005 (E_ACCESSDENIED)) können aus völlig unterschiedlichen Quellen stammen: fehlende Dateirechte, COM/DCOM-Launchberechtigungen, Dienstkonten ohne SeServiceLogonRight, AppContainer-Isolation oder Blockierungen durch Sicherheitsfeatures wie Windows Defender Application Control.

• Win32/HRESULT-Zugriffsfehler: ERROR_ACCESS_DENIED (5) und 0x80070005 treten in Datei-, Registry-, COM- und Dienstkontexten auf; die Primärkomponente variiert zwischen SRM (Objektzugriff) und COM-Sicherheitsmodell (Aktivierung/Identität).
• Besitz/Integritätslevel: STATUS_ACCESS_DENIED (0xC0000022) kann durch Mandatory Integrity Control (z. B. Low/Medium/High) ausgelöst werden, ohne dass die DACL „falsch“ ist; sichtbar oft als unerwartetes Scheitern beim Schreiben nach C:\Program Files oder HKLM.
• LSA- und Richtlinienfehler: „Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden“ korreliert häufig mit STATUS_TRUSTED_RELATIONSHIP_FAILURE (0xC000018B); Primärursache liegt in Computerkonto/Passwort, Domänenverfügbarkeit oder Zeit/Kerberos.

Netzwerk und Authentifizierung: DNS, NLA, TLS, Proxy und Mehrfachkontexte

Netzwerkfehler werden in Windows an unterschiedlichen Stellen „umetikettiert“: Winsock liefert Win32-Codes (z. B. WSAEHOSTUNREACH (10065)), HTTP-Stacks geben HRESULTs zurück, und Sicherheitsprotokolle (Schannel/Kerberos) erzeugen eigene Ereignisquellen. Dadurch wirken Ursachen oft unplausibel: Ein TLS-Validierungsproblem führt zu Updatefehlern, Proxy-Fehlkonfiguration zu Anmeldeauffälligkeiten bei Cloud-Identitäten, und DNS-Probleme zu „Netzwerkpfad nicht gefunden“ bei SMB. NLA (Network Location Awareness) beeinflusst außerdem Firewallprofile und damit nachgelagerte Verbindungen.

• Namensauflösung: ERROR_BAD_NET_NAME (67) oder ERROR_BAD_NETPATH (53) ist häufig sekundär; Primärursache liegt in DNS/NRPT oder im Erreichen des Zielhosts. Prüfpunkte sind Resolve-DnsName und ipconfig /displaydns.
• TLS/Schannel: Zertifikats- oder Kettenprobleme äußern sich als 0x80072F8F (Zeit/Zertifikat) oder 0x80072EFE (Verbindung unterbrochen) in Update-/Store-Szenarien; Primärdaten stehen in Schannel-Ereignissen und in der Zertifikatskette.
• Proxy/WinHTTP: Ein funktionierender Browser schließt WinHTTP-Probleme nicht aus; Dienste verwenden häufig WinHTTP-Konfiguration. Diagnose über netsh winhttp show proxy und Korrelation mit Dienstlogs.

Dienstbezogene Abbrüche: SCM, Dienstkonten, Abhängigkeiten und Timeout-Ketten

Der Service Control Manager (SCM) übersetzt viele Fehlersituationen in generische Dienstmeldungen. „Dienst wurde unerwartet beendet“ ist meist ein Symptom; der Primärfehler liegt im Dienstprozess (Unhandled Exception, fehlende DLL, Konfigurationsfehler) oder in Abhängigkeiten (RPC, Netzwerk, Storage). Besonders häufig sind Timeout-Ketten: Ein Dienst wartet auf Netzwerk oder Datenträger, überschreitet die Startzeit und wird vom SCM als Startfehler protokolliert. Die sichtbaren Win32-Codes sind dabei eindeutig, aber nicht hinreichend für die Ursachenbestimmung.

• Timeout beim Start: ERROR_SERVICE_REQUEST_TIMEOUT (1053) bedeutet nicht zwingend „Dienst hängt“; oft blockiert eine Abhängigkeit (z. B. DNS/AD, Storage, RPC). Korrelation über sc queryex <Dienstname> und Ereignisse unter System (Service Control Manager).
• Abhängigkeit ausgefallen: ERROR_SERVICE_DEPENDENCY_FAIL (1068) ist fast immer sekundär. Primärursache ist der nicht gestartete Abhängigkeitsdienst; dessen eigener Fehlercode ist maßgeblich.
• Dienstkonto/Anmelderechte: ERROR_SERVICE_LOGON_FAILED (1069) kann durch falsches Kennwort, abgelaufenes Konto, fehlendes Recht „Als Dienst anmelden“ oder Kerberos/Netzwerkprobleme entstehen; Einordnung erfordert die Trennung zwischen Authentifizierungsfehler und Richtlinien-/Rechteproblem.
• Absturz im Dienstprozess: Ereignisse aus Application Error oder Windows Error Reporting liefern Modul/Exception, während der SCM nur den Dienstabbruch meldet; typische Folgecodes sind 0xC0000005 (Access Violation) als Prozessstatus, nicht als SCM-Fehler.