Einführung in WinDBG - Teil 1

Alexander Antipow

WinDBG ist ein großartiger Debugger. Es hat vielleicht keine sehr benutzerfreundliche Oberfläche und standardmäßig keinen schwarzen Hintergrund, aber es ist derzeit einer der leistungsstärksten und stabilsten Debugger unter Windows. In diesem Artikel werde ich Sie durch die Grundlagen von WinDBG führen, damit Sie damit beginnen können.

WinDBG ist ein großartiger Debugger. Es hat vielleicht keine sehr benutzerfreundliche Oberfläche und standardmäßig keinen schwarzen Hintergrund, aber es ist derzeit einer der leistungsstärksten und stabilsten Debugger unter Windows. In diesem Artikel werde ich Sie durch die Grundlagen von WinDBG führen, damit Sie damit beginnen können.

Dies ist der erste Artikel einer Reihe über WinDBG. Liste aller Artikel dieser Serie:

• Teil 1 - Installation, Schnittstelle, Symbole, Remote-/Lokal-Debugging, Hilfesystem, Module, Register.
• Teil 2 - Haltepunkte.
• Teil 3 - Speicherinspektion, Schritt-für-Schritt-Programmdebugging, Tipps und Tricks.

In diesem Artikel befassen wir uns mit dem Mounten und Anhängen an einen Prozess, und in den folgenden behandeln wir Breakpoints, Single-Stepping und Speicherinspektion.

Installation von WinDBG

Im Vergleich zu Windows 7 hat sich der Installationsprozess für WinDBG in Windows 8 geringfügig geändert. In diesem Abschnitt sehen wir uns die Installation eines Debuggers für beide an Betriebssysteme.

Installieren von WinDBG unter Windows 8

In Windows 8 ist WinDBG im Windows Driver Kit (WDK) enthalten. Sie können Visual Studio und das WDK installieren oder das Paket „Debugtools für Windows 8.1“, das WinDBG enthält, separat installieren.

Das Installationsprogramm fragt, ob Sie WinDBG lokal installieren oder das gesamte Entwicklungspaket für einen anderen Computer herunterladen möchten. Letzteres ist im Wesentlichen das Äquivalent Offline-Installer, was sehr praktisch ist, wenn Sie das Paket in Zukunft auf anderen Systemen installieren möchten.

Abbildung 1: Auswahl der Installationsart

Im nächsten Fenster müssen Sie alle Elemente außer „Debugging Tools for Windows“ deaktivieren und auf die Schaltfläche „Download“ klicken.

Sobald das Installationsprogramm seine Arbeit abgeschlossen hat, wechseln Sie in das Verzeichnis, in das das Paket heruntergeladen wurde (standardmäßig ist es c:\Benutzer\Benutzername\Downloads\Windows Kits\8.1\StandaloneSDK) und führen Sie den Installationsvorgang durch.

Installieren von WinDBG unter Windows 7 und früher

Für Windows 7 und höher frühe Versionen WinDBG ist Teil des Pakets „Debugging Tools for Windows“, das im Windows SDK und im .Net Framework enthalten ist. Sie müssen das Installationsprogramm herunterladen und dann während des Installationsvorgangs „Debugging Tools for Windows“ auswählen.

Während der Installation wähle ich die Option „Debugging Tools“ unter „Reistributable Packages“, um ein eigenständiges Installationsprogramm zu erstellen, um nachfolgende Installationen zu erleichtern.

Abbildung 2: Auswählen von Installationsoptionen zum Erstellen eines eigenständigen Installationsprogramms

Nach Abschluss der Installation sollten Sie WinDBG-Installationsprogramme für verschiedene Plattformen haben (im Verzeichnis c:\Programme\Microsoft SDKs\Windows\v7.1\Redist\Debugging Tools for Windows\).

Abbildung 3: Ordner mit WinDBG-Installern für verschiedene Plattformen

WinDBG-Schnittstelle

Abbildung 4: Aussehen von WinDBG

Sobald Sie das erste Mal sehen Aussehen WinDGB, Sie werden feststellen, dass der Debugger erschreckend einfach ist. Die meisten WinDBG-Funktionen werden während des Prozessdebuggens erlernt. Anstatt Zeit mit der Beschreibung der Benutzeroberfläche zu verschwenden, behandeln wir in den folgenden Abschnitten nur die wichtigsten Punkte.

