Windows 11 Fehlerdiagnose: Welche Ereignis-IDs und Logpfade passen zu welchem Symptom?

Grundlagen der Beweissicherung: Zeitkorrelation, Logquellen in Windows 11 und typische Fallstricke

Fehlerdiagnose in Windows 11 wird belastbar, wenn Symptome zeitlich und technisch mit Spuren in Logs, Statusabfragen und Konfigurationsständen korreliert werden. Einzelne Ereignisse reichen selten aus; erst die Kette aus Auslöser, Folgefehlern und Nebenwirkungen ergibt ein stimmiges Bild. Für eine saubere Beweissicherung zählt daher weniger „wo hat es geklemmt“, sondern „welches Subsystem hat wann was gemeldet, und welche Messpunkte bestätigen das“.

Zeitkorrelation: Uhren, Zeitzonen und Ereignisreihenfolgen

Die häufigste Ursache für Fehlschlüsse ist eine fehlerhafte Zeitachse. Windows protokolliert Ereignisse mit Zeitstempeln, die in der Ereignisanzeige typischerweise in lokaler Zeit dargestellt werden; je nach Tool/Export können aber UTC-Darstellungen oder abweichende Formate auftauchen. Hinzu kommen Sprünge durch Zeitdienst-Korrekturen, Standby/Resume und Dual-Boot-Szenarien, bei denen die Hardwareuhr anders interpretiert wird. Bei der Korrelation ist deshalb zu klären, ob die Zeitstempel tatsächlich vergleichbar sind und ob ein Ereignis „vor“ einem anderen lag oder nur so angezeigt wird.

Besonders relevant sind Boot- und Resume-Grenzen: Nach einem Neustart beginnen viele Zähler neu, Treiber initialisieren erneut, und Dienste melden „Start“ in enger Folge. Bei modernem Standby oder Schnellstart (Hybrid Boot) entstehen zudem Brüche in der Timeline, weil nicht alle Komponenten einen klassischen Shutdown/Startup durchlaufen. Eine belastbare Timeline setzt daher mindestens einen festen Ankerpunkt pro Abschnitt: Boot-Zeit, Sleep/Wake-Zeit oder eine eindeutig erkennbare Änderung im Systemzustand.

• Systemzeit und Zeitzone prüfen: Get-Date
Get-TimeZone
tzutil /g
• Zeitdienst-Status und letzte Synchronisation: w32tm /query /status
w32tm /query /configuration
sc query w32time
• Boot-/Wake-Ankerpunkte aus Ereignisprotokoll: Get-WinEvent -FilterHashtable @{LogName="System"; Id=6005,6006,12,13,1,42,1074,1076} -MaxEvents 200 | Select TimeCreated,Id,ProviderName,Message
• Ursache „Zeit sprang“ erkennbar machen: Get-WinEvent -FilterHashtable @{LogName="System"; ProviderName="Microsoft-Windows-Time-Service"} -MaxEvents 200 | Select TimeCreated,Id,Message

Logquellen in Windows 11: Kanäle, Provider, Dateien und Persistenz

Windows 11 verteilt Diagnoseartefakte auf mehrere Ebenen: klassische Windows-Ereignisprotokolle (EVTX), anwendungsspezifische Kanäle unter „Applications and Services Logs“, textbasierte Logs (z. B. CBS/DISM), ETW-Traces sowie Crashdumps und WER-Berichte. Für die Beweissicherung ist entscheidend, welche Quelle für welche Frage taugt: Ein Dienstfehler zeigt sich häufig im System-Log, während die eigentliche Ursache im zugehörigen „Operational“-Kanal des Providers liegt.

EVTX-Dateien liegen unter C:\Windows\System32\winevt\Logs\ und werden ringförmig geschrieben; bei hoher Ereignisrate gehen ältere Einträge verloren, wenn Größe und Aufbewahrung nicht angepasst sind. Viele Admin-Werkzeuge filtern zudem standardmäßig, was zu scheinbar „leeren“ Logs führt. Eine weitere Hürde: Einige Kanäle sind nicht aktiv oder protokollieren erst nach dem Aktivieren von Operational/Analytic/Debug-Kanälen. Analytic/Debug sind oft deaktiviert und können viel Daten erzeugen; ein planvolles, zeitlich begrenztes Aktivieren ist sinnvoller als permanentes Mitschneiden.

