Aktivieren des Postmortemdebuggings
Ausnahmebehandlung für den Benutzermodus
Ausnahmen und Haltepunkte
Die häufigsten Anwendungsfehler werden als Ausnahmen bezeichnet. Dazu gehören Zugriffsverletzungen, Division-by-Zero-Fehler, numerische Überläufe, CLR-Ausnahmen und viele andere Arten von Fehlern. Anwendungen können auch Unterbrechungen von Haltepunkten verursachen. Dies tritt auf, wenn Windows die Anwendung nicht ausführen kann (z. B. wenn ein erforderliches Modul nicht geladen werden kann) oder wenn ein Haltepunkt auftritt. Haltepunkte können durch einen Debugger in den Code eingefügt oder über eine Funktion wie DebugBreak aufgerufen werden.
Vorrang von Ausnahmehandlern
Basierend auf Konfigurationswerten und welchen Debuggern aktiv sind, behandelt Windows Benutzermodusfehler auf verschiedene Arten. Die folgende Sequenz zeigt die Rangfolge, die für die Fehlerbehandlung im Benutzermodus verwendet wird:
Wenn ein Benutzermodusdebugger derzeit an den fehlerhaften Prozess angefügt ist, führen alle Fehler dazu, dass das Ziel in diesen Debugger umgebrochen wird.
Solange der Debugger für den Benutzermodus angefügt ist, werden keine anderen Fehlerbehandlungsmethoden verwendet – auch wenn der Befehl gn (Mit Ausnahme nicht behandelt) verwendet wird.
Wenn kein Benutzermodusdebugger angefügt ist und der ausgeführte Code über eigene Ausnahmebehandlungsroutinen verfügt (z. B. try - außer), versucht diese Ausnahmebehandlungsroutine, den Fehler zu behandeln.
Wenn kein Benutzermodusdebugger angefügt ist und Windows über eine offene Kerneldebuggingverbindung verfügt, und der Fehler ist ein Haltepunktunterbruch, versucht Windows, den Kerneldebugger zu kontaktieren.
Kerneldebuggingverbindungen müssen während des Startvorgangs von Windows geöffnet werden. Wenn Sie verhindern möchten, dass ein Benutzermodusunterbrechung in den Kerneldebugger einbricht, können Sie das KDbgCtrl-Dienstprogramm mit dem Parameter "-du " verwenden. Ausführliche Informationen zum Konfigurieren von Kerneldebuggingverbindungen und zur Verwendung von KDbgCtrl finden Sie unter "Einrichten zum Debuggen".
Im Kerneldebugger können Sie gh (Go With Exception Handled) verwenden, um den Fehler zu ignorieren und das Ziel weiterhin auszuführen. Sie können gn (Go With Exception Not Handled) verwenden, um den Kerneldebugger zu umgehen und zu Schritt 4 zu wechseln.
Wenn die Bedingungen in Den Schritten 1, 2 und 3 nicht angewendet werden, aktiviert Windows ein Debuggingtool, das in den Registrierungswerten AeDebug konfiguriert ist. Jedes Programm kann vorab als Tool ausgewählt werden, das in dieser Situation verwendet werden soll. Das ausgewählte Programm wird als postmortem Debugger bezeichnet.
Wenn die Bedingungen in Den Schritten 1, 2 und 3 nicht angewendet werden, und es gibt keinen postmortem Debugger registriert, zeigt Windows-Fehlerberichterstattung (WER) eine Meldung an und bietet Lösungen, falls vorhanden. WER schreibt auch eine Speicherabbilddatei, wenn die entsprechenden Werte in der Registrierung festgelegt werden. Weitere Informationen finden Sie unter Verwenden von WER und Sammeln von User-Mode Dumps.
DebugBreak-Funktion
Wenn ein postmortem Debugger installiert wurde, können Sie den Debugger absichtlich aus einer Benutzermodusanwendung durch Aufrufen der DebugBreak-Funktion in den Debugger einbrechen.
Angeben eines Postmortem-Debuggers
In diesem Abschnitt wird beschrieben, wie Tools wie WinDbg als postmortem Debugger konfiguriert werden. Nach der Konfiguration wird der Postmortem-Debugger automatisch gestartet, wenn eine Anwendung abstürzt.
Registrierungsschlüssel nach Mortem-Debugger
Windows-Fehlerberichterstattung (WER) erstellt den Postmortem-Debuggerprozess mithilfe der Werte, die im Registrierungsschlüssel AeDebug festgelegt sind.
HKLM\Software\Microsoft\Windows NT\Currentversion\AeDebug
Es gibt zwei primäre Registrierungswerte von Interesse, Debugger und Auto. Der Debuggerregistrierungswert gibt die Befehlszeile für den postmortem Debugger an. Der Wert der automatischen Registrierung gibt an, ob der Postmortem-Debugger automatisch gestartet wird oder ein Bestätigungsmeldungsfeld zuerst angezeigt wird.
Debugger (REG_SZ)
Dieser REG_SZ Wert gibt den Debugger an, der das Postmortemdebugging behandelt.
Der vollständige Pfad zum Debugger muss aufgelistet werden, es sei denn, der Debugger befindet sich in einem Verzeichnis, das sich im Standardpfad befindet.
Die Befehlszeile wird aus der Debuggerzeichenfolge über einen Printf-Stilaufruf generiert, der 3 Parameter enthält. Obwohl die Reihenfolge behoben ist, muss keine oder alle verfügbaren Parameter verwendet werden.
DWORD (%ld) – Prozess-ID des Zielprozesses.
DWORD (%ld) – Ereignishandle, das in den postmortem Debuggerprozess dupliziert wurde. Wenn der Postmortemdebugger das Ereignis signalisiert, führt WER den Zielprozess fort, ohne auf das Beenden des Postmortem-Debuggers zu warten. Das Ereignis sollte nur signalisiert werden, wenn das Problem behoben wurde. Wenn der postmortem Debugger beendet wird, ohne das Ereignis zu signalisieren, setzt WER die Sammlung von Informationen über die Zielprozesse fort.
void* (%p) – Adresse einer JIT_DEBUG_INFO Struktur, die im Adressbereich des Zielprozesses zugeordnet ist. Die Struktur enthält zusätzliche Ausnahmeinformationen und den Kontext.
Auto (REG_SZ) Dieser REG_SZ Wert ist immer 0 oder 1.
Wenn "Auto " auf "0" festgelegt ist, wird ein Bestätigungsmeldungsfeld vor dem Start des postmortem Debuggingprozesses angezeigt.
Wenn auto auf 1 festgelegt ist, wird der Postmortem-Debugger sofort erstellt.
Wenn Sie die Registrierung manuell bearbeiten, gehen Sie dies sehr sorgfältig vor, da falsche Änderungen an der Registrierung möglicherweise windows nicht starten können.
Beispiel für die Befehlszeilenverwendung
Viele Postmortemdebugger verwenden eine Befehlszeile, die -p und -e-Schalter enthält, um anzugeben, dass die Parameter eine PID und ein Ereignis (bzw. ein Ereignis) sind. Das Installieren von WinDbg über windbg.exe -I erstellt beispielsweise die folgenden Werte:
Debugger = "<Path>\WinDbg -p %ld -e %ld -g"
Auto = 1
Es gibt Flexibilität, wie die PARAMETER WER %ld %ld %p verwendet werden können. Beispiel: es ist nicht erforderlich, Schalter um oder zwischen den WER-Parametern anzugeben. Beispielsweise erstellt die Installation von Windows Sysinternals ProcDump mithilfe procdump.exe -i der folgenden Werte ohne Schalter zwischen den WER%ld %ld %p-Parametern:
Debugger = "<Path>\procdump.exe" -accepteula -j "c:\Dumps" %ld %ld %p
Auto = 1
32- und 64-Bit-Debugger
Auf einer 64-Bit-Plattform werden die Registrierungswerte Für 64-Bit- und 32-Bit-Anwendungen (REG_SZ) und automatische Registrierungswerte (REG_SZ) einzeln definiert. Ein zusätzlicher Windows-Schlüssel unter Windows (WOW) wird verwendet, um die 32-Bit-Anwendungs-Post-Mortem-Debuggingwerte zu speichern.
HKLM\Software\Wow6432node\Microsoft\Windows NT\Currentversion\AeDebug
Verwenden Sie auf einer 64-Bit-Plattform einen 32-Bit-Debugger für 32-Bit-Prozesse und einen 64-Bit-Debugger für 64-Bit-Prozesse. Dadurch wird verhindert, dass sich ein 64-Bit-Debugger auf die WOW64-Threads konzentriert, statt auf die 32-Bit-Threads in einem 32-Bit-Prozess.
Für viele Postmortemdebugger, einschließlich der Debugtools für Windows-Postmortemdebugger, umfasst dies zweimal das Ausführen des Installationsbefehls; einmal mit der x86-Version und einmal mit der x64-Version. Wenn Sie beispielsweise WinDbg als interaktiven Postmortemdebugger verwenden möchten, wird der windbg.exe -I Befehl zweimal für jede Version ausgeführt.
64-Bit-Installation:
C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\windbg.exe –I
Dadurch wird der Registrierungsschlüssel mit diesen Werten aktualisiert.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug
Debugger = "C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\windbg.exe" -p %ld -e %ld –g
32-Bit-Installation:
C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\windbg.exe –I
Dadurch wird der Registrierungsschlüssel mit diesen Werten aktualisiert.
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug
Debugger = "C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\windbg.exe" -p %ld -e %ld –g
Konfigurieren von Post Mortem-Debuggern
Debuggingtools für Windows
Die Debugtools für Windows-Debugger unterstützen alle Unterstützungen, die als postmortem Debugger festgelegt werden. Der Installationsbefehl beabsichtigt, dass der Prozess interaktiv gedebuggt wird.
WinDbg
Führen Sie die Ausführung aus windbg -I, um den Postmortem-Debugger auf WinDbg festzulegen. (Die I muss großgeschrieben werden.) Dieser Befehl zeigt nach der Verwendung eine Erfolgs- oder Fehlermeldung an. Um mit 32- und 64-Bit-Anwendungen zu arbeiten, führen Sie den Befehl sowohl für die Debugger 64 als auch für 32 Debugger aus.
C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\windbg.exe –I
C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\windbg.exe –I
Dies ist, wie der AeDebug-Registrierungseintrag bei windbg -I der Ausführung konfiguriert wird.
Debugger = "<Path>\WinDbg -p %ld -e %ld -g"
Auto = 1
In den Beispielen <ist Path> das Verzeichnis, in dem sich der Debugger befindet.
Die Parameter "-p" und "-e" übergeben die Prozess-ID und das Ereignis, wie zuvor erläutert.
Der -g übergibt den Befehl g (Go) an WinDbg und setzt die Ausführung aus der aktuellen Anweisung fort.
Hinweis Es gibt ein erhebliches Problem, das den Befehl g (Go) übergibt. Das Problem mit diesem Ansatz besteht darin, dass Ausnahmen nicht immer wiederholt werden, in der Regel aufgrund einer vorübergehenden Bedingung, die nicht mehr vorhanden ist, wenn der Code neu gestartet wird. Weitere Informationen zu diesem Problem finden Sie unter .jdinfo (Verwenden von JIT_DEBUG_INFO).
Um dieses Problem zu vermeiden, verwenden Sie JDINFO oder .dump /j. Dieser Ansatz ermöglicht es dem Debugger, sich im Kontext des Codefehlers von Interesse zu befinden. Weitere Informationen finden Sie unter Just In Time (JIT) Debugging weiter unten in diesem Thema.
CDB
Um den postmortem Debugger auf CDB festzulegen, führen Sie cdb -iae (Install AeDebug) oder cdb -iaecKeyString (Install AeDebug with Command) aus.
C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\cdb.exe -iae
C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\cdb.exe -iae
Wenn der Parameter -iaec verwendet wird, gibt KeyString eine Zeichenfolge an, die an das Ende der Befehlszeile angefügt werden soll, die zum Starten des Postmortem-Debuggers verwendet wird. Wenn KeyString Leerzeichen enthält, muss sie in Anführungszeichen eingeschlossen werden.
C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\cdb.exe -iaec [KeyString]
C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\cdb.exe -iaec [KeyString]
Dieser Befehl zeigt nichts an, wenn er erfolgreich ist, und eine Fehlermeldung, wenn er fehlschlägt.
NTSD
Um den Postmortemdebugger auf NTSD festzulegen, führen Sie ntsd -iae (Install AeDebug) oder ntsd -iaecKeyString (Install AeDebug with Command) aus.
C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\ntsd.exe -iae
C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\ntsd.exe -iae
Wenn der Parameter -iaec verwendet wird, gibt KeyString eine Zeichenfolge an das Ende der Befehlszeile an, die zum Starten des Postmortem-Debuggers verwendet wird. Wenn KeyString Leerzeichen enthält, muss sie in Anführungszeichen eingeschlossen werden.
C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\ntsd.exe -iaec [KeyString]
C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\ntsd.exe -iaec [KeyString]
Dieser Befehl zeigt nichts an, wenn es erfolgreich ist, und ein Fehler beim Fehler eines neuen Konsolenfensters.
Hinweis Da die Parameter -p %ld -e %ld -g immer zuerst in der Befehlszeile des postmortem Debuggers angezeigt werden, sollten Sie den -iaec-Schalter nicht verwenden, um den -serverparameter anzugeben, da -server nicht funktioniert, es sei denn, es wird zuerst in der Befehlszeile angezeigt. Um einen postmortem Debugger zu installieren, der diesen Parameter enthält, müssen Sie die Registrierung manuell bearbeiten.
Visual Studio JIT-Debugger
Wenn Visual Studio installiert wurde, wird vsjitdebugger.exe als Post mortem-Debugger registriert. Der Visual Studio JIT-Debugger beabsichtigt, dass der Prozess interaktiv debuggen soll.
Debugger = "C:\WINDOWS\system32\vsjitdebugger.exe" -p %ld -e %ld
Wenn Visual Studio aktualisiert oder neu installiert wird, wird dieser Eintrag erneut geschrieben, überschreiben Sie alle alternativen Werte, die festgelegt sind.
Fenster Sysinternals ProcDump
Das Windows Sysinternals ProcDump-Hilfsprogramm kann auch für die Postmortem-Dumpaufnahme verwendet werden. Weitere Informationen zum Verwenden und Herunterladen von ProcDump finden Sie unter ProcDump.
Wie der Befehl ".dump WinDbg" kann ProcDump einen Dump des Absturzes nicht interaktiv erfassen. Die Aufnahme kann in jeder Windows-Systemsitzung auftreten.
ProcDump beendet, wenn die Dumpdateiaufnahme abgeschlossen ist, meldet WER dann den Fehler und den fehlerhaften Prozess wird beendet.
Verwenden Sie procdump -i die Installation von Procdump und -you, um ProcDump für das 32- und 64-Bit-Post mortem-Debugging zu deinstallieren.
<Path>\procdump.exe -i
Die Befehle zum Installieren und Deinstallieren geben die Registrierungswerte aus, die bei Erfolg geändert wurden, und die Fehler beim Fehler.
Die Befehlszeilenoptionen procDump in der Registrierung sind auf folgendes festgelegt:
Debugger = <Path>\ProcDump.exe -accepteula -j "<DumpFolder>" %ld %ld %p
ProcDump verwendet alle 3 Parameter – PID, Event und JIT_DEBUG_INFO. Weitere Informationen zum JIT_DEBUG_INFO-Parameter finden Sie unter " Just In Time" (JIT) Debug unten.
Die Größe der erfassten Dumpeinstellungen für Mini (Prozess/Threads/Handle/Module/Adressraum) ohne Größenoptionssatz, MiniPlus (Mini plus MEM_PRIVATE Seiten) mit -mp-Set oder Full (alle Speicher - entspricht ".dump /mA") mit -ma set.
Für Systeme mit ausreichendem Laufwerkspeicher wird eine Vollaufnahme (-ma) empfohlen.
Verwenden Sie -ma mit der Option -i, um eine alle Speicheraufnahme anzugeben. Geben Sie optional einen Pfad für die Dumpdateien an.
<Path>\procdump.exe -ma -i c:\Dumps
Für Systeme mit eingeschränktem Laufwerkspeicher wird eine MiniPlus-Aufnahme (mp) empfohlen.
<Path>\procdump.exe -mp -i c:\Dumps
Der Ordner zum Speichern der Dumpdatei ist optional. Der Standard ist der aktuelle Ordner. Der Ordner sollte mit einer ACL gesichert werden, die gleich oder besser ist als das, was für C:\Windows\Temp verwendet wird. Weitere Informationen zum Verwalten von Sicherheit im Zusammenhang mit Ordnern finden Sie unter Security Während des Postmortem-Debuggens.
Um ProcDump als postmortem Debugger zu deinstallieren und die vorherigen Einstellungen wiederherzustellen, verwenden Sie die Option -u (Deinstallieren).
<Path>\procdump.exe -u
Weitere Informationen zu ProcDump finden Sie unter ProcDump und Windows SysInternals Administratorreferenz von Mark Russinovich und Aaron Margosis, veröffentlicht von Microsoft Press.
Just In Time (JIT) Debugging
Festlegen des Kontexts auf die fehlerhafte Anwendung
Wie zuvor beschrieben, ist es sehr wünschenswert, den Kontext auf die Ausnahme festzulegen, die den Absturz mithilfe des JIT_DEBUG_INFO-Parameters verursacht hat. Weitere Informationen hierzu finden Sie unter .jdinfo (Verwenden von JIT_DEBUG_INFO).
Debuggingtools für Windows
In diesem Beispiel wird gezeigt, wie Sie die Registrierung bearbeiten, um einen anfänglichen Befehl (-c) auszuführen, der den Befehl "Jdinfo-Adresse<>" verwendet, um die zusätzlichen Ausnahmeinformationen anzuzeigen und den Kontext an den Speicherort der Ausnahme zu ändern (ähnlich wie .ecxr den Kontext auf den Ausnahmedatensatz festgelegt wird).
Debugger = "<Path>\windbg.exe -p %ld -e %ld -c ".jdinfo 0x%p"
Auto = 1
Der %p-Parameter ist die Adresse einer JIT_DEBUG_INFO Struktur im Adressraum des Zielvorgangs. Der %p-Parameter wird mit 0x angefügt, sodass er als Hexwert interpretiert wird. Weitere Informationen finden Sie unter .jdinfo (Verwenden JIT_DEBUG_INFO).
Um eine Mischung aus 32- und 64-Bit-Apps zu debuggen, konfigurieren Sie sowohl die 32- als auch die 64-Bit-Registrierungsschlüssel (oben beschrieben), indem Sie den richtigen Pfad zum Speicherort der 64-Bit- und 32-Bit-WinDbg.exe festlegen.
Erstellen einer Dumpdatei mithilfe von .dump
Um eine Dumpdatei zu erfassen, wenn ein Fehler auftritt, der die JIT_DEBUG_INFO-Daten enthält, verwenden Sie die .dump /j-Adresse<>.
<Path>\windbg.exe -p %ld -e %ld -c ".dump /j %p /u <DumpPath>\AeDebug.dmp; qd"
Verwenden Sie die Option "/u", um einen eindeutigen Dateinamen zu generieren, damit mehrere Dumpdateien automatisch erstellt werden können. Weitere Informationen zu den Optionen finden Sie unter .dump (Create Dump File).
Der erstellte Dump enthält die JITDEBUG_INFO Daten, die als Standardausnahmekontext gespeichert sind. Verwenden Sie stattdessen .jdinfo, um die Ausnahmeinformationen anzuzeigen und den Kontext festzulegen, verwenden Sie .exr -1, um den Ausnahmedatensatz und .ecxr anzuzeigen, um den Kontext festzulegen. Weitere Informationen finden Sie unter .exr (Display Exception Record) und .ecxr (Display Exception Context Record).
Windows-Fehlerberichterstattung - q / qd
Die Art und Weise, wie die Debugsitzung endet, bestimmt, ob Windows-Fehlerberichterstattung den Fehler meldet.
Wenn die Debugsitzung mit qd vor dem Schließen des Debuggers getrennt wird, meldet WER den Fehler.
Wenn die Debugsitzung mit q beendet wird (oder wenn der Debugger ohne Trennzeichen geschlossen wird), meldet WER den Fehler nicht.
Fügen Sie ;q oder ;qd am Ende der Befehlszeichenfolge an, um das gewünschte Verhalten aufzurufen.
Um beispielsweise zu ermöglichen, dass WER den Fehler meldet, nachdem CDB einen Dump erfasst hat, konfigurieren Sie diese Befehlszeichenfolge.
<Path>\cdb.exe -p %ld -e %ld -c ".dump /j 0x%p /u c:\Dumps\AeDebug.dmp; qd"
In diesem Beispiel könnte WER den Fehler melden, nachdem WinDbg einen Dump erfasst hat.
<Path>\windbg.exe -p %ld -e %ld -c ".dump /j %p /u <DumpPath>\AeDebug.dmp; qd""
Sicherheitsrisiken
Wenn Sie die Aktivierung des Postmortem-Debuggens auf einem Computer berücksichtigen, den Sie für andere Personen freigeben, finden Sie unter Security Während des Postmortem-Debuggens.