Das Wichtigste, was Sie über die Debugger-Schnittstelle wissen müssen, ist das Befehlsfenster, das aus zwei Bereichen besteht. Der erste Bereich: ein Fenster, in dem das Ergebnis der Ausführung von Befehlen angezeigt wird. Zweiter Bereich: ein kleines Textfeld zur Eingabe von Befehlen.

Abbildung 5: WinDBG-Befehlsfenster

Symbole

In den meisten Fällen erfordert WinDBG keine speziellen Einstellungen und funktioniert sofort nach dem Auspacken. Aber eine wichtige Sache, die optimiert werden muss, sind die Symbole. Symbole sind Dateien, die zusammen mit der ausführbaren Datei während der Programmkompilierung generiert werden und Debugging-Informationen (Funktionen und Variablennamen) enthalten. Debug-Informationen ermöglichen es Ihnen, die Funktionalität einer Anwendung beim Debuggen oder Disassemblieren zu untersuchen. Viele Microsoft-Komponenten werden mit Symbolen kompiliert, die über den Microsoft Symbol Server verteilt werden. Bei den restlichen ausführbaren Dateien ist nicht alles so rosig – sehr selten werden Dateien mit Debugging-Informationen mit der Anwendung gebündelt. In den meisten Fällen schränken Unternehmen den Zugriff auf solche Informationen ein.

Um WinDBG für die Verwendung von Microsoft Symbol Server zu konfigurieren, gehen Sie zum Abschnitt File:Symbol File Path und legen Sie den Pfad auf SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols fest. Natürlich ist es etwas seltsam, dass Sternchen als Trennzeichen verwendet werden. Nachdem Sie den Microsoft Symbol Server eingerichtet haben, werden die Symbole in den Ordner C:\Symbols heruntergeladen.

Abbildung 6: Microsoft Symbol Server-Setup

WinDBG lädt bei Bedarf automatisch Symbole für Binärdateien. Sie können auch Ihren eigenen Symbolordner wie folgt hinzufügen:

SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols;c:\SomeOtherSymbolFolder

Hinzufügen von Symbolen während des Debuggens

Wenn Sie beim Debuggen Symbole importieren müssen, können Sie dies mit .sympath tun (das Befehlsfenster wird angezeigt, wenn Sie sich in den Prozess einklinken). Um beispielsweise den Ordner c:\SomeOtherSymbolFolder hinzuzufügen, geben Sie den folgenden Befehl ein:

0:025> .sympath+ c:\SomeOtherSymbolFolder
Symbolsuchpfad ist: SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols;c:\SomeOtherSymbolFolder
Der Suchpfad für erweiterte Symbole lautet: srv*c:\symbols*http://msdl.microsoft.com/download/symbols;c:\someothersymbolfolder

Es empfiehlt sich, Symbole nach dem Hinzufügen oder Ändern von Pfaden neu zu laden:

0:025> .neu laden
Aktuelle Module neu laden
................................................................
...............................................

Geladene Symbole prüfen

Um zu sehen, welche Module geladene Symbole haben, können Sie den Befehl x*! Obwohl WinDBG nur bei Bedarf Symbole lädt, ist das x*! zeigt Symbole, die geladen werden können. Es ist möglich, das Laden von Symbolen mit dem Befehl ld * zu erzwingen (dies kann einige Zeit dauern und Sie können diesen Vorgang stoppen, indem Sie zu Debug:Break gehen).

Jetzt können wir die Symbole für jedes Modul sehen.

Abbildung 8: Symbolliste

Debuggen eines lokalen Prozesses

Beim Debuggen eines lokalen Prozesses haben Sie zwei Möglichkeiten:

1. An einen bereits laufenden Prozess anhängen.
2. Starten Sie den Prozess über WinDBG.

Jede Methode hat ihre eigenen Vor- und Nachteile. Wenn Sie das Programm beispielsweise über WinDBG ausführen, stehen Ihnen einige spezielle Debugging-Optionen zur Verfügung (z. B. Heap-Debugging), die zum Absturz der Anwendung führen können. Andererseits gibt es auch Programme, die abstürzen, wenn man ihnen einen Debugger anhängt. Einige Anwendungen (insbesondere Malware) überprüfen beim Start das Vorhandensein eines Debuggers im System und dementsprechend ist es in diesem Fall sinnvoll, sich an einen bereits laufenden Prozess zu klammern. Manchmal gibt es ein Debugging eines Windows-Dienstes, der beim Start einige Parameter festlegt. Um den Debugging-Prozess zu vereinfachen, ist es daher auch besser, sich in einen laufenden Prozess einzuklinken, anstatt den Dienst über einen Debugger zu starten. Einige Leute behaupten, dass das Ausführen eines Prozesses durch einen Debugger einen ernsthaften Einfluss auf die Leistung hat. Kurz gesagt, probieren Sie beide aus und wählen Sie, was am besten zu Ihnen passt. Wenn Sie aus irgendeinem Grund eine bestimmte Methode bevorzugen, teilen Sie Ihre Gedanken in den Kommentaren mit!