Für die Mastertabellen ist es hilfreich, pro Symptom mindestens zwei Klassen von Evidenz zu verknüpfen: ein Ereignis mit Event-ID und Provider (für die Suchbarkeit) sowie den konkreten Logpfad (für Export/Archivierung). So wird nachvollziehbar, ob ein „Update hängt“ durch Servicing-Fehler, Netzwerkabbrüche, Richtlinien oder beschädigte Komponenten ausgelöst wurde.

Erhebung und Export: reproduzierbar, minimalinvasiv, revisionsfest

Beweissicherung konkurriert häufig mit Betriebsanforderungen: Das System soll weiterlaufen, die Diagnose darf keine zusätzlichen Störungen erzeugen, und dennoch müssen Spuren unverändert bleiben. Bewährt hat sich ein zweistufiges Vorgehen: zuerst passiv erfassen (Export vorhandener EVTX, Statusabfragen, Konfiguration), anschließend gezielt aktivieren oder reproduzieren (zusätzliche Kanäle einschalten, Tracing nur für ein Zeitfenster). Wichtig ist die Konsistenz: Zeitfenster, Filterkriterien und Exportformate sollten pro Fall gleich bleiben, damit Vergleiche möglich sind.

• EVTX selektiv exportieren (mit Zeitfenster): wevtutil epl System C:\Temp\System.evtx
wevtutil epl "Microsoft-Windows-WindowsUpdateClient/Operational" C:\Temp\WU-Operational.evtx
• Abfrage statt UI-Filter (stabil reproduzierbar): Get-WinEvent -FilterHashtable @{LogName="System"; StartTime=(Get-Date).AddHours(-6)} | Select TimeCreated,Id,ProviderName,LevelDisplayName,Message
• Kanalstatus und Größe dokumentieren: wevtutil gl System
wevtutil gl "Microsoft-Windows-DNS-Client/Operational"
• Systemzustand als Kontext sichern: systeminfo
Get-ComputerInfo | Select WindowsProductName,WindowsVersion,OsBuildNumber
Get-HotFix | Sort InstalledOn -Descending | Select -First 20

Beim Export ist darauf zu achten, dass die EVTX-Dateien nicht „aus Versehen“ überschrieben werden und dass die Ablage einen nachvollziehbaren Namensstandard trägt (Host, Zeitraum, Kanal). Bei Sicherheitslogs gelten zusätzlich Zugriffs- und Auditvorgaben; hier ist insbesondere wichtig, die Integrität der Exportkette (wer, wann, womit) zu dokumentieren.

Typische Fallstricke: scheinbar fehlende Logs, irreführende IDs, Kettenfehler

Mehrdeutige oder generische Meldungen sind der Normalfall. Viele Event-IDs signalisieren nur „etwas ging schief“, nicht aber warum; die Ursache steht dann in einem anderen Kanal oder ergibt sich erst aus begleitenden Statusabfragen. Zusätzlich existieren Ereignisse, die in unterschiedlichen Windows-Versionen oder durch unterschiedliche Provider ähnlich aussehen, aber abweichende Semantik haben. Für Windows 11 ist deshalb die Kombination aus ProviderName, Kanal und Event-ID der stabile Schlüssel; die reine Nummer reicht selten.

„Keine Events“ ist ebenfalls ein Signal: Entweder ist der relevante Kanal deaktiviert, die Loggröße zu klein, die Aufbewahrung überschreibt zu schnell, oder die Zeitfilterung passt nicht zur tatsächlichen Zeitzone. In Remoteszenarien kommen Verzerrungen hinzu, etwa durch verzögerte Ereignisübermittlung in zentralen Sammlungen. Bei Kettenfehlern hilft ein konsequentes Vorgehen entlang der Abhängigkeiten: Netzwerk vor Domänenanmeldung, Domänenanmeldung vor Gruppenrichtlinien, Gruppenrichtlinien vor App-Start, Storage vor Dateisystem, Dateisystem vor Update-Servicing.

