# BSOD Analysis: Dem Kernel-Absturz auf den Grund gehen

TL;DR / Management Summary Ein Blue Screen of Death (BSOD) ist die Schutzreaktion des Kernels auf eine kritische Fehlfunktion. Windows schreibt dabei den RAM-Inhalt in eine Dump-Datei (.dmp). Ein Senior Admin ratet nicht, welcher Treiber schuld sein könnte, sondern nutzt den Windows Debugger (WinDbg), um den exakten Fehler-Kontext (Analyze -v) zu extrahieren. Ziel ist die Identifikation des fehlerhaften Treibers (.sys) oder der defekten Hardware-Komponente (meist RAM).

# 1. Einführung & Architektur

Was passiert beim Crash?

Wenn der Kernel eine Verletzung der Integrität feststellt (z.B. Zugriff auf ungültigen Speicher), ruft er die Funktion KeBugCheckEx() auf. Das System stoppt alle I/O, um Datenkorruption zu verhindern, und schreibt den Dump.

# Dump-Typen

  1. Small Memory Dump (256 KB): Enthält nur den Stop-Code und den Stack-Trace. Ideal für den schnellen Check.
  2. Kernel Memory Dump: Enthält nur den Kernel-Space RAM. Der Standard für Treiber-Debugging.
  3. Complete Memory Dump: Der gesamte RAM. Riesig, aber nötig für komplexe Race-Conditions.

# 2. Vorbereitung & Tools

Vom Dump zum Text.

# WinDbg (Windows Debugger)

Installieren Sie WinDbg aus dem Microsoft Store oder als Teil des SDKs.

# Symbole konfigurieren

Ohne Symbole sehen Sie nur Hex-Adressen. WinDbg braucht Zugriff auf die Microsoft Symbol Server.

# 3. Deep Dive: Den Crash analysieren

Die 5-Minuten-Diagnose.

  1. Öffnen Sie die Datei C:\Windows\Minidump\MMDDYY-XXXXX-01.dmp in WinDbg.
  2. Klicken Sie auf den Link !analyze -v im Command-Fenster.

# Worauf Sie achten müssen:

# 4. Day-2 Operations: Dump-Management

Sicherstellen, dass Dumps entstehen.

# Einstellungen via GPO/Registry

Damit Windows Dumps schreibt, muss das Pagefile (Artikel 448) auf C: vorhanden sein.

# 5. Troubleshooting & “War Stories”

Wenn der Debugger lügt.

# Top 3 Fehlerbilder

  1. Symptom: analyze zeigt ntoskrnl.exe als schuldigen Treiber.

    • Ursache: Das ist der Windows-Kernel selbst. Er ist fast nie die echte Ursache, sondern nur das “Opfer”.
    • Lösung: Schauen Sie tiefer in den Stack-Trace nach Drittanbieter-Treibern (.sys).

  2. Symptom: Kein Dump wird erstellt.

    • Ursache: Pagefile zu klein oder SSD-Controller stürzt mit ab.
    • Lösung: Pagefile auf “Vom System verwaltet” stellen.

  3. Symptom: Stop-Code WHEA_UNCORRECTABLE_ERROR.

    • Ursache: Harte Hardware-Fehler (CPU-Spannung, SSD-Defekt).
    • Lösung: Hardware-Diagnose-Tools des Herstellers nutzen.

# “War Story”: Der “Anti-Virus” Killer

Ein Server-Cluster stürzte jeden Sonntag um 0:00 Uhr ab. Stop-Code: POOL_CORRUPTION_IN_FILE_AREA. Die Analyse: WinDbg zeigte, dass ein Filter-Treiber eines bekannten Antivirus-Herstellers beim Scannen von Schattenkopien (VSS) Speicher überschrieb. Lösung: Update des AV-Clients. Ohne den Dump-Check hätten wir die Schuld beim Backup-Tool gesucht.

# 6. Monitoring & Alerting

Crash-Trends erkennen.

# BluescreenView (NirSoft)

Für den schnellen Überblick über viele PCs eignet sich BlueScreenView. Es listet alle Dumps tabellarisch auf.

# PowerShell Dump-Check

# Prüft, ob in den letzten 24h ein Dump erstellt wurde
$Dumps = Get-ChildItem C:\Windows\Minidump | Where-Object { $_.LastWriteTime -gt (Get-Date).AddDays(-1) }
if ($Dumps) { Write-Error "Crash detected!" }

# 7. Fazit & Empfehlung

Ein BSOD ist eine präzise Nachricht des Systems.

# Anhang: Cheatsheet für WinDbg

Befehl Zweck
!analyze -v Automatische Analyse
lm t n Liste aller geladenen Module
!drivers Treiber-Details
!memusage Speicher-Statistik
.symfix; .reload Symbole neu laden

# Referenzen