Vollständiger Leitfaden zur Analyse von Bluescreens und Kernel-Dumps in Windows

Informatec Digital » Ressourcen » Vollständiger Leitfaden zur Analyse von Bluescreens und Kernel-Dumps in Windows

Wenn ein Windows-Computer mit einem Bluescreen abstürzt, ist das nicht nur ärgerlich: Im Speicherabbild verbergen sich oft wertvolle Informationen, die genau Aufschluss darüber geben, was im Kernel passiert ist. Anstatt den Arbeitsspeicher oder das BIOS zu verteufeln oder sofort neu zu formatieren, lohnt es sich, zu lernen, wie man diese Daten interpretiert.

Mit etwas Übung ermöglichen uns Tools wie WinDbg und Funktionen wie !analyze -v, .bugcheck oder die korrekte Verwendung von Symbolen, von der Fehlermeldung „Ich erhalte einen Bluescreen“ zur Erkenntnis zu gelangen, welcher Treiber, welche Ressource oder welches Gerät den Bluescreen verursacht hat. In diesem Artikel erklären wir Schritt für Schritt und detailliert, wie man einen Bluescreen mithilfe seines Kernel-Dumps analysiert, welche Arten von Dumps es gibt, wie man alles vorbereitet und welche Befehle die Analyse optimal unterstützen.

Was ist ein Bluescreen (BSOD) und welche Informationen enthält er?

Wenn Windows auf einen Zustand stößt, der die Systemintegrität gefährdet und eine sichere Wiederherstellung nicht möglich ist, führt es einen internen Kernel-Aufruf namens KeBugCheckEx durch . Dieser Aufruf löst den berüchtigten Bluescreen (BSOD) aus.

KeBugCheckEx erhält stets fünf Argumente: einen Stoppcode (Fehlercode) und vier zusätzliche Parameter , die den technischen Kontext des Fehlers liefern. Genau diese Daten können wir anschließend auswerten.

• Auf dem blauen Bildschirm Klassisch, wenn das System nicht für einen automatischen Neustart konfiguriert ist.
• Im Windows-Ereignisprotokollinnerhalb der Ereignisanzeige (Systemprotokoll).
• In der Speicherabbilddatei (Minidump, Kernel-Dump oder vollständiger Dump), mithilfe von WinDbg und Befehlen wie !analyze -v o .bugcheck.

Jeder Fehlercode hat einen symbolischen Namen und einen zugehörigen Hexadezimalwert . Beispielsweise entspricht der Fehlercode DRIVER_POWER_STATE_FAILURE dem Code 0x9F , während RESOURCE_NOT_OWNED dem Code 0xE3 entspricht . Diese Codes und ihre Parameter sind in der Microsoft-Fehlercodereferenz dokumentiert, die Sie stets griffbereit haben sollten.

Zusätzlich zum Fehlercode kann der Bluescreen den Namen eines möglicherweise beteiligten .sys-Treibers anzeigen . Handelt es sich um einen Treiber eines Drittanbieters (Antivirus-Software, Netzwerkkarte, Grafikkarte usw.), haben wir oft einen klaren Verdächtigen. Erscheint eine generische Systemkomponente (ntoskrnl.exe, win32k.sys usw.) oder gar nichts, müssen wir einen Speicherauszug erstellen und WinDbg zur weiteren Untersuchung verwenden.

Arten von Speicherabbildern in Windows

Um einen Bluescreen (BSOD) detailliert zu analysieren, benötigen wir von Windows eine Speicherabbilddatei (DMP), die beim Auftreten des Fehlers erstellt wird. Diese Datei erfasst den Systemzustand zum Zeitpunkt des Fehlers und kann verschiedene Typen aufweisen.

In den Optionen unter „Start und Wiederherstellung“ (Rechtsklick auf „Dieser PC“ / „Arbeitsplatz“ → Eigenschaften → Erweiterte Systemeinstellungen → Registerkarte „Erweitert“ → Schaltfläche „Einstellungen“ unter „Start und Wiederherstellung“) können Sie zwischen verschiedenen Speicherabbildtypen wählen. Jeder Typ hat seine Vor- und Nachteile.

