Windows-Debugging-Tools: Diagnose und Behebung von BSODs. Windows-Debugging-Tools: Diagnose und Behebung von BSODs Erstellen eines Remote-Servers

Diese Arten von Fehlern sind normalerweise mit einem ausgefallenen Treiber verbunden, der schwer zu lokalisieren sein kann. Das verbesserte Fehlerverfolgungssystem in Windows Vista (und nicht nur in Vista!) kann Sie jedoch oft zu einer problematischen Datei führen. Infolgedessen hören die meisten Menschen auf, verzweifelt zu versuchen, auf einem instabilen Computer zu arbeiten, Dokumente mit paranoider Regelmäßigkeit zu speichern und auf das Beste zu hoffen.

Beim Absturz von Windows wird in der Regel ein sogenannter „Memory Dump“ erstellt. Letzteres kann mit den kostenlosen Windows-Debugging-Tools untersucht werden, die Sie auf die Ursache des Problems hinweisen können. Daher müssen Sie nur Folgendes tun:

Laden Sie sich ein Debugging-Tool herunter

Sie können die Windows-Debugging-Tools direkt von der Microsoft-Website herunterladen. Das Programm funktioniert mit vielen Betriebssysteme, beginnend mit Windows NT 4 und endend mit Windows 2008, Sie sollten also keine Probleme damit haben. Ja, es kann nicht gesagt werden, dass es unter Windows 7 RC stabil ist, aber nach unseren Tests funktioniert es immer noch. Daher kann sogar ein Versuch, ein Problem unter Windows 7 RC zu diagnostizieren, erfolgreich sein.

Konfigurieren Sie Ihr System

Bei Abstürzen muss Ihr Computer Speicherabbilder erstellen, die später als Informationsquelle für den Debugger dienen. Daher ist es wichtig, dass Windows so konfiguriert ist, dass Dumps generiert werden. Um Ihr Betriebssystem zu konfigurieren, klicken Sie mit der rechten Maustaste auf Ihren Computer (Computer) und wählen Sie Eigenschaften (Eigenschaften). Klicken Sie dann auf die Registerkarte Erweiterte Systemeinstellungen, suchen Sie dort den Unterabschnitt Start- und Wiederherstellungseinstellungen und stellen Sie sicher, dass die Option Debugging-Informationen schreiben auf Kernel-Speicherabbild ) oder Vollständiges Speicherabbild eingestellt ist.

Klicken Sie als nächstes auf Start, gehen Sie zu Programme (Alle Programme), wählen Sie Debugging Tools und führen Sie WinDbg aus. Gehen Sie im Programm zum Menü Datei und wählen Sie Symboldateipfad ... Schreiben Sie dann die folgende Zeile in das sich öffnende Fenster:

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

Letzterer definiert den Pfad zu speziellen Daten – den sogenannten „Symbolen“ (Symbole), die dem Debugging-Tool bei der Identifizierung Ihrer abgestürzten Datei helfen können.

Klicken Sie nach Eingabe der Zeichenfolge auf die Schaltfläche OK. Später, wenn Sie mit dem Debugger arbeiten, bewirkt diese Zeile, dass die Symbole von msdl.microsoft.com heruntergeladen und im Ordner c:\symbols gespeichert werden.

Lösen Sie Ihr Problem

Warten Sie nun auf einen weiteren Bluescreen-Fehler und den anschließenden Neustart des Computers. Führen Sie dann WinDbg erneut aus (Vista-Benutzer müssen das Programm als Administrator ausführen), klicken Sie auf das Menü Datei, wählen Sie Crash Dump öffnen, öffnen Sie die Datei \Windows\MEMORY.DMP, und das Programm beginnt sofort mit der Analyse.

Leider bietet WinDbg nur sehr wenige Informationen darüber, was es tut, sodass Sie vielleicht sogar denken, dass das Programm hängen bleibt. Allerdings warten. Beachten Sie, dass die Analyse von beispielsweise 4 GB Arbeitsspeicher auf einem nicht sehr leistungsstarken Computer einige Zeit bis zu Stunden dauern kann. Seien Sie daher geduldig, sondern lassen Sie die Analyse lieber über Nacht stehen.

In der Regel stellt sich das Ergebnis jedoch innerhalb weniger Minuten ein. Dies wird durch die Bugcheck-Analysezeile belegt, die so etwas wie "Wahrscheinlich verursacht durch: UACReplace.sys" sagt. Ins Russische übersetzt bedeutet dies, dass das Problem möglicherweise durch die Datei UACReplace.sys verursacht wird. Geben Sie es in die Suchleiste ein, z. B. Google, und Sie erfahren seinen wahren Ursprung. Insbesondere, wenn es zu einem der von Ihnen installierten Programme gehört bzw installierter Treiber, dann können Sie einfach versuchen, es oder ihn zu aktualisieren. Vielleicht löst das deine Probleme.

Ich muss sagen, dass WinDbg von Zeit zu Zeit die Datei überhaupt nicht benennen kann oder einfach eine der Windows-DLLs auswählt. Wenn Ihnen das passiert ist, klicken Sie einfach auf das Befehlsfenster über der Statusleiste und geben Sie den Befehl ein:

Danach drücken Sie die Eingabetaste. Dadurch erhalten Sie einen detaillierteren Bericht, der Informationen über enthalten kann mögliche Gründe deine Probleme.

