WinDBG für Absturz-Dumps unter Windows 11 und 10: Erfahren Sie, wie Sie Crash-Dumps analysieren, BSOD-Ursachen ermitteln und Systemfehler gezielt beheben.
Wenn Windows plötzlich mit einem Bluescreen abstürzt, hinterlässt das Betriebssystem wertvolle Spuren in sogenannten Dump-Dateien. WinDbg (Windows Debugger) ist das offizielle Microsoft-Tool, um diese Absturz-Dumps unter Windows 10 und Windows 11 gezielt zu analysieren.
Dieser Artikel zeigt Ihnen Schritt für Schritt, wie Sie WinDbg installieren, konfigurieren und erfolgreich zur Fehlerursachenanalyse einsetzen.
Was ist ein Absturz-Dump und warum entsteht er?
Wenn Windows 10 oder Windows 11 auf einen schwerwiegenden Fehler trifft, den das Betriebssystem selbst nicht mehr beheben kann, reagiert es mit einem Blue Screen of Death (BSOD). Dabei friert das System ein, zeigt einen blauen Fehlerbildschirm und startet anschließend automatisch neu. Gleichzeitig erstellt Windows jedoch eine wichtige Datei: den sogenannten Memory Dump oder Absturz-Dump.
Dieser Dump ist im Wesentlichen eine Momentaufnahme des Arbeitsspeichers zum genauen Zeitpunkt des Absturzes. Deshalb enthält er Informationen wie den Fehlercode (Bug Check Code), den Zustand aller aktiven Prozesse, geladene Treiber sowie den Aufrufstapel (Call Stack) der zuletzt ausgeführten Funktion. Außerdem speichert Windows dabei Metadaten zum Systemzustand, was die Analyse erheblich erleichtert.
Diese Dump-Datei ist jedoch keine lesbare Textdatei. Stattdessen handelt es sich um binäre Daten, die ausschließlich mit einem geeigneten Debugger wie WinDbg ausgewertet werden können. Ohne das richtige Werkzeug bleibt der Absturz ein Rätsel – mit WinDbg hingegen lässt sich die Ursache häufig auf einen konkreten Treiber oder eine fehlerhafte Systemkomponente eingrenzen.
Welche Dump-Typen gibt es unter Windows?
Windows 10 und Windows 11 unterstützen mehrere Dump-Formate, die sich in Umfang und Detailtiefe unterscheiden. Zudem entscheidet der gewählte Dump-Typ darüber, wie viel Speicher auf der Festplatte belegt wird und wie gründlich die spätere Analyse ausfällt.
Kleines Speicherabbild (Minidump, 256 KB): Dieser Typ ist der kompakteste und enthält lediglich die grundlegenden Informationen über den Absturz: den Fehlercode, eine Liste der geladenen Treiber sowie den Aufrufstapel des abgestürzten Threads. Für die meisten Alltagsanalysen ist er deshalb völlig ausreichend. Außerdem werden Minidumps im Ordner C:\Windows\Minidump gespeichert.
Automatisches Speicherabbild: Windows wählt hierbei die Größe selbst, abhängig vom tatsächlichen Speicherbedarf. Dieser Typ enthält mehr Informationen als ein Minidump, jedoch weniger als ein vollständiges Abbild. Er ist die Standardeinstellung unter Windows 11.
Kernelspeicherabbild: Dieser Dump enthält ausschließlich den Kernel-Speicher – also jenen Teil, der für den Betriebssystemkern und die Treiber relevant ist. Benutzerprozesse werden hingegen nicht aufgezeichnet. Deshalb ist er kompakter als ein vollständiges Abbild, dabei jedoch detaillierter als ein Minidump.
Vollständiges Speicherabbild: Dieser Typ speichert den gesamten physischen Arbeitsspeicher zum Zeitpunkt des Absturzes. Er ist zwar am aussagekräftigsten, belegt jedoch entsprechend viel Speicherplatz auf der Festplatte – mindestens so viel wie der verbaute RAM.
Aktives Speicherabbild: Ähnlich wie das vollständige Abbild, jedoch werden inaktive Seiten herausgefiltert. Dadurch entsteht eine kleinere Datei mit dennoch hohem Informationsgehalt.
Wo liegen die Dump-Dateien auf Ihrem System?
Unter Windows 10 und Windows 11 werden Dump-Dateien standardmäßig an festen Speicherorten abgelegt. Minidumps befinden sich im Ordner C:\Windows\Minidump. Jede Datei trägt dabei einen Namen, der Datum und Uhrzeit des Absturzes codiert – zum Beispiel Mini061326-01.dmp für den 13. Juni 2026, ersten Absturz des Tages.
Größere Dump-Typen (Kernel- und vollständige Abbilder) werden hingegen direkt im Windows-Verzeichnis gespeichert, standardmäßig als C:\Windows\MEMORY.DMP. Außerdem überschreibt Windows diese Datei bei jedem neuen Absturz, sofern Sie nichts anderes eingestellt haben.
Sollte der Ordner C:\Windows\Minidump leer sein oder gar nicht existieren, dann legt Windows ihn beim nächsten Absturz automatisch an. Allerdings müssen die entsprechenden Dump-Einstellungen korrekt konfiguriert sein – andernfalls werden keine Dateien erzeugt.
Dump-Einstellungen in Windows korrekt konfigurieren
Damit Windows 10 und Windows 11 überhaupt Dump-Dateien erstellen, müssen Sie zunächst die Systemeinstellungen prüfen. Gehen Sie dabei wie folgt vor:
- Drücken Sie Windows + R, geben Sie
sysdm.cplein und bestätigen Sie mit der Eingabetaste. - Wechseln Sie zum Reiter „Erweitert“ und klicken Sie unter „Starten und Wiederherstellen“ auf „Einstellungen“.
- Wählen Sie unter „Debugginginformationen aufzeichnen“ den gewünschten Dump-Typ aus. Für die Analyse mit WinDbg empfiehlt sich zunächst „Kleines Speicherabbild (256 KB)“.
- Stellen Sie sicher, dass das Verzeichnis
%SystemRoot%\Minidumpeingetragen ist. - Setzen Sie außerdem einen Haken bei „Vorhandene Dateien überschreiben“, falls Sie immer den aktuellsten Dump behalten möchten – oder entfernen Sie ihn, um alle Dumps zu archivieren.
- Bestätigen Sie die Einstellungen mit „OK“ und starten Sie den PC neu, damit die Änderungen wirksam werden.
Zusätzlich sollte der Dienst „Systemereignisbenachrichtigung“ (SENS) aktiv sein, da er für die korrekte Erstellung von Dump-Dateien benötigt wird. Überprüfen Sie dies über die Dienste-Verwaltung (services.msc).
WinDbg Preview installieren
Microsoft bietet WinDbg in zwei Varianten an: die klassische Version als Teil des Windows SDK sowie die modernere WinDbg Preview, die über den Microsoft Store verfügbar ist. Für die meisten Anwender unter Windows 10 und Windows 11 ist WinDbg Preview die empfohlene Wahl, da sie eine aktualisierte Benutzeroberfläche, bessere Performance und regelmäßige Updates bietet.
Die Installation gelingt in wenigen Schritten:
- Öffnen Sie den Microsoft Store über das Startmenü.
- Suchen Sie nach „WinDbg Preview“.
- Klicken Sie auf „Installieren“ und warten Sie, bis der Download abgeschlossen ist.
- Starten Sie WinDbg Preview nach der Installation mit Rechtsklick → „Als Administrator ausführen“, da Administratorrechte für die Dump-Analyse erforderlich sind.
Alternativ können Sie WinDbg auch als Teil der Windows Debugging Tools über das Windows SDK installieren. Laden Sie dazu den SDK-Installer von der offiziellen Microsoft-Website herunter, wählen Sie während der Installation ausschließlich die Komponente „Debugging Tools for Windows“ aus und schließen Sie die Installation ab. Dieser Weg empfiehlt sich besonders für Entwickler, die zusätzliche Debugging-Werkzeuge benötigen.
Symbolpfad einrichten – der entscheidende Schritt
Der Symbolpfad (Symbol Path) ist die wichtigste Konfigurationseinstellung in WinDbg, bevor Sie mit der eigentlichen Analyse beginnen. Symboldateien (.pdb-Dateien) übersetzen rohe Speicheradressen in lesbare Funktions- und Modulnamen. Ohne korrekt eingerichtete Symbole bleibt die Ausgabe von WinDbg weitgehend unleserlich.
Microsoft stellt diese Symbole kostenlos über einen öffentlichen Symbol-Server bereit. Richten Sie den Symbolpfad in WinDbg Preview wie folgt ein:
- Öffnen Sie WinDbg Preview als Administrator.
- Klicken Sie oben auf „Settings“ (Zahnrad-Symbol) und wählen Sie „Debugging Settings“.
- Tragen Sie im Feld „Symbol Path“ folgenden Pfad ein:
SRV*C:\Symbols*- Bestätigen Sie mit „OK“.
Dieser Eintrag weist WinDbg an, Symboldateien zunächst lokal im Ordner C:\Symbols zu suchen. Fehlen sie dort, werden sie automatisch vom Microsoft Symbol Server heruntergeladen und für künftige Analysen zwischengespeichert. Deshalb ist beim ersten Laden einer Dump-Datei eine aktive Internetverbindung erforderlich.
Alternativ können Sie den Symbolpfad direkt über die WinDbg-Befehlszeile festlegen, nachdem Sie eine Dump-Datei geöffnet haben:
.sympath SRV*C:\Symbols*
.reloadDer Befehl .reload zwingt WinDbg, alle Symbole neu zu laden. Außerdem empfiehlt es sich, danach den Befehl lm auszuführen, um zu überprüfen, welche Module korrekt mit Symbolen geladen wurden.
Eine Dump-Datei öffnen und laden
Nachdem WinDbg Preview installiert und der Symbolpfad konfiguriert ist, können Sie eine Dump-Datei laden. Gehen Sie dazu folgendermaßen vor:
- Starten Sie WinDbg Preview als Administrator.
- Klicken Sie im Startbildschirm auf „Open dump file“ oder nutzen Sie die Tastenkombination Strg + D.
- Navigieren Sie im Dateidialog zum Ordner
C:\Windows\Minidump. - Wählen Sie die gewünschte
.dmp-Datei aus – in der Regel die neueste, erkennbar am Datum im Dateinamen. - Klicken Sie auf „Öffnen“.
WinDbg beginnt nun damit, die Dump-Datei zu laden und die benötigten Symbole herunterzuladen. Dieser Vorgang kann beim ersten Mal einige Minuten in Anspruch nehmen, da die Symboldateien zunächst vom Microsoft-Server heruntergeladen werden müssen. Im Ausgabefenster sehen Sie dabei die Statusmeldungen des Ladevorgangs.
Sobald WinDbg die Datei vollständig geladen hat, zeigt es grundlegende Informationen über den Absturz an – unter anderem den Bug Check Code, den Zeitstempel und das betroffene Modul. Außerdem wartet WinDbg auf Ihre weiteren Befehle.
Den Befehl !analyze -v ausführen
Der wichtigste Befehl in WinDbg für die Absturzanalyse lautet:
!analyze -vGeben Sie ihn im Befehlsfenster am unteren Rand der WinDbg-Oberfläche ein und drücken Sie die Eingabetaste. Der Parameter -v steht für „verbose“ (ausführlich) und sorgt dafür, dass WinDbg möglichst viele Details zur Absturzursache ausgibt.
Die Analyse kann je nach Systemgeschwindigkeit und Dump-Größe zwischen wenigen Sekunden und mehreren Minuten dauern. Außerdem muss WinDbg möglicherweise noch weitere Symboldateien nachladen – deshalb ist eine stabile Internetverbindung in dieser Phase besonders wichtig.
Nach Abschluss der Analyse zeigt WinDbg eine umfangreiche Ausgabe an, die unter anderem folgende Informationen enthält:
- BUGCHECK_CODE: Der numerische Fehlercode des BSOD (z. B.
0x0000007Eoder0xC2) - BUGCHECK_P1 bis P4: Zusätzliche Parameter, die den Fehler näher beschreiben
- MODULE_NAME: Das Modul oder der Treiber, das/der den Absturz verursacht hat
- IMAGE_NAME: Der Dateiname der verdächtigen Komponente (z. B.
ntoskrnl.exe,nvlddmkm.sys) - STACK_TEXT: Der Aufrufstapel zum Zeitpunkt des Absturzes
Die Analyse-Ausgabe verstehen und den Fehler eingrenzen
Die Ausgabe von !analyze -v kann auf den ersten Blick überwältigend wirken. Deshalb ist es wichtig zu wissen, worauf Sie sich konzentrieren sollten.
MODULE_NAME und IMAGE_NAME sind die entscheidenden Felder. Sie zeigen an, welches Modul oder welcher Treiber vermutlich für den Absturz verantwortlich ist. Dabei gilt: Endet der Dateiname auf .sys, handelt es sich um einen Treiber. Hingegen deutet ntoskrnl.exe auf den Windows-Kernel hin, was oft auf Hardwareprobleme oder fehlerhafte Treiber auf tieferer Ebene hinweist.
STACK_TEXT enthält den Aufrufstapel – also die Abfolge der zuletzt aufgerufenen Funktionen vor dem Absturz. Scrollen Sie dabei zu den obersten Einträgen, da diese den direkten Auslöser am häufigsten identifizieren. Ein typischer Eintrag könnte beispielsweise so aussehen:
nt!KeBugCheckEx
nvlddmkm+0x3b2f8cIn diesem Fall deutet nvlddmkm.sys auf einen NVIDIA-Grafiktreiber hin. Außerdem liefert der BUGCHECK_CODE wichtige Hinweise: Der Code 0x0000009F (DRIVER_POWER_STATE_FAILURE) zeigt beispielsweise an, dass ein Treiber beim Übergang in den Energiesparmodus versagt hat.
Weiterführende WinDbg-Befehle für die Tiefenanalyse
Zusätzlich zu !analyze -v bietet WinDbg eine Reihe weiterer nützlicher Befehle, die eine tiefergehende Untersuchung ermöglichen.
lmvm MODULNAME – Dieser Befehl zeigt detaillierte Informationen zu einem bestimmten Modul an, darunter Version, Hersteller und Pfad. Ersetzen Sie MODULNAME durch den in der Analyse genannten Treibernamen, zum Beispiel:
lmvm nvlddmkmkv – Gibt den vollständigen Aufrufstapel (Call Stack) mit zusätzlichen Details aus. Deshalb ist er besonders hilfreich, wenn der Stack bei !analyze -v unvollständig erscheint.
!thread – Zeigt Informationen über den Thread an, der den Absturz ausgelöst hat. Ebenso nützlich ist der Befehl !process, um Informationen über den betroffenen Prozess zu erhalten.
.bugcheck – Gibt den Bug Check Code und die zugehörigen Parameter noch einmal kompakt aus, ohne die vollständige Analyse erneut durchzuführen.
!drvobj TREIBERNAME – Liefert Informationen zum Treiberobjekt und dessen Callbacks – besonders hilfreich bei der Analyse von Treiberkonflikten.
.logopen C:\WinDbg_Log.txt und .logclose – Schreibt die gesamte Ausgabe in eine Textdatei, die Sie bequem archivieren oder in Foren teilen können.
Alternative Tools: BlueScreenView und WhoCrashed
Nicht jeder Anwender möchte sich mit der Komplexität von WinDbg auseinandersetzen. Deshalb gibt es zwei benutzerfreundlichere Alternativen, die unter Windows 10 und Windows 11 ebenfalls zuverlässig funktionieren.
BlueScreenView von NirSoft ist ein kostenloses Tool, das alle Minidump-Dateien im Ordner C:\Windows\Minidump automatisch einliest und in einer übersichtlichen Tabelle darstellt. Jede Spalte zeigt dabei Absturzdatum, Fehlercode und den beteiligten Treiber an. Zudem können Sie einzelne Treiber direkt in der unteren Fensterhälfte anzeigen lassen. BlueScreenView erfordert keine Installation und startet als portable Anwendung direkt aus dem heruntergeladenen Ordner.
WhoCrashed von Resplendence Software analysiert Dump-Dateien ebenfalls automatisch und erstellt daraus einen verständlichen Bericht in Klartext. Dieser enthält Sätze wie: „Der Absturz wurde wahrscheinlich durch den Treiber XY verursacht.“ Außerdem schlägt WhoCrashed konkrete Maßnahmen vor, zum Beispiel das Aktualisieren oder Deinstallieren eines bestimmten Treibers. Deshalb eignet sich WhoCrashed besonders für Anwender ohne technischen Hintergrund.
Der Vorteil von WinDbg gegenüber diesen Alternativen liegt jedoch in seiner Tiefe: Nur WinDbg ermöglicht eine vollständige Analyse aller Dump-Typen, inklusive Kernel-Dumps und vollständiger Speicherabbilder. Zudem ist es das einzige Tool, das auch beim Debugging laufender Prozesse und Treiber eingesetzt werden kann.
Empfohlene Vorgehensweisen bei wiederkehrenden Abstürzen
Wenn Ihr Windows 10- oder Windows 11-System regelmäßig abstürzt, sind strukturierte Maßnahmen gefragt. Die folgenden empfohlenen Vorgehensweisen helfen Ihnen dabei, das Problem systematisch einzugrenzen.
Mehrere Dump-Dateien analysieren: Analysieren Sie nicht nur den letzten Dump, sondern alle verfügbaren Dateien im Ordner C:\Windows\Minidump. Wiederkehrende Abstürze mit demselben MODULE_NAME deuten stark auf einen problematischen Treiber hin. Außerdem können unterschiedliche Fehlercodes auf ein Hardware-Problem hinweisen.
Treiber aktualisieren oder zurücksetzen: Identifizieren Sie den betroffenen Treiber über WinDbg und überprüfen Sie anschließend, ob eine aktuellere Version verfügbar ist. Laden Sie Treiberupdates grundsätzlich von der offiziellen Herstellerwebsite herunter – also direkt von NVIDIA, AMD, Intel, Realtek oder dem jeweiligen Gerätehersteller. Alternativ können Sie einen kürzlich installierten Treiber auch im Geräte-Manager zurücksetzen: Geräte-Manager öffnen → Gerät auswählen → Eigenschaften → Treiber → Treiber zurücksetzen.
Windows-Systemdateien reparieren: Führen Sie nach einem Absturz die folgenden Befehle in einer Eingabeaufforderung als Administrator aus:
sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealthSFC (System File Checker) prüft und repariert beschädigte Systemdateien. DISM stellt zusätzlich den Windows-Komponentenspeicher wieder her.
Arbeitsspeicher testen: Hardwarefehler im RAM sind eine häufige Ursache für scheinbar willkürliche Abstürze. Nutzen Sie dafür das integrierte Tool Windows-Speicherdiagnose (mdsched.exe) oder das fortgeschrittenere MemTest86, das Sie als bootfähiges USB-Medium starten.
Windows Update prüfen: Stellen Sie sicher, dass alle ausstehenden Updates installiert sind. Microsoft veröffentlicht regelmäßig Patches, die bekannte BSOD-Ursachen beheben. Öffnen Sie dazu Einstellungen → Windows Update → Nach Updates suchen.
Häufige Fragen zu WinDbg und Absturz-Dumps
Was ist der Unterschied zwischen WinDbg und WinDbg Preview?
WinDbg Preview ist die modernisierte Version des klassischen Windows Debuggers. Sie bietet eine überarbeitete Benutzeroberfläche, bessere Performance durch Nutzung mehrerer CPU-Kerne sowie regelmäßige Updates über den Microsoft Store. Funktional sind beide Versionen nahezu identisch, jedoch ist WinDbg Preview für die meisten Anwender unter Windows 10 und Windows 11 die bessere Wahl.
Warum zeigt WinDbg keine Symbole an?
Das passiert meistens, wenn der Symbolpfad nicht korrekt eingerichtet ist oder keine Internetverbindung besteht. Überprüfen Sie deshalb, ob der Eintrag SRV*C:\Symbols* im Symbolpfad hinterlegt ist. Außerdem sollten Sie sicherstellen, dass der OrdnerC:\Symbols` existiert oder von WinDbg automatisch angelegt werden kann.
Was bedeutet der Bug Check Code 0x0000007E?
Der Code 0x0000007E (SYSTEM_THREAD_EXCEPTION_NOT_HANDLED) tritt auf, wenn ein Systemthread eine Ausnahme erzeugt, die nicht behandelt werden konnte. Häufige Ursachen sind inkompatible Treiber, fehlerhafte Hardware oder beschädigte Systemdateien. WinDbg zeigt dabei in der Regel den verursachenden Treiber im Feld IMAGE_NAME an.
Kann ich Dump-Dateien von einem anderen PC analysieren?
Ja, das ist möglich. WinDbg kann Dump-Dateien unabhängig davon analysieren, auf welchem System sie erstellt wurden. Kopieren Sie die .dmp-Datei einfach auf Ihren Analyse-PC und öffnen Sie sie dort mit WinDbg. Allerdings werden die passenden Symbole dann vom Microsoft Symbol Server heruntergeladen, was eine Internetverbindung voraussetzt.
Wie lange dauert die Analyse mit !analyze -v?
Die Dauer hängt von der Größe der Dump-Datei und der Internetverbindung ab. Ein Minidump wird meistens innerhalb von 30 bis 60 Sekunden analysiert. Hingegen kann ein vollständiges Speicherabbild mehrere Minuten in Anspruch nehmen, insbesondere wenn viele Symbole nachgeladen werden müssen.
Was tun, wenn der Ordner C:\Windows\Minidump leer ist?
Überprüfen Sie zunächst die Dump-Einstellungen unter Systemsteuerung → System → Erweiterte Systemeinstellungen → Starten und Wiederherstellen. Stellen Sie sicher, dass unter „Debugginginformationen aufzeichnen“ ein Dump-Typ ausgewählt ist. Außerdem benötigt Windows ausreichend freien Speicherplatz auf dem Systemlaufwerk, um Dump-Dateien erstellen zu können.
Ist WinDbg auch für vollständige Speicherabbilder geeignet?
Ja, WinDbg unterstützt alle Dump-Typen unter Windows 10 und Windows 11 – von Minidumps über Kernel-Dumps bis hin zu vollständigen Speicherabbildern. Allerdings benötigen vollständige Abbilder entsprechend mehr Analyse-Zeit und Arbeitsspeicher auf dem Analyse-System.
Was bedeutet „ntoskrnl.exe“ als verursachendes Modul?
ntoskrnl.exe ist der Windows-Kernel. Wenn er als Absturzverursacher angezeigt wird, deutet das meistens nicht auf einen Fehler im Kernel selbst hin. Stattdessen ist häufig ein Treiber eines Drittanbieters schuld, der fehlerhafte Daten an den Kernel übergibt. Analysieren Sie in diesem Fall den vollständigen Call Stack mit dem Befehl kv.
Kann WinDbg auch Absturzanalysen auf Windows Server durchführen?
Ja, WinDbg funktioniert gleichermaßen auf Windows Server 2016, 2019, 2022 und neueren Versionen. Die Vorgehensweise ist dabei identisch zu Windows 10 und Windows 11. Deshalb eignet sich WinDbg auch für Administratoren in Unternehmensumgebungen.
Welches Tool empfiehlt sich für Einsteiger – WinDbg oder BlueScreenView?
Für einen schnellen ersten Überblick eignet sich BlueScreenView oder WhoCrashed besser, da beide Tools keine Konfiguration erfordern und die wichtigsten Informationen sofort lesbar darstellen. WinDbg hingegen ist das leistungsfähigere Werkzeug für eine tiefergehende Analyse – und deshalb die richtige Wahl, wenn einfachere Tools den Verursacher nicht eindeutig identifizieren können.
Fazit
WinDbg Preview ist das leistungsfähigste Tool, um Absturz-Dumps unter Windows 10 und Windows 11 professionell zu analysieren. Mit dem korrekten Symbolpfad und dem Befehl !analyze -v lässt sich die Ursache eines BSOD in vielen Fällen auf einen konkreten Treiber eingrenzen.
Außerdem bieten BlueScreenView und WhoCrashed einen schnellen Einstieg für weniger erfahrene Anwender. Wer jedoch wiederkehrende Abstürze systematisch lösen möchte, kommt an WinDbg langfristig nicht vorbei.