Kleiner Speicherauszug (Minidump)

Das Minidump- Format ist das kleinste (ca. 64 KB) und gleichzeitig das am stärksten eingeschränkte für fortgeschrittene Debugging-Verfahren. Dennoch ist es in vielen BSOD-Szenarien weiterhin nützlich, um eine schnelle Diagnose zu erhalten .

Ein Minidump speichert unter anderem folgende Daten:

• Die Stoppmeldung, der Bugcheck-Code und seine Parameter.
• Der Prozessorkontext (PRCB) des Prozessors, der den Fehler verursacht hat.
• Kernelprozessinformationen (EPROSS) des aktiven Prozesses zum Zeitpunkt des Absturzes.
• Thread-Informationen im Kernel (ETHREAD) des Threads, der den Absturz verursacht hat.
• Der Kernelmodus-Aufrufstapel für diesen Thread (bis zu 16 KB).
• Liste der geladenen Treiber zum Zeitpunkt des Urteils.
• Liste der geladenen und heruntergeladenen Module.
• Ein Debugging-Datenblock mit grundlegenden Systeminformationen.

Diese Art von Speicherabbild wird typischerweise unter %SystemRoot%\Minidump (z. B. C:\Windows\Minidump ) gespeichert. Für viele grundlegende Support- oder Diagnosefälle ist ein mit !analyze -v gründlich analysiertes Minidump völlig ausreichend.

Kernelspeicherabbild

Der Kernel-Speicherabbild enthält den Inhalt des Kernel-Speichers zum Zeitpunkt des Absturzes, mit Ausnahme der Speicherbereiche der Benutzerprozesse. Er bietet ein optimales Verhältnis zwischen Größe und Detailgenauigkeit und ist häufig die empfohlene Option zur Diagnose der meisten Bluescreens.

Dieser Speicherabbild wird als MEMORY.DMP im Systemverzeichnis %SystemRoot% (standardmäßig C:\Windows\MEMORY.DMP ) gespeichert. Seine Größe hängt vom vom Kernel verwendeten Speicher ab, ist aber in der Regel deutlich größer als ein Minidump und wesentlich besser handhabbar als ein vollständiger Speicherabbild.

Komplette Speicherauszug

Ein vollständiger Speicherauszug speichert praktisch den gesamten Inhalt des Arbeitsspeichers zum Zeitpunkt des Fehlers: Kernel, Benutzerprozesse usw. Er ist die detaillierteste Methode, benötigt aber auch den meisten Speicherplatz und ist am anspruchsvollsten in Bezug auf die Konfiguration.

Damit ein vollständiger Dump gültig ist, müssen mehrere Voraussetzungen erfüllt sein:

• El Auslagerungsdatei muss sich in der dieselbe Partition, auf der Windows installiert ist.
• Da muss sein Festplattenspeicher, der mindestens der Größe des physischen Speichers entspricht. der Maschine.
• Verschieben Sie die Auslagerungsdatei nicht auf eine andere physische Festplatte, wenn Sie beschädigte Speicherabbilder vermeiden wollen.

In Produktionsumgebungen mit viel RAM ist ein vollständiger Speicherauszug möglicherweise unpraktisch, aber bei sehr komplexen oder sporadisch auftretenden Problemen kann er den entscheidenden Unterschied bei der Lokalisierung des Problems ausmachen.

Windows so konfigurieren, dass BSODs erfasst und protokolliert werden

Bevor wir uns mit WinDbg beschäftigen, ist es unerlässlich sicherzustellen, dass das System die Speicherabbilder korrekt generiert und das Bluescreen-Ereignis protokolliert.

Im Fenster „Start und Wiederherstellung“ finden wir mehrere relevante Optionen:

• Schreibe ein Ereignis in das Systemprotokoll: muss aktiviert sein, damit der Bugcheck in der Ereignisanzeige protokolliert wird.
• Schreiben von DebuginformationenHier wählen wir zwischen Minidump, Kernel-Speicherabbild oder vollständigem Speicherabbild.
• Pfad zur Dump-Datei: Standard %SystemRoot%\MEMORY.DMP für Kernel/vollständig.
• Starten Sie automatisch neuEs ist ratsam, diese Option zu deaktivieren, wenn wir möchten. Betrachten Sie ruhig den blauen Bildschirm und notieren Sie, was erscheint.

Bei einigen Herstellern oder Supportabteilungen, beispielsweise bei bestimmten Netzwerkadaptern, wird der Benutzer gebeten, die Speicherabbilddatei (Dump-Datei) einzureichen . Diese befindet sich üblicherweise unter C:\Windows\memory.dmp . Es empfiehlt sich, sie anhand von Datum und Uhrzeit zu suchen, um die Datei zu identifizieren, die dem letzten Fehler entspricht.

Wenn wir auch dann einen Speicherabbild erzwingen wollen, wenn das System eingefroren ist (ohne Reaktion von Tastatur oder Maus), gibt es einen sehr nützlichen Trick für PS/2-Tastaturen (nicht USB/Bluetooth): die Konfiguration der Registrierung, um mit einer Tastenkombination einen Speicherabbild auszulösen.

Im Falle eines Systemabsturzes einen Speicherabbild über die Tastatur erzwingen.

Um einen Speicherauszug zu erstellen, selbst wenn der Bildschirm vollständig eingefroren ist, können Sie die Option „CrashOnCtrlScroll“ auf PS/2-Tastaturen verwenden. Diese Methode funktioniert nicht mit USB- oder Bluetooth-Tastaturen.

In der Registry müssen wir den folgenden Schlüssel erstellen oder ändern:

HKEY_LOCAL_MACHINE
  System
    CurrentControlSet
      Services
        i8042prt
          Parameters

Nombre: CrashOnCtrlScroll
Tipo:   REG_DWORD
Valor:  1

Nach einem Neustart können Sie jederzeit (auch bei eingefrorenem Bildschirm) einen kontrollierten Absturz auslösen und das System durch zweimaliges Drücken der rechten Strg- Taste und anschließend der Rollen-Taste einen Speicherauszug erstellen lassen . Dies ist sehr hilfreich, um schwerwiegende Abstürze zu untersuchen, die keinen Bluescreen (BSOD) anzeigen.

Einführung in WinDbg zur Analyse von Kernel-Dumps

WinDbg ist Microsofts führendes Tool für Kernel-Debugging und Speicherabbildanalyse . Es ist kostenlos erhältlich (derzeit auch im Microsoft Store als WinDbg Preview) und obwohl es auf den ersten Blick komplex erscheinen mag, reichen für eine erste BSOD-Analyse Kenntnisse über einige wenige grundlegende Optionen aus.

Wir können WinDbg auf dem betroffenen Rechner selbst oder auf einem beliebigen anderen Computer installieren ; die .dmp-Datei kann über das Netzwerk, per USB oder sogar komprimiert als CAB-Datei übertragen werden. Prozessor und Windows-Version, auf der wir den Speicherabbild analysieren, müssen nicht mit denen des abgestürzten Rechners übereinstimmen.

Starten Sie WinDbg mit einem Speicherabbild über die Befehlszeile.

Eine klassische Methode zum Öffnen eines Speicherauszugs in WinDbg ist die Verwendung der Befehlszeile mit dem Parameter `-z` , der den Pfad zur Auszugsdatei angibt. Dies kann mit anderen Parametern wie dem Symbol- oder Binärpfad kombiniert werden.

windbg -y <RutaSimbolos> -i <RutaBinarios> -z <RutaDump>

Der Parameter -v aktiviert den ausführlichen Modus , der sehr hilfreich ist, um mehr Kontext zu erhalten. Neben WinDbg gibt es auch kd.exe , einen konsolenbasierten Debugger, der praktisch dasselbe ermöglicht, jedoch ohne grafische Oberfläche.