• Provider-/Kanal-Verwechslung vermeiden: Ereignisse stets mit Get-WinEvent inklusive ProviderName und LogName erfassen, nicht nur mit einer Event-ID aus der GUI.
• Überschreiben durch kleine Loggrößen erkennen: Kanalparameter mit wevtutil gl <LogName> prüfen (u. a. maxSize, retention).
• „Symptom statt Ursache“ entlarven: Bei Dienstabbrüchen zusätzlich Dienstabhängigkeiten und Status prüfen: sc qc <Dienstname>
sc query <Dienstname>
• Fehlerketten zeitlich schneiden: Zeitfenster um den Auslöser eng halten (z. B. ±15 Minuten) und danach erweitern; Abfrage mit Get-WinEvent -FilterHashtable @{StartTime=...; EndTime=...} statt „letzte 24 Stunden“.

Wenn diese Grundregeln eingehalten werden, lassen sich die späteren Mastertabellen konsistent nutzen: Symptome werden nicht als Text behauptet, sondern mit korrelierten Zeitpunkten, eindeutigem Provider/Kanal, gesichertem Logpfad und einer prüfbaren Folge von Kommandos hinterlegt. Genau dadurch werden Nebenwirkungen sichtbar, etwa wenn ein scheinbarer Anwendungsfehler in Wirklichkeit aus Namensauflösung, Zertifikatsvalidierung oder einem blockierten Servicestart resultiert.

Mastertabellen: Symptome, Dienste/Komponenten, Event-IDs, Logpfade und Prüfkommandos (PowerShell, MMC, WPR/WPA)

Die Mastertabellen verdichten Fehlerbilder aus Windows 11 auf eine prüfbare Kette aus Symptom → betroffene Komponente/Dienst → Event-Quelle und Ereignis-ID → konkretes Log (Kanal) → geeignete Werkzeuge und Kommandos. Dadurch lässt sich die Diagnose konsequent an Telemetrie, Protokollen und Zustandsabfragen ausrichten, statt an freien Symptombeschreibungen. Wichtig ist die Trennung zwischen “Wo wird protokolliert?” (Eventlog-Kanal, Datei-Log, ETW-Trace) und “Wodurch wird bestätigt?” (Service-Status, Treiberzustand, Netzwerkpfad, Integritätsprüfungen, Performance-Traces).

Für die Zuordnung werden bevorzugt die standardisierten Windows-Eventlogs unter %SystemRoot%\System32\winevt\Logs\ genutzt. Kanäle aus “Applications and Services Logs” erscheinen dort als eigene .evtx-Dateien, während klassische Kanäle wie “System” und “Application” ebenfalls als System.evtx und Application.evtx vorliegen. Ergänzend sind textbasierte Logs relevant, etwa CBS/DISM unter %windir%\Logs\CBS\CBS.log und %windir%\Logs\DISM\dism.log, sowie Update-Protokolle, die je nach Windows-Version/Build über ETW-Ausgaben bzw. die WindowsUpdateClient-Operational-Events nachvollzogen werden.

Spaltenlogik: von Symptomen zu Belegen

Die Tabellen sollten pro Zeile nur ein klar abgegrenztes Symptom abbilden und mehrere, eng verknüpfte Prüfpfade anbieten. Bewährt haben sich Spalten für Fehlerbild (beobachtetes Verhalten), betroffener Dienst/Komponente (z. B. wuauserv, WinRM, Netlogon, WlanSvc), Event-Quelle(n) und Event-IDs, exakter Kanalname (MMC-Ansicht) plus Dateipfad der .evtx, sowie “Erstprüfung” (schnell, nicht-invasiv) und “Vertiefung” (Trace, Korrelation, Eskalation).

Für Eventlogs ist der präzise Kanalname entscheidend, weil Quellen in mehreren Kanälen auftreten können. Beispiel: Update-Fehler tauchen im “System”-Log (Service Control Manager, Kernel) und parallel in “Microsoft-Windows-WindowsUpdateClient/Operational” auf. Die Mastertabellen bilden deshalb Kanal, Quelle und ID gemeinsam ab, damit die Abfrage in PowerShell eindeutig bleibt.