Starten eines Prozesses

Wenn Sie debuggen gesonderte Bewerbung, die lokal und nicht im Netzwerk ausgeführt wird, möchten Sie sie möglicherweise über WinDBG ausführen. Dies bedeutet jedoch nicht, dass Sie sich nicht in einen bereits laufenden Prozess einklinken können. Wählen Sie den für Sie bequemsten Weg.

Das Starten des Prozesses ist nicht schwierig. Gehen Sie zu „Datei:Ausführbare Datei öffnen“ und wählen Sie die ausführbare Datei aus, die Sie debuggen möchten. Sie können auch Argumente angeben oder das Startverzeichnis festlegen:

Abbildung 9: Auswählen einer ausführbaren Datei zum Debuggen

Prozessverbindung

Auch die Anbindung an einen bereits laufenden Prozess ist nicht schwierig. Beachten Sie jedoch, dass es in einigen Fällen einige Zeit dauern kann, genau den Prozess zu finden, den Sie debuggen möchten. Beispielsweise erstellen einige Browser einen übergeordneten Prozess und dann mehrere weitere Prozesse für jede Registerkarte. Abhängig von dem Crash-Dump, den Sie debuggen, möchten Sie sich also möglicherweise nicht mit dem übergeordneten Prozess verbinden, sondern mit dem Prozess, der der Registerkarte zugeordnet ist.

Um an einen bereits laufenden Prozess anzuhängen, gehen Sie zu „Datei: An einen Prozess anhängen“ und wählen Sie dann die PID oder den Prozessnamen aus. Denken Sie daran, dass Sie über die entsprechenden Rechte verfügen müssen, um sich in den Prozess einzuklinken.

Abbildung 10: Auswählen eines Prozesses zum Anhängen

Wenn die Anwendung nach dem Verbinden ihre Arbeit ausgesetzt hat, können Sie den "Noninvaise"-Modus verwenden, indem Sie das entsprechende Kontrollkästchen aktivieren.

Debuggen eines Remote-Prozesses

Manchmal müssen Sie möglicherweise einen Prozess auf einem Remote-System debuggen. Es wäre viel bequemer, dieses Problem mit einem lokalen Debugger zu lösen, anstatt ihn zu verwenden virtuelle Maschine oder RDP. Oder vielleicht debuggen Sie den LoginUI.exe-Prozess, der nur verfügbar ist, wenn das System gesperrt ist. In solchen Situationen können Sie die lokale Version von WinDBG verwenden und remote an Prozesse anfügen. Um diese Probleme zu lösen, gibt es zwei gebräuchlichste Methoden.

Bestehende Debug-Sitzungen

Wenn Sie bereits mit dem lokalen Debuggen des Programms begonnen haben (indem Sie einen Prozess über WinDBG anhängen oder starten), können Sie einen bestimmten Befehl eingeben, und WinDBG startet einen „Listener“ (Zuhörer), mit dem sich der Remote-Debugger verbinden kann. Verwenden Sie dazu den Befehl .server:

Server-tcp:port=5005

Nachdem Sie den obigen Befehl ausgeführt haben, sehen Sie möglicherweise eine Warnung wie diese:

Abbildung 11: Warnmeldung, die nach dem Ausführen des Befehls zum Erstellen eines „Listeners“ angezeigt werden kann

Dann meldet WinDBG, dass der Server läuft:

0:005> .server tcp:port=5005
0: -remote tcp:Port=5005,Server=USER-PC

Sie können sich nun von einem entfernten Host zu einer bereits bestehenden Debug-Session verbinden, indem Sie auf „File:Connect to a Remote Session“ gehen und so etwas in das Textfeld eingeben: tcp:Port=5005,Server=192.168.127.138

Abbildung 12: Fernverbindung zur Debug-Session