kd.exe -z "Ruta\al\volcado.dmp" -y "Ruta\simbolos" -i "Ruta\busqueda\binarios"

Öffnen Sie einen Speicherabbild über die grafische Benutzeroberfläche.

Wenn WinDbg bereits im passiven Modus geöffnet ist, können Sie eine Absturzabbilddatei über das Menü „Datei“ → „Absturzabbild öffnen “ oder die Tastenkombination Strg+D laden . Wählen Sie die .dmp-Datei (oder auch eine .cab-Datei, die sie enthält) aus, und WinDbg lädt die Absturzinformationen.

Eine weitere Alternative ist, WinDbg zu starten und dort den Befehl .opendump unter Angabe des Pfads zur Dump-Datei und anschließend den Befehl g (Go) auszuführen, um die Dump-Debugging-Sitzung zu starten:

.opendump C:\Windows\Memory.dmp
g

WinDbg erlaubt sogar mehrere Müllhalden gleichzeitig räumenHinzufügen mehrerer Parameter -z auf der Befehlszeile oder durch Wiederholung .opendump mit verschiedenen Routen und der Verwaltung der Multi-Destination-Session.

Konfigurieren Sie den Symbolpfad in WinDbg

Ohne Symbole arbeitet WinDbg nahezu blind. Symbole (.pdb) enthalten Debugging-Informationen über Funktionen, interne Strukturen, Variablen, Offsets usw. und sind für eine zuverlässige Analyse unerlässlich, insbesondere bei der Arbeit mit dem Kernel.

Um die öffentlichen Symbole von Microsoft zu verwenden, ohne sie manuell herunterladen zu müssen, empfiehlt es sich, einen Symbolserver zu konfigurieren , der auf den offiziellen Microsoft-Server und ein lokales Cache-Verzeichnis verweist. Beispielsweise kann man zunächst einen Ordner C:\symbols erstellen und anschließend in WinDbg den Symbolpfad wie folgt konfigurieren:

SRV*c:\symbols*https://msdl.microsoft.com/download/symbols

Dies kann über das Menü „Datei“ → „Symboldateipfad“ oder in WinDbg Preview über „Datei“ → „Einstellungen“ → „Debugging-Einstellungen“ durch Anpassen des „Standard-Symbolpfads“ erfolgen . Bei der ersten Analyse eines Speicherabbilds eines bestimmten Systems lädt der Debugger die benötigten Symbole automatisch aus dem Internet herunter. Dies kann je nach Ihrer Internetverbindung einige Minuten dauern.

Es ist wichtig zu beachten, dass die öffentlichen Symbole von Microsoft manchmal nicht alle internen Typinformationen enthalten . Daher können Warnungen wie „Ihr Debugger verwendet nicht die richtigen Symbole“ oder Verweise auf nicht auflösbare Typen auftreten. Für die grundlegende BSOD-Analyse sind öffentliche Symbole in der Regel ausreichend, stoßen aber bei detaillierteren Informationen an ihre Grenzen.

Erste Analyse: Grundlegende Befehle und Fehlerprüfung

Sobald der Speicherabbild geladen und die Symbole konfiguriert sind, zeigt WinDbg normalerweise eine Kopfzeile mit Systeminformationen und eine Warnung wie „Verwenden Sie !analyze -v, um detaillierte Debugging-Informationen zu erhalten.“ an. Das ist unser erster Schritt für eine erste Analyse.

Der Befehl !analyze -v führt eine automatische Analyse des Speicherabbilds durch und liefert üblicherweise folgende Ergebnisse:

• Der Bugcheck-Code (zum Beispiel 0xE3, 0xD1, 0x9F, 0x44…).
• Die Parameter Arg1, Arg2, Arg3 und Arg4 aus dem Bugcheck.
• Das wahrscheinlichste Modul oder der wahrscheinlichste Treiber Ursache des Fehlers (Probably caused by).
• Der zugehörige Prozess in diesem Moment (zum Beispiel Teams.exe).
• Der Aufrufstapel (Stack-Trace) des Threads, der den Absturz ausgelöst hat.
• Bucket-Informationen und Fehlerhashes, die nützlich sind, um wiederholte Fehler zu korrelieren.