Wenn Sie dieses Mal kein Glück haben, verzweifeln Sie nicht. Das Debuggen ist selbst für Experten ziemlich schwierig. Schließen Sie also einfach WinDbg und führen Sie den Analysator nach dem nächsten Absturz erneut aus. Vielleicht gibt dir das ein paar mehr Informationen. Viel Glück!

Um die Ursachen von Bluescreens (BSOD) zu identifizieren, ist es erforderlich, den Speicherauszug zu analysieren. In den allermeisten Fällen reicht ein Minidump, der bei kritischen Fehlern vom System erstellt wird.
Dieser Artikel enthält Schritt-für-Schritt-Anleitung zum Installieren und Konfigurieren von WinDBG - ein leistungsstarkes Debugging-Tool, mit dem Sie die wahre Ursache des BSOD identifizieren können.

Schritt 1 – Einrichten einer kleinen Memory Dump-Aufzeichnung

Schritt 2 – Installation von WinDBG

Um Speicherabbilder zu analysieren, müssen Sie den WinDBG-Debugger installieren, der im Windows SDK enthalten ist. Zum Zeitpunkt des Schreibens der neueste verfügbare Windows-Versionen SDK:

Windows 10 SDK (Online-Installationsprogramm herunterladen)
Windows 8.1 SDK (Online-Installationsprogramm herunterladen)

Schritt 3 – Zuordnen von .dmp-Dateien zu WinDBG

Ordnen Sie Ihre .dmp-Dateien WinDBG zu, um das Lesen und Analysieren von Speicherabbildern zu vereinfachen. Dadurch können Sie Dump-Dateien aus dem Explorer direkt in WinDBG öffnen und den vorläufigen Start umgehen.

Schritt 4 – Einrichten des Symbolservers zum Empfangen von Debug-Symboldateien

Die Installation und Erstkonfiguration von WinDBG ist nun abgeschlossen. Um es zu ändern Aussehen Sie können zum Menü gehen Aussicht- Schriftarteinstellungen finden Sie, indem Sie das Element auswählen Schriftart, und Konsolenfenstereinstellungen in Optionen.

Zum Zeitpunkt eines kritischen Fehlers funktioniert das Windows-Betriebssystem nicht mehr und zeigt einen Blue Screen of Death (BSOD) an. Der Inhalt des Arbeitsspeichers und alle Informationen über den aufgetretenen Fehler werden in die Auslagerungsdatei geschrieben. Beim nächsten Windows-Start wird ein Crash-Dump mit Debugging-Informationen basierend auf den gespeicherten Daten erstellt. Im Systemereignisprotokoll wird ein schwerwiegender Fehlereintrag erstellt.

Aufmerksamkeit! Ein Absturzabbild wird nicht erstellt, wenn das Festplattensubsystem ausgefallen ist oder wenn während der Anfangsphase des Windows-Starts ein kritischer Fehler aufgetreten ist.

Arten von Windows-Absturzabbildern

Betrachten wir am Beispiel des aktuellen Betriebssystems Windows 10 (Windows Server 2016) die Haupttypen von Speicherauszügen, die das System erstellen kann:

Mini-Speicherabbild (Kleines Speicherabbild)(256 KB). Diese Art von Datei enthält eine Mindestmenge an Informationen. Es enthält nur die BSOD-Fehlermeldung, Informationen über die Treiber, die Prozesse, die zum Zeitpunkt des Absturzes aktiv waren, und welcher Prozess oder Kernel-Thread den Absturz verursacht hat.
Speicherauszug des Kernels. Typischerweise klein, ein Drittel der Menge des physischen Speichers. Der Kernel-Memory-Dump ist detaillierter als der Minidump. Es enthält Informationen zu Treibern und Programmen im Kernelmodus, enthält Speicher, der dem Windows-Kernel und der Hardwareabstraktionsschicht (HAL) zugewiesen ist, sowie Speicher, der Treibern und anderen Programmen im Kernelmodus zugewiesen ist.
Vollständiger Speicherauszug. Die größte und erfordert Speicher, der dem RAM Ihres Systems entspricht, plus 1 MB, die von Windows zum Erstellen dieser Datei benötigt werden.
Automatischer Speicherauszug. Entspricht von der Information her einem Kernel Memory Dump. Es unterscheidet sich nur darin, wie viel Speicherplatz zum Erstellen der Dump-Datei verwendet wird. Dieser Dateityp existierte in Windows 7 nicht. Er wurde in Windows 8 hinzugefügt.
Aktiver Speicherauszug. Dieser Typ filtert Elemente heraus, die die Ursache eines Systemausfalls nicht bestimmen können. Dies wurde in Windows 10 hinzugefügt und ist besonders nützlich, wenn Sie eine virtuelle Maschine ausführen oder wenn Ihr System ein Hyper-V-Host ist.

Wie aktiviere ich die Generierung von Speicherabbildern in Windows?

Öffnen Sie mit Win + Pause das Systemeinstellungsfenster und wählen Sie " Zusätzliche Systemeinstellungen" (Erweiterte Systemeinstellungen). In der Registerkarte " Zusätzlich" (Erweitert), Abschnitt "" (Starten und Wiederherstellen), klicken Sie auf die Schaltfläche " Optionen" (Einstellungen). Konfigurieren Sie in dem sich öffnenden Fenster Aktionen im Falle eines Systemausfalls. Aktivieren Sie das Kontrollkästchen " Ereignisse in das Systemprotokoll schreiben» (Ein Ereignis in das Systemprotokoll schreiben), wählen Sie den Typ des Dumps aus, der bei einem Systemabsturz generiert werden soll. Wenn im Kontrollkästchen " Ersetzen Sie die vorhandene Dump-Datei» (Vorhandene Datei überschreiben) Aktivieren Sie das Kontrollkästchen, die Datei wird bei jedem Absturz überschrieben. Es ist besser, dieses Kontrollkästchen zu deaktivieren, dann haben Sie mehr Informationen für die Analyse. Deaktivieren Sie auch den automatischen Neustart des Systems (Automatisch neu starten).