Nach dem Verbinden erhalten Sie eine Bestätigung auf dem Remote-Client:

Server gestartet. Der Client kann sich mit jeder dieser Befehlszeilen verbinden
0: -remote tcp:Port=5005,Server=USER-PC
MASCHINENNAME\Benutzer (tcp 192.168.127.138:13334) verbunden am Montag, 16. Dezember, 09:03:03 2013

und die Meldung in der lokalen Version des Debuggers:

MASCHINENNAME\Benutzer (tcp 192.168.127.138:13334) verbunden am Montag, 16. Dezember, 09:03:03 2013

Erstellen Sie einen Remote-Server

Sie können auch einen separaten WinDBG-Server erstellen, eine Remoteverbindung damit herstellen und einen Prozess zum Debuggen auswählen. Dies kann mithilfe der Datei dbgsrv.exe erfolgen, in der Sie Prozesse debuggen möchten. Um einen solchen Server zu starten, führen Sie den folgenden Befehl aus:

dbgsrv.exe -t tcp:port=5005

Abbildung 13: Starten eines Remote-Servers

Und wieder erhalten Sie möglicherweise eine Sicherheitswarnung, die Sie akzeptieren sollten:

Abbildung 14: Sicherheitsmeldung, die beim Start des Debug-Servers angezeigt werden kann

Sie können sich mit dem Debug-Server verbinden, wenn Sie in die Datei „File: Connect to Remote Stub“ gehen und in das Textfeld folgende Zeile eingeben: TCP:Port=5005,Server=192.168.127.138

Abbildung 15: Verbindung zum Debug-Server herstellen

Nach dem Verbinden erhalten Sie keine Signale, dass Sie verbunden sind, aber wenn Sie zu "Datei: An einen Prozess anhängen" gehen, sehen Sie eine Liste von Debug-Serverprozessen (wo dbgsrv.exe ausgeführt wird). Jetzt können Sie sich in den Prozess einklinken, als ob Sie es lokal tun würden.

Hilfesystem

Das Hilfesystem in WinDBG ist großartig. Sie sollten nicht nur etwas Neues lernen, sondern auch lernen können Hintergrundinformationüber jedes Team. Verwenden Sie den Befehl .hh, um auf die WinDBG-Hilfe zuzugreifen:

Sie können auch Hilfeinformationen zu einem bestimmten Befehl abrufen. Um beispielsweise Hilfe zum Befehl .reload zu erhalten, verwenden Sie den folgenden Befehl:

windbg> .hh .neu laden

Oder gehen Sie einfach zum Abschnitt "Hilfe:Inhalt".

Module

Während das Programm läuft, werden verschiedene Module importiert, die die Funktionalität der Anwendung bereitstellen. Wenn Sie also wissen, welche Module von einer Anwendung importiert werden, können Sie besser verstehen, wie sie funktioniert. In vielen Fällen debuggen Sie das spezifische Modul, das vom Programm geladen wird, und nicht die ausführbare Datei selbst.

Sobald die Verbindung zum Prozess hergestellt ist, zeigt WinDBG automatisch die geladenen Module an. Unten sind zum Beispiel die Module, nachdem ich mich mit calc.exe verbunden habe:

Microsoft (R) Windows-Debugger-Version 6.12.0002.633 X86
Urheberrecht (c) Microsoft Corporation. Alle Rechte vorbehalten.