Praxis-Cluster: häufige Problemfamilien mit Logkanälen und IDs

Die folgenden Einträge sind als Muster für Tabellenzeilen zu verstehen: Sie kombinieren typische Windows-11-Symptome mit häufig relevanten Kanälen und konkreten Erstprüfungen. Event-IDs können je nach Build, Rollup und Feature-Set variieren; deshalb ist die Kombination aus Kanal und Provider wichtiger als eine isolierte ID-Liste. In der Tabelle werden IDs als Startpunkt geführt, die Filterung sollte aber immer mit einem Zeitfenster und korrelierenden Quellen erfolgen.

• Windows Update: Download/Installation schlägt fehl: Kanal Microsoft-Windows-WindowsUpdateClient/Operational, typische IDs u. a. 20, 25, 31; Logdatei %SystemRoot%\System32\winevt\Logs\Microsoft-Windows-WindowsUpdateClient%4Operational.evtx; Abfragen: Get-WinEvent -FilterHashtable @{LogName="Microsoft-Windows-WindowsUpdateClient/Operational"; Id=20,25,31; StartTime=(Get-Date).AddDays(-7)}
Get-Service wuauserv,usosvc,bits | Select Name,Status,StartType
DISM /Online /Cleanup-Image /RestoreHealth und Logkorrelation über %windir%\Logs\DISM\dism.log
• Treiber/Kernel: Bluescreen oder spontane Reboots: Kanal System, Provider Microsoft-Windows-Kernel-Power (häufig 41) und Microsoft-Windows-WER-SystemErrorReporting; Logdatei %SystemRoot%\System32\winevt\Logs\System.evtx; Abfragen: Get-WinEvent -FilterHashtable @{LogName="System"; ProviderName="Microsoft-Windows-Kernel-Power"; StartTime=(Get-Date).AddDays(-14)}
wevtutil qe System /q:"*[System[Provider[@Name='Microsoft-Windows-WER-SystemErrorReporting']]]" /f:text /c:50
  Vertiefung per ETW: wpr -start GeneralProfile -filemode und Auswertung in WPA (wpa.exe)
• Anmeldung/Profil: Temporäres Profil, Anmeldeverzögerung: Kanäle Application (Provider Microsoft-Windows-User Profiles Service) und Microsoft-Windows-User Profiles Service/Operational; Logdateien %SystemRoot%\System32\winevt\Logs\Application.evtx und %SystemRoot%\System32\winevt\Logs\Microsoft-Windows-User Profiles Service%4Operational.evtx; Abfragen: Get-WinEvent -FilterHashtable @{LogName="Microsoft-Windows-User Profiles Service/Operational"; StartTime=(Get-Date).AddDays(-7)}
Get-LocalUser | Select Name,Enabled,LastLogon
  Korrelation mit GPO/Domain über gpresult /h %TEMP%\gp.html
• Netzwerk: WLAN-Verbindungsabbrüche/“Kein Internet”: Kanäle Microsoft-Windows-WLAN-AutoConfig/Operational und Microsoft-Windows-NetworkProfile/Operational; Logpfade %SystemRoot%\System32\winevt\Logs\Microsoft-Windows-WLAN-AutoConfig%4Operational.evtx, %SystemRoot%\System32\winevt\Logs\Microsoft-Windows-NetworkProfile%4Operational.evtx; Erstprüfung: Get-NetAdapter | Select Name,Status,LinkSpeed,DriverInformation
netsh wlan show wlanreport (Report unter %ProgramData%\Microsoft\Windows\WlanReport\wlan-report-latest.html)
  Get-DnsClientServerAddress und Test-NetConnection -ComputerName 1.1.1.1 -InformationLevel Detailed