Beispielsweise könnte die Analyse eines realen Bugcheck-Falls vom Typ RESOURCE_NOT_OWNED (0xE3) darauf hindeuten, dass ein Thread versucht hat, eine Ressource freizugeben, die ihm nicht gehört . Als Prozess wird Teams.exe angezeigt, und in einer Funktion wie DrvEnumDisplaySettings wird auf win32kbase.sys verwiesen . Dies lässt vermuten, dass der fehlerhafte Thread Anzeigeeinstellungen aus dem Benutzermodus über die Windows-Grafikschicht abgefragt oder manipuliert hat.

Um die Details des Stoppcodes und seiner Parameter etwas genauer zu betrachten, haben wir auch den Befehl .bugcheckwodurch erneut der Bugcheck und die vier Argumente angezeigt werden, was nützlich ist, wenn wir diese Informationen wiederholen möchten, ohne alles erneut auszuführen. !analyze -v.

Praxisbeispiele: Fahrer und typische Konflikte

Die BSOD-Analyse konzentriert sich typischerweise auf die Identifizierung fehlerhafter oder nicht ordnungsgemäß funktionierender Treiber , Treiberkonflikte, fehlerhaften Speicherzugriffs, fehlerhafter Verarbeitung von I/O-Anforderungspaketen (IRPs) usw. Betrachten wir einige praktische Beispiele aus realen Anwendungsfällen, um den Prozess besser zu verstehen.

RESOURCE_NOT_OWNED (0xE3) im Zusammenhang mit Teams und win32kbase.sys

In einem Windows 10-Szenario, in dem nach mehrtägigem Betrieb ein Bluescreen mit dem Fehlercode 0xE3 (RESOURCE_NOT_OWNED) auftritt , zeigt der Minikernel-Dump etwas Ähnliches wie:

RESOURCE_NOT_OWNED (e3)
A thread tried to release a resource it did not own.
Arguments:
Arg1: <dirección recurso>
Arg2: <dirección thread>
Arg3: 0
Arg4: 0

PROCESS_NAME: Teams.exe

STACK_TEXT:
...
win32kbase!DrvEnumDisplaySettings+0x356
win32kbase!NtUserEnumDisplaySettings+0x59
win32k!NtUserEnumDisplaySettings+0x15
nt!KiSystemServiceCopyEnd+0x28
...

Der Debugger zeigt hier an, dass die Fehlerprüfung durch einen Thread ausgelöst wird, der mit Teams.exe verknüpft ist . Der Code im Stack zum kritischen Zeitpunkt gehört jedoch zu win32kbase.sys , genauer gesagt zur Funktion DrvEnumDisplaySettings . Dies bedeutet nicht zwangsläufig, dass Teams die direkte Ursache ist, sondern vielmehr, dass Teams eine Benutzer-API aufruft , die einen Synchronisierungs- oder Ressourcenfreigabefehler im Grafiksubsystem verursacht.

Bei solchen Diagnosen liegt die Lösung oft in einem Fehler im Windows-Grafikstack, einem bestimmten Videotreiber oder in der Interaktion zwischen Anwendung und Treibern. Die eigentliche Behebung kann die Aktualisierung der GPU-Treiber, von Teams oder sogar die Installation bestimmter Windows-Patches erfordern , anstatt einfach abzuwarten, bis sich das Problem von selbst löst.

DRIVER_IRQL_NOT_LESS_OR_EQUAL (0xD1) mit NotMyFault

Das Dienstprogramm NotMyFault von Sysinternals ist ein Lernwerkzeug, mit dem Sie Kernel-Fehler kontrolliert erzeugen können, um die Analyse von Screenshots zu erlernen. Wenn Sie beispielsweise in NotMyFault die Option „Hoher IRQL-Fehler (Kernel-Modus)“ auswählen und auf „Fehler auslösen“ klicken, wird ein DRIVER_IRQL_NOT_LESS_OR_EQUAL-Fehler (0xD1) erzwungen.