*** Warte mit ausstehendem Anhängen
Der Symbolsuchpfad lautet: SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols
Ausführbarer Suchpfad ist:
ModLoad: 00a70000 00b30000 C:\Windows\system32\calc.exe
ModLoad: 77630000 7776c000 C:\Windows\SYSTEM32\ntdll.dll
ModLoad: 77550000 77624000 C:\Windows\system32\kernel32.dll
ModLoad: 75920000 7596a000 C:\Windows\system32\KERNELBASE.dll
ModLoad: 76410000 77059000 C:\Windows\system32\SHELL32.dll
ModLoad: 77240000 772ec000 C:\Windows\system32\msvcrt.dll
ModLoad: 76300000 76357000 C:\Windows\system32\SHLWAPI.dll
ModLoad: 75cd0000 75d1e000 C:\Windows\system32\GDI32.dll
ModLoad: 75fa0000 76069000 C:\Windows\system32\USER32.dll
ModLoad: 777b0000 777ba000 C:\Windows\system32\LPK.dll
ModLoad: 774b0000 7754d000 C:\Windows\system32\USP10.dll
ModLoad: 73110000 732a0000 C:\Windows\WinSxS\x86_microsoft.windows.gdiplus_
6595b64144ccf1df_1.1.7600.16385_none_72fc7cbf861225ca\gdiplus.dll
ModLoad: 75a80000 75bdc000 C:\Windows\system32\ole32.dll
ModLoad: 76360000 76401000 C:\Windows\system32\RPCRT4.dll
ModLoad: 777c0000 77860000 C:\Windows\system32\ADVAPI32.dll
ModLoad: 75be0000 75bf9000 C:\Windows\SYSTEM32\sechost.dll
ModLoad: 76270000 762ff000 C:\Windows\system32\OLEAUT32.dll
ModLoad: 74590000 745d0000 C:\Windows\system32\UxTheme.dll
ModLoad: 74710000 748ae000 C:\Windows\WinSxS\x86_microsoft.windows.common-
ModLoad: 703d0000 70402000 C:\Windows\system32\WINMM.dll
ModLoad: 74c80000 74c89000 C:\Windows\system32\VERSION.dll
ModLoad: 77770000 7778f000 C:\Windows\system32\IMM32.DLL
ModLoad: 75c00000 75ccc000 C:\Windows\system32\MSCTF.dll
ModLoad: 74130000 7422b000 C:\Windows\system32\WindowsCodecs.dll
ModLoad: 74260000 74273000 C:\Windows\system32\dwmapi.dll
ModLoad: 756d0000 756dc000 C:\Windows\system32\CRYPTBASE.dll
ModLoad: 75e60000 75ee3000 C:\Windows\system32\CLBCatQ.DLL
ModLoad: 6ef10000 6ef4c000 C:\Windows\system32\oleacc.dll

Später im Debugging-Prozess können Sie diese Liste mit dem Befehl lmf erneut anzeigen:

0:005>lmf
start end Modulname
00a70000 00b30000 calc C:\Windows\system32\calc.exe
6ef10000 6ef4c000 oleacc C:\Windows\system32\oleacc.dll
703d0000 70402000 WINMM C:\Windows\system32\WINMM.dll
73110000 732a0000 gdiplus C:\Windows\WinSxS\x86_microsoft.windows.gdiplus_6595b64144ccf1df_
1.1.7600.16385_none_72fc7cbf861225ca\gdiplus.dll
74130000 7422b000 WindowsCodecs C:\Windows\system32\WindowsCodecs.dll
74260000 74273000 dwmapi C:\Windows\system32\dwmapi.dll
74590000 745d0000 UxTheme C:\Windows\system32\UxTheme.dll
74710000 748ae000 COMCTL32 C:\Windows\WinSxS\x86_microsoft.windows.common-
controls_6595b64144ccf1df_6.0.7600.16385_none_421189da2b7fabfc\COMCTL32.dll
74c80000 74c89000 VERSION C:\Windows\system32\VERSION.dll
756d0000 756dc000 CRYPTBASE C:\Windows\system32\CRYPTBASE.dll
75920000 7596a000 KERNELBASE C:\Windows\system32\KERNELBASE.dll
75a80000 75bdc000 ole32 C:\Windows\system32\ole32.dll
75be0000 75bf9000 sechost C:\Windows\SYSTEM32\sechost.dll
75c00000 75ccc000 MSCTF C:\Windows\system32\MSCTF.dll
75cd0000 75d1e000 GDI32 C:\Windows\system32\GDI32.dll
75e60000 75ee3000 CLBCatQ C:\Windows\system32\CLBCatQ.DLL
75fa0000 76069000 USER32 C:\Windows\system32\USER32.dll
76270000 762ff000 OLEAUT32 C:\Windows\system32\OLEAUT32.dll
76300000 76357000 SHLWAPI C:\Windows\system32\SHLWAPI.dll
76360000 76401000 RPCRT4 C:\Windows\system32\RPCRT4.dll
76410000 77059000 SHELL32 C:\Windows\system32\SHELL32.dll
77240000 772ec000 msvcrt C:\Windows\system32\msvcrt.dll
774b0000 7754d000 USP10 C:\Windows\system32\USP10.dll
77550000 77624000 Kernel32 C:\Windows\system32\kernel32.dll
77630000 7776c000 ntdll C:\Windows\SYSTEM32\ntdll.dll
77770000 7778f000 IMM32 C:\Windows\system32\IMM32.DLL
777b0000 777ba000LPK C:\Windows\system32\LPK.dll
777c0000 77860000 ADVAPI32 C:\Windows\system32\ADVAPI32.dll