• DNS/Name Resolution: Zeitüberschreitungen, sporadische Auflösung: Kanal Microsoft-Windows-DNS-Client/Operational; Logdatei %SystemRoot%\System32\winevt\Logs\Microsoft-Windows-DNS-Client%4Operational.evtx; Abfragen: Get-WinEvent -FilterHashtable @{LogName="Microsoft-Windows-DNS-Client/Operational"; StartTime=(Get-Date).AddDays(-3)}
$dns=(Get-DnsClientServerAddress -AddressFamily IPv4).ServerAddresses | Where-Object {$_} | Select-Object -First 1; Resolve-DnsName -Name example.com -Server $dns
  Flankierend: ipconfig /displaydns und ipconfig /flushdns
• RDP: Anmeldung scheitert, Abbrüche nach Verbindungsaufbau: Kanäle Microsoft-Windows-TerminalServices-LocalSessionManager/Operational und Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational; Logpfade %SystemRoot%\System32\winevt\Logs\Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx, %SystemRoot%\System32\winevt\Logs\Microsoft-Windows-TerminalServices-RemoteConnectionManager%4Operational.evtx; Erstprüfung: Get-Service TermService | Select Status,StartType
Get-NetTCPConnection -LocalPort 3389 -State Listen
  Security-Korrelation: Get-WinEvent -FilterHashtable @{LogName="Security"; Id=4625; StartTime=(Get-Date).AddDays(-2)}

Prüfkommandos standardisieren: Filter, Zeitfenster, Korrelation

Damit Mastertabellen operational bleiben, sollten Kommandos wiederholbar, schnell und selektiv sein. Für Eventlogs eignet sich Get-WinEvent mit -FilterHashtable, weil Provider, ID, LogName und Zeitfenster zusammengeführt werden. Bei hohen Ereignismengen liefert wevtutil häufig schneller Rohdaten, insbesondere mit XPATH-Queries. In MMC (Ereignisanzeige) sollte ein gespeicherter benutzerdefinierter Filter auf denselben Kanal/Provider referenzieren wie die PowerShell-Abfrage, um Abweichungen zu vermeiden.

Für Kettenfehler ist die Zeitsynchronisation zentral: Ein WLAN-Abbruch kann zeitgleich DNS-Client-Fehler erzeugen, die wiederum App-Timeouts oder Authentifizierungsprobleme nach sich ziehen. Tabellen sollten deshalb Querverweise auf “benachbarte” Kanäle enthalten, etwa WLAN-AutoConfig ↔ NetworkProfile ↔ DNS-Client ↔ Schannel/Security. Für Performance- und Latenzthemen ergänzt ETW die Eventlogs: WPR zeichnet reproduzierbare Traces, WPA visualisiert CPU, Disk, Networking und DPC/ISR, wodurch Symptome wie “UI hängt” oder “Audio knackt” auf konkrete Treiber oder Warteschlangen zurückgeführt werden können.

• Eventlog-Abfrage mit Korrelation: $t=(Get-Date).AddHours(-6); Get-WinEvent -FilterHashtable @{LogName="System"; StartTime=$t} | Where-Object {$_.ProviderName -in "Service Control Manager","Microsoft-Windows-Kernel-General"} | Select TimeCreated,ProviderName,Id,LevelDisplayName,Message
• Gezielte Kanalprüfung per Dateipfad (Existenz/Größe): Get-Item "$env:SystemRoot\System32\winevt\Logs\Microsoft-Windows-WLAN-AutoConfig%4Operational.evtx" | Select FullName,Length,LastWriteTime
• Service- und Treiberzustand (schneller Ist-Stand): Get-Service | Where-Object {$_.Status -ne "Running" -and $_.StartType -eq "Automatic"} | Select Name,DisplayName,Status
pnputil /enum-drivers
• ETW-Trace für Reproduktionsfenster: wpr -start GeneralProfile -filemode
wpr -stop "$env:TEMP\trace.etl"
wpa.exe "$env:TEMP\trace.etl"

Kettenfehler und Querverweise: Von Folgeereignissen zur Ursache mit Korrelation, Baselines und Priorisierung