In den meisten Fällen reicht ein kleiner Speicherauszug aus, um die Ursache des BSOD zu analysieren.

Wenn jetzt ein BSOD auftritt, können Sie die Dump-Datei analysieren und die Ursache der Fehler finden. Ein Minidump wird standardmäßig im Ordner %systemroot%\minidump gespeichert. Um die Dump-Datei zu analysieren, empfehle ich die Verwendung des Programms WinDBG(Microsoft-Kernel-Debugger).

Installieren von WinDBG unter Windows

Dienstprogramm WinDBG enthalten in " Windows 10-SDK» (Windows 10-SDK). .

Die Datei wird aufgerufen winsdksetup.exe, Größe 1,3 MB.

Führen Sie die Installation aus und wählen Sie aus, ob Sie das Paket auf diesem Computer installieren oder zur Installation auf anderen Computern herunterladen möchten. Installieren Sie das Paket auf dem lokalen Computer.

Sie können das gesamte Paket installieren, aber nur das Debug-Tool auswählen, um es zu installieren Debugging-Tools für Windows.

Nach der Installation finden Sie WinDBG-Verknüpfungen im Startmenü.

Festlegen der Zuordnung von .dmp-Dateien zu WinDBG

Um Dump-Dateien mit einem einfachen Klick zu öffnen, ordnen Sie die Erweiterung .dmp dem Dienstprogramm WinDBG zu.

offen Befehlszeile als Administrator und führen Sie Befehle für 64-Bit-Systeme aus: cd C:\Program Files (x86)\Windows Kits\10\Debuggers\x64
windbg.exe –IA
für 32-Bit-System:
C:\Programme (x86)\Windows Kits\10\Debugger\x86
windbg.exe –IA
Als Ergebnis werden Dateitypen: .DMP, .HDMP, .MDMP, .KDMP, .WEW WinDBG zugeordnet.

Einrichten eines Debug-Symbolservers in WinDBG

Debug-Symbole (Debug-Symbole oder Symboldateien) sind Datenblöcke, die beim Kompilieren eines Programms zusammen mit einer ausführbaren Datei erzeugt werden. Solche Datenbausteine enthalten Informationen über Variablennamen, aufgerufene Funktionen, Bibliotheken usw. Diese Daten werden beim Ausführen des Programms nicht benötigt, sind jedoch beim Debuggen nützlich. Microsoft-Komponenten werden mit Symbolen kompiliert, die über den Microsoft Symbol Server verteilt werden.

Richten Sie WinDBG für die Verwendung von Microsoft Symbol Server ein:

Öffnen Sie WinDBG;
Gehen Sie zum Menü Datei –> Symboldateipfad;
Schreiben Sie einen String mit der URL zum Herunterladen von Debug-Symbolen von der Microsoft-Website und dem Ordner zum Speichern des Caches: SRV*E:\Sym_WinDBG*http://msdl.microsoft.com/download/symbols Im Beispiel wird der Cache heruntergeladen in den Ordner E:\Sym_WinDBG, können Sie beliebige angeben.
Vergessen Sie nicht, Änderungen im Menü zu speichern Datei–>Arbeitsbereich speichern;

WinDBG sucht nach Symbolen im lokalen Ordner und lädt die Symbole automatisch von der angegebenen Site herunter, wenn es die erforderlichen Symbole darin nicht findet. Wenn Sie Ihren eigenen Symbolordner hinzufügen möchten, können Sie dies folgendermaßen tun:

SRV*E:\Sym_WinDBG*http://msdl.microsoft.com/download/symbols;c:\Symbols

Wenn keine Internetverbindung besteht, laden Sie zuerst das Symbolpaket von der Windows-Ressource Symbolpakete herunter.

Crash-Dump-Analyse in WinDBG

Der WinDBG-Debugger öffnet die Dump-Datei und lädt die notwendigen Symbole zum Debuggen aus lokaler Ordner oder aus dem Internet. Während dieses Vorgangs können Sie WinDBG nicht verwenden. Am unteren Rand des Fensters (in der Debugger-Befehlszeile) erscheint die Inschrift Debuggee nicht verbunden.

Befehle werden in die Befehlszeile am unteren Rand des Fensters eingegeben.

Das Wichtigste, worauf Sie achten sollten, ist der Fehlercode, der immer im Hexadezimalwert angegeben wird und so aussieht 0xXXXXXXXXX(angezeigt in einer der Optionen - STOP:, 07/02/2019 0008F, 0x8F). In unserem Beispiel lautet der Fehlercode 0x139.

Der Debugger fordert Sie auf, den Befehl auszuführen: analyze -v, bewegen Sie einfach den Mauszeiger über den Link und klicken Sie darauf. Wozu dient dieser Befehl?

Es führt eine vorläufige Analyse des Speicherauszugs durch und liefert detaillierte Informationen zum Starten der Analyse.
Dieser Befehl zeigt den STOP-Code und den symbolischen Namen des Fehlers an.
Es zeigt die Aufrufliste der Befehle, die zum Absturz geführt haben.
Außerdem werden hier IP-Adresse, Prozess- und Registerfehler angezeigt.
Das Team kann fertige Empfehlungen zur Lösung des Problems geben.