Sie können die Download-Adresse für ein bestimmtes Modul auch mit dem Befehl „lmf m“ herausfinden:

0:005> lmf m Kernel32
start end Modulname
77550000 77624000 Kernel32 C:\Windows\system32\kernel32.dll

Mit der Erweiterung !dh ( Ausrufezeichen zeigt eine Erweiterung an):

0:005> !dh Kernel32

Dateityp: DLL
DATEIKOPFWERTE
14C-Maschine (i386)
4 Anzahl der Abschnitte
4A5BDAAD Zeit-Datum-Stempel Mo 13. Juli 21:09:01 2009

0 Dateizeiger auf Symboltabelle
0 Anzahl Symbole
Größe E0 des optionalen Headers
2102 Eigenschaften
Ausführbar
32-Bit-Wortmaschine
DLL

OPTIONALE HEADERWERTE
10B Magie #
9.00 Linker-Version
C4600 Größencode
C800 Größe der initialisierten Daten
0 Größe nicht initialisierter Daten
510C5 Adresse des Einstiegspunkts
1000 Basiscode
----- Neu -----
77550000 Bilddatenbank
1000 Abschnittsausrichtung
200 Dateiausrichtung
3-Subsystem (Windows-CUI)
6.01 Betriebssystemversion
6.01-Image-Version
6.01 Subsystemversion
Bild in D4000-Größe
Header der Größe 800
D5597 Prüfsumme
00040000 Größe der Stapelreserve
00001000 Größe des Stack-Commits
00100000 Größe der Heap-Reserve
00001000 Größe des Heap-Commits
140 DLL-Eigenschaften
dynamische Basis
NX-kompatibel
B4DA8 [A915] Adresse des Exportverzeichnisses
BF6C0 [ 1F4] Adresse des Importverzeichnisses
C7000 [ 520] Adresse des Ressourcenverzeichnisses
0 [ 0] Adresse des Ausnahmeverzeichnisses
0 [ 0] Adresse des Sicherheitsverzeichnisses
C8000 [B098] Adresse des Basisverlagerungsverzeichnisses
C5460 [38] Adresse des Debug-Verzeichnisses
0 [ 0] Adresse des Beschreibungsverzeichnisses
0 [ 0] Adresse des Spezialverzeichnisses
0 [ 0] Adresse des Thread-Speicherverzeichnisses
816B8 [ 40] Adresse des Konfigurationsverzeichnisses laden
278 [ 408] Adresse des gebundenen Importverzeichnisses
1000 [DE8] Adresse des Verzeichnisses der Importadressentabelle
0 [ 0] Adresse des verzögerten Importverzeichnisses
0 [ 0] Adresse des COR20-Header-Verzeichnisses
0 [ 0] Adresse des reservierten Verzeichnisses

ABSCHNITTÜBERSCHRIFT #1
.Textname
Virtuelle Größe von C44C1
1000 virtuelle Adressen
C4600 Größe der Rohdaten
800 Dateizeiger auf Rohdaten

0 Anzahl Umzüge
0 Anzahl Zeilennummern
60000020 Fahnen
Code
(keine Ausrichtung angegeben)
Lesen ausführen

Debug-Verzeichnisse(2)
Typ Größe Adresszeiger
cv 25 c549c c4c9c Format: RSDS, GUID, 2, Kernel32.pdb
(10) 4 c5498 c4c98

ABSCHNITTSKOPPLUNG #2
.Datenname
FEC virtuelle Größe
Virtuelle C6000-Adresse
E00 Größe der Rohdaten
C4E00-Dateizeiger auf Rohdaten
0 Dateizeiger auf Verschiebungstabelle
0 Dateizeiger auf Zeilennummern
0 Anzahl Umzüge
0 Anzahl Zeilennummern
C0000040-Flags
initialisierte Daten
(keine Ausrichtung angegeben)
Lesen Schreiben

ABSCHNITTÜBERSCHRIFT #3
.rsrc-Name
520 virtuelle Größe
Virtuelle C7000-Adresse
600 Größe der Rohdaten
C5C00-Dateizeiger auf Rohdaten
0 Dateizeiger auf Verschiebungstabelle
0 Dateizeiger auf Zeilennummern
0 Anzahl Umzüge
0 Anzahl Zeilennummern
40000040 Flaggen
initialisierte Daten
(keine Ausrichtung angegeben)
Schreibgeschützt