Einzelne Ereignisse in Windows 11 sind selten „die Ursache“. Häufig bilden sie ein Kettenbild: Ein primärer Fehler (z. B. Namensauflösung, Zeitabweichung, Storage-Latenz) triggert Folgefehler in abhängigen Komponenten (z. B. Kerberos, Gruppenrichtlinien, AppX, Update-Stack). Querverweise zwischen Mastertabellen sollen diese Abhängigkeiten sichtbar machen, damit aus einem Symptom-Logeintrag eine belastbare Hypothese zur Erstursache entsteht. Technisch belastbar wird das erst, wenn Ereignisse zeitlich korreliert, gegen Baselines eingeordnet und nach Wirkungskette priorisiert werden.

Korrelation: Zeitfenster, Provider und Kausalität sauber trennen

Korrelation beginnt mit einem definierten Zeitfenster rund um den ersten beobachteten Impact (z. B. Anmeldeverzögerung, Dienstabbruch, Paketverlust). In der Praxis bewährt sich ein enger Kernbereich (±2 Minuten) plus ein erweitertes Fenster (±30 Minuten), weil viele Root-Causes vorher auftreten, während Folgefehler erst bei Nutzung sichtbar werden. Entscheidend ist, Provider und Kanäle gezielt zu schneiden: System- und Application-Logs liefern oft nur Symptome, während die primären Signale in spezialisierten Kanälen liegen (z. B. Microsoft-Windows-WindowsUpdateClient/Operational, Microsoft-Windows-GroupPolicy/Operational, Microsoft-Windows-DNS-Client/Operational, Microsoft-Windows-Kernel-PnP/Configuration).

Kausalität lässt sich nicht „aus dem Eventtext“ ableiten, sondern aus Reihenfolge, Wiederholung und Abhängigkeiten. Wiederkehrende Muster helfen: Wenn nach Storage-Timeouts Kernel-Events zu I/O folgen, danach Dienstabstürze und schließlich Update-Fehler, liegt die Erstursache eher unten im Stack. Querverweise zwischen Tabellen sollten deshalb nicht nur Event-IDs verlinken, sondern auch eine „Upstream/Downstream“-Richtung markieren (z. B. Netzwerk → Authentifizierung → GPO → App-Start).

• Zeitschnitt in PowerShell: $t0=(Get-Date).AddMinutes(-30); $t1=Get-Date; Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=$t0; EndTime=$t1} | Sort-Object TimeCreated
• Mehrere Kanäle parallel korrelieren: $logs=@('System','Application','Microsoft-Windows-GroupPolicy/Operational','Microsoft-Windows-DNS-Client/Operational'); foreach($l in $logs){ Get-WinEvent -FilterHashtable @{LogName=$l; StartTime=$t0; EndTime=$t1} }
• Nach Provider schneiden: Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Service Control Manager'; StartTime=$t0; EndTime=$t1}
• Nach Event-ID schneiden: Get-WinEvent -FilterHashtable @{LogName='System'; Id=7000,7001,7023,7031; StartTime=$t0; EndTime=$t1}
• In der Ereignisanzeige fokussieren: eventvwr.msc
wevtutil el

Baselines: Rauschen reduzieren, Anomalien sichtbar machen

Baselines sind in der Windows-Fehlerdiagnose weniger „Performance-Metrik“ als Log-Statistik: Welche Event-IDs treten regelmäßig auf, in welcher Häufigkeit und in welchen Zeitclustern? Ohne Baseline wirken harmlose, häufige Events wie Root-Cause-Kandidaten, während seltene, aber kritische Ereignisse übersehen werden. Für eine Baseline eignet sich ein repräsentativer Zeitraum (z. B. 7–14 Tage) unter normaler Last. Die Querverweise in Tabellen profitieren, wenn pro Event-Familie ein Normalbereich hinterlegt wird (z. B. „0–2/Tag“, „Burst beim Boot erwartbar“), damit Kettenfehler nicht an Routine-Noise hängen bleiben.

Auf Endpunkten ohne zentrale Logsammlung lässt sich eine einfache Baseline aus Get-WinEvent ableiten: Zählung nach Id und ProviderName, getrennt nach Log/Channel. Wichtig ist, Boot-Phasen (Treiberinitialisierung) und Update-Phasen separat zu bewerten. Ein „Update-Fehler“ während eines Servicing-Vorgangs hat ein anderes Gewicht als derselbe Event bei Idle, ebenso unterscheiden sich Netzwerk-Events auf einem Mobilgerät (Wechsel WLAN/LTE) von einem stationären Client.