Die wichtigsten Punkte, auf die Sie bei der Analyse nach Ausführung des Befehls !analyze -v achten sollten (die Auflistung ist nicht vollständig).

1: kd> !analyse -v

* *
*Bugcheck-Analyse*
* *
*****************************************************************************
Symbolischer Name des STOP-Fehlers (BugCheck)
KERNEL_SECURITY_CHECK_FAILURE (139)
Beschreibung des Fehlers (Eine Kernel-Komponente hat eine kritische Datenstruktur beschädigt. Diese Beschädigung könnte es einem Angreifer möglicherweise ermöglichen, die Kontrolle über diesen Computer zu übernehmen):

Eine Kernel-Komponente hat eine kritische Datenstruktur beschädigt. Die Beschädigung könnte es einem böswilligen Benutzer möglicherweise ermöglichen, die Kontrolle über diesen Computer zu erlangen.
Fehlerargumente:

Argumente:
Arg1: 0000000000000003, A LIST_ENTRY wurde beschädigt (d. h. doppelt entfernt).
Arg2: ffffd0003a20d5d0, Adresse des Trap-Frames für die Ausnahme, die die Fehlerprüfung verursacht hat
Arg3: ffffd0003a20d528, Adresse des Ausnahmedatensatzes für die Ausnahme, die die Fehlerprüfung verursacht hat
Arg4: 0000000000000000, reserviert
Debugging-Details:
------------------

Der Zähler zeigt, wie oft das System mit einem ähnlichen Fehler abgestürzt ist:

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: FAIL_FAST_CORRUPT_LIST_ENTRY

STOP-Fehlercode in abgekürzter Form:

BUGCHECK_STR: 0x139

Der abgestürzte Prozess (nicht unbedingt die Fehlerursache, nur dieser Prozess lief zum Zeitpunkt des Absturzes im Arbeitsspeicher):

PROZESSNAME: sqlservr.exe

Erläuterung des Fehlercodes: Das System hat in dieser Anwendung einen Stack-Pufferüberlauf festgestellt, der es einem Angreifer ermöglichen könnte, die Kontrolle über diese Anwendung zu übernehmen.

ERROR_CODE: (NTSTATUS) 0xc0000409 – Das System hat in dieser Anwendung einen Überlauf eines Stack-basierten Puffers festgestellt. Dieser Überlauf könnte es einem böswilligen Benutzer möglicherweise ermöglichen, die Kontrolle über diese Anwendung zu erlangen.
AUSNAHMECODE: (NTSTATUS) 0xc0000409 – Das System hat in dieser Anwendung einen Überlauf eines stapelbasierten Puffers festgestellt. Dieser Überlauf könnte es einem böswilligen Benutzer möglicherweise ermöglichen, die Kontrolle über diese Anwendung zu erlangen.

Letzter Aufruf auf dem Stack:

LAST_CONTROL_TRANSFER: von fffff8040117d6a9 zu fffff8040116b0a0

Aufrufliste zum Zeitpunkt des Ausfalls:

STAPEL_TEXT:
ffffd000`3a20d2a8 fffff804`0117d6a9: 00000000`00000139 00000000`00000003 ffffd000`3a20d5d0 ffffd000`3a20d528: nt!KeBugCheckEx
ffffd000`3a20d2b0 fffff804`0117da50: ffffe000`f3ab9080 ffffe000`fc37e001 ffffd000`3a20d5d0 fffff804`0116e2a2: nt!KiBugCheckDispatch+0x69
ffffd000`3a20d3f0 fffff804`0117c150: 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000: nt!KiFastFailDispatch+0xd0
ffffd000`3a20d5d0 fffff804`01199482: ffffc000`701ba270 ffffc000`00000001 000000ea`73f68040 fffff804`000006f9: nt!KiRaiseSecurityCheckFailure+0x3d0
ffffd000`3a20d760 fffff804`014a455d: 00000000`00000001 ffffd000`3a20d941 ffffe000`fcacb000 ffffd000`3a20d951: nt! ?? ::FNODOBFM::`string"+0x17252
ffffd000`3a20d8c0 fffff804`013a34ac: 00000000`00000004 00000000`00000000
ffffd000`3a20d990 fffff804`0117d313: ffffffff`fffffffe 00000000`00000000 00000000`00000000 000000eb`a0cf1380: nt!NtWriteFile+0x694
ffffd000`3a20da90 00007ffb`475307da: 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000: nt!KiSystemServiceCopyEnd+0x13
000000ee'f25ed2b8 00000000'00000000: 00000000'00000000 00000000'00000000 00000000'00000000

Der Codeabschnitt, in dem der Fehler aufgetreten ist:

FOLLOWUP_IP:
nt!KiFastFailDispatch+d0
fffff804`0117da50 c644242000 mov byte ptr ,0
FAULT_INSTR_CODE: 202444c6
SYMBOL_STACK_INDEX: 2
SYMBOL_NAME: nt!KiFastFailDispatch+d0
FOLLOWUP_NAME: Maschinenbesitzer

Der Name des Moduls in der Kernel-Objekttabelle. Wenn der Analysator einen problematischen Treiber erkennen konnte, wird der Name in den Feldern MODULE_NAME und IMAGE_NAME angezeigt:

MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe

1: kd > lmvm nt
Durchsuchen Sie die vollständige Modulliste
Geladene Symbolbilddatei: ntkrnlmp.exe
Zugeordnete Speicherabbilddatei: C:\ProgramData\dbg\sym\ntoskrnl.exe\5A9A2147787000\ntoskrnl.exe
Bildpfad: ntkrnlmp.exe
Bildname: ntkrnlmp.exe
Interner Name: ntkrnlmp.exe
Ursprünglicher Dateiname: ntkrnlmp.exe
Produktversion: 6.3.9600.18946
Dateiversion: 6.3.9600.18946 (winblue_ltsb_escrow.180302-1800)

Im obigen Beispiel zeigte die Analyse auf die Kerneldatei ntkrnlmp.exe. Wenn die Speicherabbildanalyse auf einen Systemtreiber (z. B. win32k.sys) oder eine Kerneldatei (wie in unserem Beispiel ntkrnlmp.exe) verweist, ist diese Datei höchstwahrscheinlich nicht die Ursache des Problems. Sehr oft stellt sich heraus, dass das Problem im Gerätetreiber, in den BIOS-Einstellungen oder in einer Fehlfunktion der Hardware liegt.

Wenn Sie sehen, dass der BSOD auf einen Treiber eines Drittanbieters zurückzuführen ist, wird sein Name in den Werten MODULE_NAME und IMAGE_NAME aufgeführt.

Zum Beispiel:

Bildpfad: \SystemRoot\system32\drivers\cmudaxp.sys
Bildname: cmudaxp.sys

Öffnen Sie die Eigenschaften der Treiberdatei und überprüfen Sie ihre Version. In den meisten Fällen wird das Problem mit den Treibern durch Aktualisieren gelöst.

Debugging-Tools für Windows- Tools zum Debuggen von Betriebscodes Windows-Systeme. Dabei handelt es sich um eine Reihe von frei verteilten Programmen von Microsoft, die zum Debuggen von Code im Benutzermodus und im Kernelmodus entwickelt wurden: Anwendungen, Treiber, Dienste, Kernelmodule. Das Toolkit enthält Konsolen- und GUI-Debugger, Dienstprogramme für die Arbeit mit Symbolen, Dateien, Prozessen und Dienstprogramme für das Remote-Debugging. Das Toolkit enthält Dienstprogramme, mit denen Sie die Ursachen von Fehlern in verschiedenen Komponenten des Systems finden können. Debugging-Tools für Windows ab einem bestimmten Zeitpunkt nicht mehr als Standalone-Distribution zum Download zur Verfügung stehen und Teil des Windows SDK (Windows Software Development Kit) sind. Instrumental-Set Windows-Tools Das SDK wiederum ist als Teil des MSDN-Abonnementprogramms erhältlich oder kann kostenlos als separate Distribution von msdn.microsoft.com heruntergeladen werden. Laut den Entwicklern das Neueste und Beste aktuelle Version Debugging Tools for Windows ist im Windows SDK enthalten.

Debugging-Tools für Windows werden ziemlich oft aktualisiert und der Öffentlichkeit zur Verfügung gestellt, und dieser Prozess hängt nicht von der Version des Betriebssystems ab. Suchen Sie daher regelmäßig nach neuen Versionen.

Sehen wir uns nun an, was uns insbesondere die Debugging-Tools für Microsoft Windows ermöglichen:

Debuggen lokaler Anwendungen, Dienste (Dienste), Treiber und Kernel;
Debuggen Sie entfernte Anwendungen, Dienste (Dienste), Treiber und den Kernel über das Netzwerk;
Debuggen Sie laufende Anwendungen in Echtzeit;
Analysieren Sie Speicherauszugsdateien von Anwendungen, dem Kernel und dem System als Ganzes;
Arbeiten Sie mit Systemen, die auf x86/x64/Itanium-Architekturen basieren;
Programme im Benutzermodus und im Kernelmodus debuggen;

Die folgenden Versionen der Debugging-Tools für Windows sind verfügbar: 32-Bit x86, Intel Itanium, 64-Bit x64. Wir brauchen zwei davon: x86 oder x64.

Es gibt mehrere Möglichkeiten, Debugging Tools für Windows zu installieren, in diesem Artikel werden wir nur die wichtigsten betrachten:

Installation über Web-Installer.
Installieren von Debugging-Tools für Windows von der Windows SDK-ISO.
Installieren von Debugging-Tools für Windows direkt aus den Paketen dbg_amd64.msi /dbg_x86.msi.

Es bleibt unklar, an welcher Stelle, warum sollte ich Debugging-Tools auf einem Computer installieren? Schließlich kommt es oft vor, dass Eingriffe in das Arbeitsumfeld höchst unerwünscht sind! Und dies umso mehr, als die Installation eines neuen Produkts, dh das Vornehmen von Änderungen an der Registrierung / den Systemdateien, möglicherweise völlig inakzeptabel ist. Beispiele sind unternehmenskritische Server. Warum ziehen Entwickler keine portablen Versionen von Anwendungen in Betracht, die keine Installation erfordern?
Von Version zu Version wird der Installationsprozess des Pakets „Debugging Tools for Windows“ einigen Änderungen unterzogen. Lassen Sie uns nun direkt in den Installationsprozess einsteigen und uns ansehen, wie das Toolkit installiert werden kann.

Installieren von Debugging-Tools für Windows mit dem Web Installer

Gehen Sie zur Seite Windows SDK Archive und suchen Sie einen Abschnitt namens Windows 10 und unterhalb des Elements „Windows 10 SDK (10586) und Microsoft Windows 10 Mobile Device Emulator (Version 10586.11)“.