ABSCHNITTÜBERSCHRIFT #4
.relocname
B098 virtuelle Größe
Virtuelle C8000-Adresse
B200 Größe der Rohdaten
C6200-Dateizeiger auf Rohdaten
0 Dateizeiger auf Verschiebungstabelle
0 Dateizeiger auf Zeilennummern
0 Anzahl Umzüge
0 Anzahl Zeilennummern
42000040 Fahnen
initialisierte Daten
Wegwerfbar
(keine Ausrichtung angegeben)
Schreibgeschützt

Meldungen und Ausnahmen

Nach dem Anhängen an einen Prozess wird zuerst eine Liste von Modulen angezeigt, und dann können andere Meldungen erscheinen. Wenn wir uns beispielsweise in calc.exe einklinken, setzt WinDBG automatisch einen Haltepunkt (der nur eine Markierung ist, die zum Stoppen der Anwendung verwendet wird). Breakpoint-Informationen werden auf dem Bildschirm angezeigt:

(da8.b44): Unterbrechungsbefehlsausnahme - Code 80000003 (erste Chance)

Diese spezielle Nachricht ist eine Ausnahme, nämlich die Ausnahme der ersten Chance. Eine Ausnahme ist im Wesentlichen eine spezielle Bedingung, die während der Ausführung eines Programms auftritt. Ausnahme der ersten Chance bedeutet, dass das Programm unmittelbar nach Auftreten der Ausnahme gestoppt wurde. Eine Ausnahme der zweiten Chance bedeutet, dass nach dem Auftreten der Ausnahme einige Operationen ausgeführt werden und das Programm dann seine Arbeit stoppt.

Register

Nach dem Anzeigen von Meldungen und Ausnahmen gibt der Debugger den Zustand der Prozessorregister aus. Register sind spezielle Variablen innerhalb des Prozessors, die kleine Informationen speichern oder den Zustand von etwas im Speicher verfolgen. Der Prozessor kann die Informationen in diesen Registern sehr schnell verarbeiten. Dies ist viel schneller, als jedes Mal Informationen über den Bus aus dem RAM zu erhalten.

Nach dem Verbinden mit calc.exe zeigt WinDBG automatisch Informationen zu den folgenden Registern an:

eax=7ffd9000 ebx=00000000 ecx=00000000 edx=776cd23d esi=00000000 edi=00000000
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246

Später können Sie diese Informationen mit dem Befehl r erneut duplizieren:

0:005>r
eax=7ffd9000 ebx=00000000 ecx=00000000 edx=776cd23d esi=00000000 edi=00000000
eip=77663540 esp=02affd9c ebp=02affdc8 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
ntdll!DbgBreakPoint:
77663540 cc int 3

Wenn wir den Wert eines bestimmten Registers erhalten möchten, können wir den folgenden Befehl ausführen:

0:005> reax
eax=7ffd9000

Informationen können gleichzeitig aus mehreren Registern wie folgt bezogen werden:

0:005> reax,ebp
eax=7ffd9000 ebp=02affdc8

Zeiger auf Anweisung

Beim letzten Befehl geht es um das Ausführen von Anweisungen. Auch hier wird, wie beim r-Kommando, angezeigt, was das EIP-Register enthält. EIP ist ein Register, das den Standort enthält nächste Anweisung vom Auftragsverarbeiter auszuführen. Was WinDBG anzeigt, ist das Äquivalent des Befehls u eip L1, wonach WinDBG zu der im EIP-Register angegebenen Adresse geht, diesen Abschnitt in Assembler-Code konvertiert und auf dem Bildschirm anzeigt.

ntdll!DbgBreakPoint:
77663540 cc int 3

in Kontakt bleiben

In den folgenden Artikeln werden wir uns ansehen, wie man WinDBG im Kampf verwendet: Breakpoints, schrittweises Debugging und Speicheranzeige. Nicht wechseln! J.