Auf dem blauen Bildschirm sehen wir etwas wie DRIVER_IRQL_NOT_LESS_OR_EQUAL und möglicherweise einen Treiberkandidaten (z. B. MyFault.sys , der vom Tool verwendete Treiber). Sobald der Speicherabbild erstellt und mit WinDbg geöffnet wurde, könnte die erste Ausgabe etwa so aussehen:

Use !analyze -v to get detailed debugging information.
BugCheck D1, {e1071800, 1c, 0, f7cda403}
*** ERROR: Module load completed but symbols could not be loaded for myfault.sys
Probably caused by : memory_corruption
Followup: memory_corruption

Obwohl der Debugger auf einen Speicherfehler hinweist , wissen wir, dass die eigentliche Ursache mit NotMyFault und dessen Treiber zusammenhängt. Um dies zu bestätigen, können wir die Ablaufverfolgung mit Befehlen wie !thread fortsetzen , um die Aufrufe des Threads zum Zeitpunkt des Fehlers zu sehen, und mit !irp, um die beteiligte IRP zu analysieren, falls der Fehler mit E/A-Operationen zusammenhängt.

Mit `!thread <dir_thread>` können wir beispielsweise den Stack-Trace des Threads anzeigen und die Anweisung finden, in der `myfault+0x403` auftritt . Dies zeigt an, wo der Testtreiber einen Fehler verursacht hat. Von dort aus können wir IRP, Speicherstatus usw. untersuchen, genau wie bei einem echten Fehler.

MEHRERE IRP-ABGESCHLOSSENE ANFRAGEN (0x44) und USB-Konflikte

Ein weiteres sehr anschauliches Beispiel ist der Bugcheck. MEHRERE_IRP_ABGESCHLOSSENE_ANFRAGEN (0x44)Dieser Fehler tritt auf, wenn Ein IRP (I/O-Anforderungspaket) wird mehr als einmal abgeschlossenin der Regel, weil zwei verschiedene Fahrer glauben, dass ihnen dasselbe IRP gehört, und beide anrufen. IoCompleteRequest().

Die Analyse mit !analyze -v könnte eine Beschreibung ähnlich dieser liefern:

MULTIPLE_IRP_COMPLETE_REQUESTS (44)
A driver has requested that an IRP be completed (IoCompleteRequest()), but
the packet has already been completed.
...
Arguments:
Arg1: <IRP_ADDRESS>
Arg2: 00000d75
Arg3: 00000000
Arg4: 00000000

Probably caused by : usbehci.sys

Zunächst scheint usbehci.sys , ein Microsoft-Treiber für USB-EHCI-Controller, der Verdächtige zu sein. Es ist jedoch relativ selten, dass ein Fehler tatsächlich durch einen nativen Windows-Treiber ohne jegliche Interaktion von Drittanbietern verursacht wird. Um der Sache auf den Grund zu gehen, verwenden wir die vom Bugcheck bereitgestellte IRP-Adresse (Arg1) und führen !irp <IRP_ADDRESS> aus.

!irp 87e5a490
Irp is active with 3 stacks 3 is current (= 0x87e5a548)
...
> [ f, 0] 0 c0 8a055618 00000000 b69de300-00000000 Success Error
  \Driver\usbehci ax88172
Args: b70989c0 00000000 00220003 00000000

In der letzten Zeile sehen wir deutlich die Zeichenkette „\Driver\usbehci ax88172“ , was darauf hindeutet, dass das IRP sowohl usbehci.sys als auch einen Treiber namens ax88172.sys durchlaufen hat , der mit einem bestimmten USB-Netzwerkchipsatz (AX88172) verknüpft ist. Daher können wir schlussfolgern, dass der Konflikt von diesem Drittanbieter-USB-NIC-Treiber und nicht vom generischen EHCI-Treiber von Microsoft verursacht wird.