Klicken Sie auf einen Artikel SDK INSTALLIEREN. Laden Sie nach dem Klicken die Datei sdksetup.exe herunter und führen Sie sie aus, wodurch der Prozess der Online-Installation des Windows SDK initiiert wird. In der Anfangsphase prüft das Installationsprogramm, ob das .NET Framework-Paket auf dem System installiert ist letzte Version(derzeit ist es 4,5). Fehlt das Paket, wird die Installation angeboten und die Station nach Abschluss neu gestartet. Unmittelbar nach dem Neustart, in der Phase der Benutzerautorisierung, beginnt der Installationsprozess direkt mit dem Windows SDK.

Wenn Sie ausnahmslos alle Komponenten des Pakets auswählen, können während des Installationsvorgangs häufig Fehler auftreten. In diesem Fall empfiehlt es sich, selektiv Komponenten zu installieren, die mindestens erforderlich sind.

Nach Abschluss der Installation der Debugging-Tools für Windows lautet der Speicherort der Debug-Dateien bei dieser Installationsmethode wie folgt:

64-Bit-Versionen: C:\Programme (x86)\Windows Kits\x.x\Debuggers\x64
32-Bit-Versionen: C:\Programme (x86)\Windows Kits\x.x\Debuggers\x86

* wobei x.x eine bestimmte Version des Entwicklungskits ist;
Ist Ihnen aufgefallen, dass sich die Installationspfade ab Version 8 merklich von den klassischen für alle früheren Versionen von Debugging-Tools unterscheiden?

Ein großer Vorteil dieser Methode zum Installieren von Debugging-Tools für Windows ist die gleichzeitige Installation von Versionen von Debugging-Tools für alle Architekturen.

Installieren von Debugging-Tools für Windows von der Windows SDK-ISO

Diese Methode umfasst die Installation von Debugging Tools for Windows unter Verwendung des vollständigen Windows SDK (Software Developers Kit)-Installationsabbilds. Bis zu einem gewissen Zeitpunkt konnten Sie das ISO-Image für das entsprechende System auf der Seite Windows SDK-Archiv herunterladen. Im Moment können Sie jedoch ein ISO-Image des SDK erhalten, indem Sie das Webinstallationsprogramm sdksetup.exe ausführen und das Element auswählen Laden Sie das Windows Software Development Kit herunter im Startfenster des Installers:

Wie sich herausstellte, ist die bisherige Installationsmethode mit dem Web-Installer ziemlich launisch und schlägt oft fehl. Auf sauberen Systemen lässt es sich problemlos installieren, aber auf ausreichend geladenen Systemen treten zahlreiche Probleme auf. Wenn dies bei Ihnen der Fall ist, verwenden Sie diese Methode.

Dementsprechend müssen Sie auf der Seite das erforderliche Distributionskit auswählen, bei mir (und ich denke bei vielen) im Moment ist es "Windows SDK für Windows 7 und .NET Framework 4" und klicken Sie direkt darunter auf den Link "Get DVD ISO-Image" .

Wenn Sie mit der Website msdn.microsoft.com arbeiten, empfehle ich Ihnen, einen Browser zu verwenden Internet Explorer, denn es wurden Fälle von Nichtfunktionieren von Konkurrenzprodukten beobachtet!

Dementsprechend ist es notwendig, nur nach Bedarf zu wählen. Normalerweise entspricht die Bitanzahl der Debugging Tools für Windows der Bitanzahl des Systems. Meine Testsysteme sind meistens 64-Bit, daher lade ich in den meisten Fällen das Image für das 64-Bit-System GRMSDKX_EN_DVD.iso herunter.
Dann müssen wir nach dem Herunterladen des Images irgendwie mit dem vorhandenen ISO-Image arbeiten. Der traditionelle Weg ist natürlich das Brennen einer CD, aber das ist eine ziemlich langwierige und manchmal kostspielige Methode. Ich schlage vor zu verwenden kostenlose Dienstprogramme um virtuelle Plattengeräte im System zu erstellen. Ich persönlich bevorzuge für diesen Zweck das Programm DEAMON Tools Lite. Jemand hat vielleicht andere Vorlieben, direktere oder leichtere Dienstprogramme, in Geschmack und Farbe, wie sie sagen.

Dann aktiviere ich per Doppelklick Autoload und starte die Installation des Windows SDK:

Wenn wir an der Reihe sind, die zu installierenden Komponenten aus der Liste auszuwählen, deaktivieren wir absolut alle Optionen mit Ausnahme der im Screenshot markierten. Dies wird uns helfen, unnötige Fehler jetzt zu vermeiden.

Richtig, der Screenshot zeigt zwei Optionen: „Windows Performance Toolkit“ und „Debugging Tools for Windows“. Wählen Sie beides, denn das Windows Performance Toolkit wird sich bei Ihrer Arbeit sicherlich als nützlich erweisen! Nachdem Sie auf die Schaltfläche „Weiter“ geklickt haben, wird die Installation im normalen Modus fortgesetzt. Und am Ende sehen Sie die Aufschrift "Installation Complete".
Nach Abschluss der Installation lauten die Arbeitsverzeichnisse des Debugging Tools for Windows-Kits wie folgt:

Für x86-Version:
Für x64-Version:

Damit ist die Installation der Debugging-Tools für Windows abgeschlossen.

Installieren von Debugging-Tools für Windows über eine .msi-Datei