Zum Zeitpunkt eines kritischen Fehlers funktioniert das Windows-Betriebssystem nicht mehr und zeigt einen Blue Screen of Death (BSOD) an. Inhalt Arbeitsspeicher und alle Informationen über den aufgetretenen Fehler werden in die Auslagerungsdatei geschrieben. Beim nächsten Windows-Start Anhand der gespeicherten Daten wird ein Crash-Dump mit Debugging-Informationen 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. In der Regel klein - ein Drittel des Volumens physikalischer Speicher. 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 Größe und benötigt Speicher in Höhe des RAM Ihres Systems plus 1 MB, erforderliche Windows um diese Datei zu erstellen.
• 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.

1. 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
2. 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 kompiliert mit Symbolen, die über 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 einem lokalen Ordner oder aus dem Internet herunter. 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 !analyze -v auszuführen, 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 stellt bereit genaue Information um die Analyse zu starten.
• 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 Prozess, der während der Ausführung abgestürzt ist (nicht unbedingt die Fehlerursache, nur dieser Prozess lief zum Zeitpunkt des Absturzes im Speicher):

PROZESSNAME: sqlservr.exe

Fehlercode-Entschlüsselung: Das System hat in dieser Anwendung einen Stapelpufferü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 stapelbasierten 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 (z. B. ntkrnlmp.exe in unserem Beispiel) verweist, ist dies höchstwahrscheinlich der Fall angegebene Datei ist nicht die Ursache des Problems. Sehr oft stellt sich heraus, dass das Problem im Gerätetreiber liegt, BIOS-Einstellungen oder Gerätestörung.

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.

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 Betriebssystemen, beginnend mit Windows NT 4 und endend mit Windows 2008, sodass Sie damit keine Probleme haben sollten. 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 Zusatzoptionen Erweitert (Erweiterte Systemeinstellungen), suchen Sie dort den Unterabschnitt Start- und Wiederherstellungseinstellungen (Start- und Wiederherstellungseinstellungen) und stellen Sie sicher, dass die Option Debugging-Informationen schreiben auf Kernel-Speicherabbild oder Vollständiges Speicherabbild ( 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, das Programm hängt fest. 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!

Debugging-Tools für Windows- Tools zum Debuggen des Codes von Windows-Betriebssystemen. 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 ist die neuste und aktuellste Version der Debugging Tools für Windows im Windows SDK enthalten.

Debugging-Tools für Windows werden aktualisiert und an gepostet öffentlicher Zugang ziemlich oft 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 über das Netzwerk Remote-Anwendungen, Dienste (Dienste), Treiber und Kernel;
• 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 ISO Windows-Image SDK.
• 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-Archiv und suchen Sie den Abschnitt darunter Windows-Name 10 und darunter „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 die neueste Version des .NET Framework-Pakets auf dem System installiert ist (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;
Uns ist aufgefallen, dass ab Version 8 die Installationspfade für alle deutlich von den klassischen abweichen vorherige Versionen Debugging-Tools?

Ein großes Plus diese Methode Beim Installieren von Debugging-Tools für Windows werden Versionen von Debugging-Tools für alle Architekturen gleichzeitig installiert.

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 gewünschte Distributionskit auswählen, bei mir (und ich denke bei vielen) im Moment "Windows SDK für Windows 7 und .NET Framework 4" und etwas weiter unten 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, weil es Fälle von Inoperabilität von Konkurrenzprodukten gegeben hat!

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.. Nach der Installation von DAEMON Werkzeuge Lite, doppelklicke ich einfach auf die Image-Datei GRMSDKX_EN_DVD.iso und ich habe eine neue virtuelle CD in meinem System:

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 fortgesetzt normaler Modus. 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

Wenn beim Installieren von Debugging Tools for Windows mit two bisherige Wege, wir haben noch einen auf Lager, 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 dieses nicht ins System mounten, sondern einfach mit Hilfe der bekannten öffnen WinRAR-Archivierer, gut, oder jedes andere Produkt, das mit dem Inhalt von ISO-Datenträgern 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 angesehen werden.

zusätzliche Information

Ich weiß nicht, woran es liegt, vielleicht an meiner Unaufmerksamkeit, 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 Debugging Tools for Windows-Pakets können als portable Anwendungen funktionieren, kopieren Sie einfach von Arbeitssystem Katalog 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 hier ist nun endlich 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. Früher hieß es kd für systems on Windows-Basis NT/2000 für x86-Rechner? 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 in Anspruch, 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 Prozessraum 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 eines Netzwerks oder lokaler Speicher Zeichen (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 zum Anzeigen von an den Computer angeschlossenen USB-Geräten.
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 zu identifizieren blaue Bildschirme(BSOD) muss den Speicherauszug 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 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.