In diesem Fall besteht die Lösung darin , den USB-Adaptertreiber zu aktualisieren, das Gerät auszutauschen oder es gegebenenfalls zu entfernen . Diese Art der IRP-Analyse ist besonders hilfreich bei Bluescreens (BSODs) im Zusammenhang mit USB, Speichermedien, Netzwerkkarten und allgemein allen Komponenten mit hohem E/A-Aufkommen.

Nützliche WinDbg-Befehle im Kernelmodus

Neben !analyze -v und .bugcheck gibt es mehrere WinDbg-Erweiterungen und -Befehle, die sehr nützlich sind, wenn wir uns etwas tiefer mit dem Kernel-Dumping beschäftigen wollen.

Zu den häufigsten gehören:

• !FadenZeigt detaillierte Informationen über einen Thread an, einschließlich seines Aufrufstapels, Status, zugehöriger IRPs usw. Es ermöglicht Ihnen, die "letzten Aktionen" des Threads zu sehen, der zum Zeitpunkt des Systemabsturzes ausgeführt wurde.
• !process 0 0Diese Liste enthält alle zum Zeitpunkt des Absturzes aktiven Prozesse. Sie ist hilfreich, um festzustellen, ob verdächtige Prozesse, Dienste, EDR-Software, Antivirenprogramme usw. auf dem Rechner liefen.
• !irp: analysiert ein spezifisches IRP und zeigt die Spuren der Fahrer, die es durchlaufen hatDer I/O-Befehl, die Flags usw. sind entscheidend für Fehler im Zusammenhang mit MEHRERE_IRP_ABGESCHLOSSENE_ANFRAGEN und andere E/A-Fehler.
• !cpuinfo: liefert Informationen über den Prozessor (Hersteller, MHz, Signaturen, Eigenschaften), die für die Überprüfung von Hardwareumgebungen nützlich sind.
• !peb: zeigt Details des PEB (Process Environment Block) an, wie z. B. Computername, Windows-Installationspfad, Anzahl der Prozessoren usw.
• !token: liefert Informationen über Sicherheitstoken, Berechtigungen und den Sicherheitskontext des Prozesses oder Threads.
• .cls: löscht das Befehlsfenster, wie in einer normalen Konsole.

Darüber hinaus ermöglichen viele spezifische Dateisystemerweiterungen (z. B. für PnP, NTFS usw.) das Extrahieren weiterer Informationen aus den Speicherabbildern. In manchen Fällen zeigt WinDbg das Vorhandensein von BLACKBOX* (BLACKBOXBSD, BLACKBOXNTFS, BLACKBOXPNP, BLACKBOXWINLOGON) an. Dabei handelt es sich um zusätzliche Datenblöcke, die während der Fehlerprüfung erfasst wurden, um die Diagnose bestimmter Systembereiche zu erleichtern.

Verwenden des Treiberüberprüfers zum Auffinden problematischer Treiber

Ein sehr hoher Anteil der Windows-Bluescreen-Fehler (BSOD) wird durch fehlerhafte oder schlecht programmierte Treiber verursacht . Um diese Probleme proaktiv zu erkennen, enthält das System ein leistungsstarkes Tool: den Treiberüberprüfer.

Der Treiberverifizierer läuft in Echtzeit und unterzieht ausgewählte Treiber einer Reihe von Tests und Stresstests: Er prüft die korrekte Speichernutzung, die Nutzung des Kernel-Pools, IRQL, IRP usw. Wenn er feststellt, dass ein Treiber sich fehlerhaft verhält, kann er einen kontrollierten Bluescreen erzwingen , sodass wir einen deutlicheren Speicherabbild analysieren können, in dem der Verursacher in der Regel leicht identifiziert werden kann.

Um den Treiberverifizierungsmanager zu starten, öffnen Sie einfach eine Eingabeaufforderung mit Administratorrechten und geben Sie Folgendes ein:

verifier