Bei Problemen während der Installation von Debugging Tools for Windows auf den beiden vorherigen Wegen haben wir noch einen weiteren, den zuverlässigsten und bewährtesten, der sozusagen mehr als einmal geholfen hat. Früher, vor der Integration in das Windows SDK, waren Debugging Tools für Windows als separater .msi-Installer verfügbar, der immer noch zu finden ist, aber bereits in den Eingeweiden der Windows SDK-Distribution. Da wir bereits ein ISO-Image des Windows SDK zur Hand haben, können wir es nicht in das System mounten, sondern es einfach mit dem bekannten WinRAR-Archivierer oder einem anderen Produkt öffnen, das mit dem Inhalt von ISO-Festplatten arbeitet.

Nachdem wir das Bild geöffnet haben, müssen wir in das Verzeichnis „Setup“ gehen, das sich im Stammverzeichnis befindet, und dann eines der Verzeichnisse auswählen:

So installieren Sie die 64-Bit-Version: \Setup\WinSDKDebuggingTools_amd64 und entpacken Sie die Datei dbg_amd64.msi aus diesem Verzeichnis.
So installieren Sie die 32-Bit-Version: \Setup\WinSDKDebuggingTools und entpacken Sie die Datei dbg_x86.msi aus diesem Verzeichnis.

Nach Abschluss der Installation lauten die Arbeitsverzeichnisse des Debugging Tools for Windows-Kits wie folgt:

Für x86-Version: C:\Programme (x86)\Debugging Tools für Windows (x86)
Für x64-Version: C:\Programme\Debugging Tools für Windows (x64)

Zu diesem Zeitpunkt kann die Installation von Debugging Tools for Windows als abgeschlossen betrachtet werden.

zusätzliche Information

Ich weiß nicht, woran es liegt, vielleicht an meiner Unachtsamkeit, aber nach der Installation der Debugging-Tools für Windows setzt der Installer den Pfad zum Verzeichnis mit dem Debugger nicht in der Systempfadvariablen Path. Dadurch ergeben sich bestimmte Einschränkungen für die Ausführung verschiedener Debugging-Tasks direkt von der Konsole aus. In Ermangelung eines Pfades schreibe ich daher selbst in das Fenster Umgebungsvariablen Pfad zu Debugging-Tools:

C:\Programme (x86)\Windows Kits\10\Debugger\x86
C:\Programme (x86)\Windows Kits\10\Debugger\x64

* In Ihrem Fall können sich die Pfade sowohl aufgrund der Verwendung eines Betriebssystems mit einer anderen Bitanzahl als auch aufgrund der Verwendung eines SDK einer anderen Version unterscheiden.

Die Dienstprogramme des Pakets „Debugging Tools for Windows“ können als portable Anwendungen verwendet werden, Sie müssen lediglich das Verzeichnis aus dem Arbeitssystem kopieren Microsoft Windows-Leistungs-Toolkit und verwenden Sie es als portable Version auf einem Produktionsserver. Aber vergessen Sie nicht, die Kapazität des Systems zu berücksichtigen !! Selbst wenn Sie das Paket auf einem kritischen System vollständig installiert haben, können Sie direkt nach der Installation mit der Arbeit beginnen, es ist kein Neustart erforderlich.

Debugging-Tools für Windows

Und jetzt endlich, hier ist die Zusammensetzung der Debugging-Tools für Windows:

Datei	Zweck
adplus.doc	Dokumentation für das ADPlus-Dienstprogramm.
adplus.exe	Eine Konsolenanwendung, die die Arbeit des CDB-Debuggers automatisiert, um Dumps und Protokolldateien für einen oder mehrere Prozesse zu erstellen.
agestore.exe	Ein Dienstprogramm zum Entfernen veralteter Dateien aus dem Speicher, der vom Symbolserver oder Quellserver verwendet wird.
breakin.exe	Ein Dienstprogramm, mit dem Sie eine benutzerdefinierte Unterbrechungskombination an Prozesse senden können, ähnlich wie beim Drücken von STRG+C.
cdb.exe	Konsolen-Debugger im Benutzermodus.
convertstore.exe	Dienstprogramm zum Konvertieren von Zeichen von 2-Tier zu 3-Tier.
dbengprx.exe	Ripiter (Proxy-Server) für Remote-Debugging.
dbgpc.exe	Ein Dienstprogramm zum Anzeigen von Informationen über den Status eines RPC-Aufrufs.
dbgsrv.exe	Der für das Remotedebuggen verwendete Serverprozess.
dbh.exe	Ein Dienstprogramm zum Anzeigen von Informationen über den Inhalt einer Symboldatei.
dumpchk.exe	Dump-Überprüfungsdienstprogramm. Ein Dienstprogramm zum schnellen Überprüfen einer Dump-Datei.
dumpexam.exe	Ein Dienstprogramm zum Analysieren eines Speicherauszugs. Das Ergebnis wird in %SystemRoot%\MEMORY.TXT ausgegeben.
gflags.exe	Editor für globale Systemflags. Das Dienstprogramm verwaltet Registrierungsschlüssel und andere Einstellungen.
i386kd.exe	Hülle für kd. Wurde kd früher so für Windows NT/2000-basierte Systeme für x86-Rechner genannt? Vermutlich aus Kompatibilitätsgründen gelassen.
ia64kd.exe	Hülle für kd. Wurde kd früher so für Windows NT/2000-basierte Systeme für ia64-Rechner genannt? Vermutlich aus Kompatibilitätsgründen gelassen.
kd.exe	Konsolendebugger im Kernelmodus.
kdbgctrl.exe	Kernel-Debug-Management-Tool. Dienstprogramm zum Verwalten und Konfigurieren der Kernel-Debugging-Verbindung.
kdsrv.exe	Verbindungsserver für KD. Das Dienstprogramm ist eine kleine Anwendung, die ausgeführt wird und auf Remoteverbindungen wartet. kd wird auf einem Client ausgeführt und verbindet sich mit diesem Server für das Remote-Debugging. Sowohl der Server als auch der Client müssen aus derselben Debugtools-Assembly stammen.
kill.exe	Dienstprogramm zum Beenden von Prozessen.
list.exe	Ein Dienstprogramm zum Anzeigen des Inhalts einer Datei auf dem Bildschirm. Dieses Mini-Dienstprogramm wurde mit einem Zweck gebündelt - dem Anzeigen großer Text- oder Protokolldateien. Es nimmt wenig Speicherplatz ein, da es den Text in Teilen lädt.
logger.exe	Ein winziger Debugger, der nur mit einem Prozess arbeiten kann. Das Dienstprogramm fügt logexts.dll in den Prozessbereich ein, der alle Funktionsaufrufe und andere Aktionen des untersuchten Programms aufzeichnet.
logviewer.exe	Ein Dienstprogramm zum Anzeigen von Protokollen, die vom Debugger logger.exe geschrieben wurden.
ntsd.exe	Symbolischer Microsoft NT-Debugger (NTSD). Ein Debugger, der mit cdb identisch ist, außer dass er beim Start ein Textfenster erstellt. Wie cdb ist ntsd in der Lage, sowohl Konsolenanwendungen als auch grafische Anwendungen zu debuggen.
pdbcopy.exe	Ein Dienstprogramm zum Entfernen privater Symbole aus einer Symboldatei, das öffentliche Symbole steuert, die in einer Symboldatei enthalten sind.
remote.exe	Dienstprogramm für das Remote-Debugging und die Fernsteuerung aller KD-, CDB- und NTSD-Konsolen-Debugger. Ermöglicht es Ihnen, alle diese Konsolen-Debugger remote auszuführen.
rtlist.exe	Remote-Task-Viewer. Das Dienstprogramm wird verwendet, um laufende Prozesse über den DbgSrv-Serverprozess aufzulisten.
symchk.exe	Ein Dienstprogramm zum Herunterladen von Symbolen vom Microsoft-Symbolserver und zum Erstellen eines lokalen Symbolcaches.
symstore.exe	Dienstprogramm zum Erstellen von Netzwerk- oder lokalen Speichern von Symbolen (2-Tier/3-Tier). Ein Symbolspeicher ist ein spezialisiertes Verzeichnis auf einer Festplatte, das nach einer bestimmten Struktur aufgebaut ist und Symbole enthält. Im Stammverzeichnis der Symbole wird eine Unterordnerstruktur angelegt, deren Namen identisch mit den Namen der Komponenten sind. Jeder dieser Unterordner enthält wiederum verschachtelte Unterordner mit speziellen Namen, die durch Hashing von Binärdateien erhalten werden. Das Symstore-Dienstprogramm scannt Komponentenordner und fügt neue Komponenten zum Symbolspeicher hinzu, wo jeder Client sie abrufen kann. Der Symstore soll verwendet werden, um Symbole aus dem 0-Tier-Speicher zu erhalten und sie in den 2-Tier-/3-Tier-Speicher zu legen.
tlist.exe	Task-Viewer. Ein Dienstprogramm zum Auflisten aller laufenden Prozesse.
umdh.exe	Dump-Heap-Dienstprogramm im Benutzermodus. Ein Dienstprogramm zum Analysieren von Heaps eines ausgewählten Prozesses. Ermöglicht es Ihnen, verschiedene Optionen für den Heap anzuzeigen.
usbview.exe	USB-Viewer. Dienstprogramm zu sehen USB-Geräte an einen Computer angeschlossen.
vmdemux.exe	Demultiplexer für virtuelle Maschinen. Erstellt mehrere benannte Pipes für eine einzelne COM-Verbindung. Kanäle werden verwendet, um verschiedene Komponenten der virtuellen Maschine zu debuggen
windbg.exe	Benutzermodus- und Kernelmodus-Debugger mit GUI.

Um die Ursachen von Bluescreens (BSOD) zu identifizieren, ist es erforderlich, den Speicherauszug zu analysieren. In den allermeisten Fällen reicht ein Minidump, der bei kritischen Fehlern vom System erstellt wird.
Dieser Artikel enthält schrittweise Anweisungen zum Installieren und Konfigurieren von WinDBG, einem leistungsstarken Debugging-Tool, mit dem Sie die wahre Ursache eines BSOD identifizieren können.

Schritt 1 – Einrichten einer kleinen Memory Dump-Aufzeichnung

Schritt 2 – Installation von WinDBG

Um Speicherabbilder zu analysieren, müssen Sie den WinDBG-Debugger installieren, der im Windows SDK enthalten ist. Zum Zeitpunkt des Schreibens sind die neuesten verfügbaren Versionen des Windows SDK:

Windows 10 SDK (Online-Installationsprogramm herunterladen)
Windows 8.1 SDK (Online-Installationsprogramm herunterladen)

Schritt 3 – Zuordnen von .dmp-Dateien zu WinDBG

Schritt 4 – Einrichten des Symbolservers zum Empfangen von Debug-Symboldateien

Die Installation und Erstkonfiguration von WinDBG ist nun abgeschlossen. Um das Aussehen zu ändern, können Sie zum Menü gehen Aussicht- Schriftarteinstellungen finden Sie, indem Sie das Element auswählen Schriftart, und Konsolenfenstereinstellungen in Optionen.