Priorisierung: „Erstes kritisches Ereignis“ statt „lautestes Symptom“

Priorisierung folgt einer einfachen Logik: Das früheste Ereignis mit hoher Kausalwahrscheinlichkeit erhält Vorrang, nicht das Ereignis mit dem dramatischsten Text. Eine sinnvolle Heuristik kombiniert Schweregrad (Critical/Error), Provider-Schicht (Kernel/Storage/Netz vor Anwendung), Persistenz (wiederholbar) und Reichweite (betrifft mehrere Dienste). In Querverweisen sollten Downstream-Events (z. B. App-Fehler) explizit auf Upstream-Prüfungen verweisen (z. B. DNS, Zeitdienst, Disk/Controller), damit Diagnosewege nicht an der Oberfläche enden.

• Boot- und Shutdown-Kette abgleichen: Get-WinEvent -FilterHashtable @{LogName='System'; Id=41,6008,1074,6005,6006,12,13; StartTime=(Get-Date).AddDays(-7)} | Sort TimeCreated
• Storage-Latenz/Resets als Upstream prüfen: Get-WinEvent -FilterHashtable @{LogName='System'; Id=129,153,157; StartTime=$t0; EndTime=$t1}
Get-PhysicalDisk | Select-Object FriendlyName,HealthStatus,OperationalStatus
• Netzwerk/DNS vor Auth/GPO prüfen: Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-DNS-Client/Operational'; StartTime=$t0; EndTime=$t1}
Resolve-DnsName -Name example.com
• Zeitabweichung als Kerberos-Killer einordnen: w32tm /query /status
w32tm /query /peers
• Update-Kette im Servicing-Kontext prüfen: Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-WindowsUpdateClient/Operational'; StartTime=$t0; EndTime=$t1}
DISM /Online /Cleanup-Image /ScanHealth

Querverweis-Design: Linkregeln für reproduzierbare Diagnosepfade

Querverweise zwischen Tabellen funktionieren nur mit konsistenten Regeln. Empfehlenswert ist eine Trennung aus (1) Symptom-Events, (2) vermuteten Upstream-Events, (3) Verifikationskommandos und (4) Ausschlussprüfungen. Jede Zeile, die ein Downstream-Symptom beschreibt, benötigt mindestens einen Verweis auf eine Upstream-Tabelle samt Logkanal und typischem „Vorläuferfenster“. Umgekehrt sollten Upstream-Zeilen Downstream-Folgen aufführen, damit ein bereits beobachteter Schaden zurück auf eine kleine Menge Ursachen verweist.

Technisch bewährt sich ein leichtgewichtiger Korrelationsschlüssel, der in Tabellen wiederverwendet wird, etwa CHAIN-NET-01 (DNS/Connectivity), CHAIN-STO-02 (I/O-Timeouts), CHAIN-TIME-01 (Zeitsynchronisation). Der Schlüssel ist kein „Ticketlabel“, sondern eine Navigationshilfe: Er verbindet Ereignisfamilien über Kanäle hinweg und steuert die Priorisierung. Ergänzend sollten Baseline-Hinweise die Bewertung stabilisieren, etwa „Event tritt beim WLAN-Roaming häufig auf“ versus „Event ist auf stationären Geräten ungewöhnlich“.

• Logpfad-Validierung (existierende Kanäle prüfen): wevtutil el | findstr /i "DNS-Client GroupPolicy WindowsUpdateClient"
• Export für Kettenanalyse ohne GUI: wevtutil epl System "$env:TEMP\System.evtx" /ow:true
wevtutil epl "Microsoft-Windows-DNS-Client/Operational" "$env:TEMP\DNS-Client.evtx" /ow:true
• Gezielte Textsuche in Events (als Ergänzung, nicht Primärfilter): Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=$t0; EndTime=$t1} | Where-Object {$_.Message -match 'timeout|reset|failed'}