Dort können wir auswählen, welche Treiber wir überprüfen möchten. Vorsicht ist geboten: Der Verifizierer verursacht zusätzlichen Systemaufwand und kann die Leistung beeinträchtigen . Daher empfiehlt es sich, die Überprüfung nur für möglichst wenige verdächtige Treiber zu aktivieren , anstatt wahllos alle auszuwählen.

Sobald der Treiberverifizierer aufgrund fehlerhaften Verhaltens einen Bluescreen auslöst, können wir den Kernel-Dump mit WinDbg analysieren und idealerweise eindeutig feststellen, welcher Treiber betroffen war und welchen Fehler er verursacht hat. Die Referenzartikel von Microsoft zum Treiberverifizierer erläutern die verschiedenen Optionen und Anwendungsstrategien detailliert.

Praktische Ratschläge für Ingenieure und Techniker

Egal ob Sie Treiberentwickler, Softwareentwickler mit Kernel-Interaktion oder einfach der Techniker sind, der alle Bluescreens des Todes abfängt – es gibt einige Richtlinien, die man sich verinnerlichen sollte, um sich im Dschungel der BSODs nicht zu verirren.

Der erste Schritt, wenn der Fehler im eigenen Code liegt, besteht darin, den Kernel-Debugger systematisch zu verwenden, um das Problem zu reproduzieren und zu analysieren . Durch die Verbindung eines Debuggers mit dem Zielsystem (über Netzwerk, serielle Schnittstelle usw.) führt ein Bugcheck dazu, dass das System im Debugger anhält, anstatt direkt einen Bluescreen anzuzeigen. Dort können Sie Speicher, Stacks und Strukturen untersuchen und den Code korrigieren.

In anderen Szenarien können Fehlerprüfungen durch Treiber, Hardware oder Software von Drittanbietern verursacht werden , die außerhalb unserer Kontrolle liegen. In diesen Fällen verschiebt sich das Ziel von der „Fehlerbehebung im Code“ hin zur Isolierung und Behebung des Problems.

• Identifizieren Sie den verdächtigen Treiber oder die verdächtige Hardwarekomponente mithilfe von WinDbg und einer Dump-Analyse.
• Aktualisieren oder zurücksetzen Treiberversionen, BIOS, Firmware oder zugehörige Anwendungen.
• Entfernen oder ersetzen USB-Geräte, Grafikkarten, Netzwerkadapter konfliktreich.
• Sich anlehnen Ereignisanzeige, Sysinternals, Netzwerküberwachungs- und Analysetools zur weiteren Erläuterung.

Viele scheinbar unerklärliche Probleme lassen sich durch einfache Fehlerbehebungsmaßnahmen lösen : Dokumentation prüfen, Dateiversionen und -daten überprüfen, wichtige Komponenten neu installieren oder in Konflikt stehende Module deaktivieren. Die Analyse des Speicherabbilds gibt uns eine klare Richtung vor, wo wir suchen müssen, und erspart uns oft stundenlanges Ausprobieren.

Es ist außerdem wichtig zu beachten, dass in Umgebungen wie derjenigen, die den CrowdStrike Falcon- Vorfall und andere EDR-Systeme verursacht hat, die häufigsten Fragen sich darum drehen, was den Bluescreen ausgelöst hat und wie man ihn schnell identifizieren kann . Mit der richtigen Konfiguration von WinDbg, inklusive Symbolen und einer klaren Vorgehensweise zum Öffnen und Analysieren von Speicherabbildern, lässt sich die Ursache innerhalb von Minuten eingrenzen, was sonst möglicherweise in einer Formatierung und Neuinstallation enden würde, ohne dass die eigentliche Ursache geklärt ist.

Kurz gesagt: Die Kombination aus einer guten Speicherabbildkonfiguration, dem disziplinierten Einsatz von Tools wie WinDbg, Driver Verifier und Sysinternals sowie der Gewohnheit, Protokolle und Stacks methodisch zu überprüfen, verwandelt die Bluescreens eines unberechenbaren Feindes in eine sehr genaue Informationsquelle darüber, was im Kernel fehlgeschlagen ist , und hilft uns, wesentlich fundiertere technische Entscheidungen zu treffen.