Steuern von Ausnahmen und Ereignissen

Artikel
10/26/2023

Sie können Ausnahmen in Benutzermodus- und Kernelmodusanwendungen mit einer Vielzahl von Methoden abfangen und behandeln. Ein aktiver Debugger, ein Postmortemdebugger oder eine interne Fehlerbehandlungsroutine sind gängige Methoden zum Behandeln von Ausnahmen.

Weitere Informationen zur Rangfolge dieser verschiedenen Ausnahmehandler finden Sie unter Aktivieren des Postmortemdebuggens.

Wenn das Microsoft Windows-Betriebssystem einem Debugger die Behandlung einer Ausnahme zulässt, wird die Anwendung, die die Ausnahme generiert hat, in den Debugger unterteilt . Das heißt, die Anwendung wird beendet, und der Debugger wird aktiv. Der Debugger kann dann die Ausnahme in irgendeiner Weise behandeln oder die Situation analysieren. Der Debugger kann dann den Prozess beenden oder die Ausführung fortsetzen lassen.

Wenn der Debugger die Ausnahme ignoriert und die Anwendung weiterhin ausführen lässt, sucht das Betriebssystem nach anderen Ausnahmehandlern, als ob kein Debugger vorhanden wäre. Wenn die Ausnahme behandelt wird, wird die Anwendung weiterhin ausgeführt. Wenn die Ausnahme jedoch nicht behandelt wird, erhält der Debugger eine zweite Gelegenheit, sich mit der Situation zu befassen.

Verwenden des Debuggers zum Analysieren einer Ausnahme

Wenn eine Ausnahme oder ein Ereignis in den Debugger einbricht, können Sie den Debugger verwenden, um den ausgeführten Code und den von der Anwendung verwendeten Arbeitsspeicher zu untersuchen. Wenn Sie bestimmte Mengen ändern oder zu einem anderen Punkt in der Anwendung springen, können Sie möglicherweise die Ursache der Ausnahme entfernen.

Sie können die Ausführung fortsetzen, indem Sie einen Befehl gh (Go with Exception Handled) oder gn (Go with Exception Not Handled) ausgeben.

Wenn Sie den gn-Befehl in der zweiten Gelegenheit des Debuggers ausgeben, um die Ausnahme zu behandeln, wird die Anwendung beendet.

Kernelmodusausnahmen

Ausnahmen, die im Kernelmoduscode auftreten, sind schwerwiegender als Benutzermodusausnahmen. Wenn Kernelmodusausnahmen nicht behandelt werden, wird eine Fehlerüberprüfung durchgeführt, und das System wird beendet.

Wie bei Benutzermodusausnahmen wird der Debugger benachrichtigt, wenn ein Kernelmodusdebugger an das System angefügt ist, bevor der Fehlerüberprüfungsbildschirm (auch als Bluescreen bezeichnet) angezeigt wird. Wenn kein Debugger angefügt ist, wird der Fehlerüberprüfungsbildschirm angezeigt. In diesem Fall erstellt das Betriebssystem möglicherweise eine Absturzabbilddatei.

Steuern von Ausnahmen und Ereignissen über den Debugger

Sie können den Debugger so konfigurieren, dass er auf bestimmte Ausnahmen und Ereignisse auf bestimmte Weise reagiert.

Der Debugger kann den Umbruch status für jede Ausnahme oder jedes Ereignis festlegen:

Das Ereignis kann zu einem Break in den Debugger führen, sobald es auftritt (die "erste Chance").
Das Ereignis kann einbrechen, nachdem anderen Fehlerhandlern die Möglichkeit gegeben wurde, zu reagieren (die "zweite Chance").
Das Ereignis kann dem Debugger auch eine Nachricht senden, aber weiterhin ausgeführt werden.
Der Debugger kann das Ereignis ignorieren.

Der Debugger kann auch die Behandlung status für jede Ausnahme und jedes Ereignis festlegen. Der Debugger kann das Ereignis wie eine behandelte Ausnahme oder eine nicht behandelte Ausnahme behandeln. (Natürlich erfordern Ereignisse, die nicht tatsächlich Fehler sind, keine Behandlung.)

Sie können die Unterbrechung status und die Behandlung status steuern, indem Sie eine der folgenden Aktionen ausführen:

Verwenden Sie den Befehl SXE, SXD, SXN oder SXI im Fenster Debuggerbefehl.
(CDB und NTSD) Verwenden Sie die Option -x, -xe, -xd, -xn oder -xi in der Befehlszeile.
(CDB, NTSD und KD) Verwenden Sie die sxe- oder sxd-Schlüsselwort (keyword) in der Tools.ini-Datei.
(Nur WinDbg) Wählen Sie im Menü Debuggen die Option Ereignisfilter aus, um das Dialogfeld Ereignisfilter zu öffnen, und wählen Sie dann die gewünschten Optionen aus.

Der SX\*-Befehl, die Befehlszeilenoption -x\* und die sx\*-Tools.ini Schlüsselwort (keyword) in der Regel den Umbruch status des angegebenen Ereignisses festlegen. Sie können die Option -h hinzufügen, um stattdessen die Behandlung status festzulegen.

Es gibt vier spezielle Ereigniscodes (cc, hc, bpec und ssec), die immer die Behandlung status anstelle von Break status angeben.

Sie können die letzte Ausnahme oder das letzte Ereignis anzeigen, indem Sie den Befehl .lastevent (Letztes Ereignis anzeigen) verwenden.

Steuern des Unterbrechungsstatus

Wenn Sie den Umbruch status einer Ausnahme oder eines Ereignisses festlegen, können Sie die folgenden Optionen verwenden.

Get-Help	Statusname	BESCHREIBUNG
SXE oder -xe	Break (Aktiviert)	Wenn diese Ausnahme auftritt, bricht das Ziel sofort in den Debugger ein. Dieser Umbruch tritt auf, bevor andere Fehlerhandler aktiviert werden. Diese Methode wird als First-Chance-Handling bezeichnet.
SXD oder -xd	Pause der zweiten Chance (Deaktiviert)	Der Debugger wird für diese Art von Ausnahme beim ersten Zufall nicht eingebrochen (obwohl eine Meldung angezeigt wird). Wenn andere Fehlerhandler diese Ausnahme nicht beheben können, wird die Ausführung beendet, und das Ziel wird in den Debugger unterteilt. Diese Methode wird als Behandlung mit zweiter Chance bezeichnet.
SXN oder -xn	Ausgabe (Benachrichtigen)	Wenn diese Ausnahme auftritt, bricht die Zielanwendung überhaupt nicht in den Debugger ein. Es wird jedoch eine Meldung angezeigt, die den Benutzer über diese Ausnahme informiert.
SXI oder -xi	Ignorieren	Wenn diese Ausnahme auftritt, wird die Zielanwendung nicht in den Debugger eingebrochen, und es wird keine Meldung angezeigt.

Wenn von einer SX*-Einstellung keine Ausnahme erwartet wird, bricht die Zielanwendung bei der zweiten Chance in den Debugger ein. Die Standard-status für Ereignisse ist im folgenden Abschnitt "Ereignisdefinitionen und Standardwerte" dieses Themas aufgeführt.

Um den Break status mithilfe der grafischen WinDbg-Benutzeroberfläche festzulegen, wählen Sie im Menü Debuggen das gewünschte Ereignis aus der Liste im Dialogfeld Ereignisfilter aus, und wählen Sie dann Aktiviert, Deaktiviert, Ausgabe oder Ignorieren aus.

Steuern des Bearbeitungsstatus

Alle Ereignisse gelten als unbehandelt, es sei denn, Sie verwenden den Befehl gh (Go with Exception Handled).

Alle Ausnahmen gelten als unbehandelt, es sei denn, Sie verwenden den Befehl sx\* zusammen mit der Option -h .

Darüber hinaus können SX*-Optionen die Status für ungültige Handles, STATUS_BREAKPOINT Unterbrechungsanweisungen und Einzelschrittausnahmen konfigurieren. (Diese Konfiguration ist von ihrer Unterbrechungskonfiguration getrennt.) Wenn Sie deren Umbruch status konfigurieren, werden diese Ereignisse ch, bpe bzw. sse genannt. Wenn Sie deren Verarbeitung status konfigurieren, werden diese Ereignisse hc, bpec bzw. ssec genannt. (Eine vollständige Auflistung der Ereignisse finden Sie im folgenden Abschnitt "Ereignisdefinitionen und -standardwerte".)

Sie können die Verarbeitung status für das STRG+C-Ereignis (cc) konfigurieren, aber nicht dessen Umbruch status. Wenn eine Anwendung ein STRG+C-Ereignis empfängt, wird die Anwendung immer in den Debugger unterteilt.

Wenn Sie den SX*-Befehl für cc-, hc-, bpec- und ssec-Ereignisse verwenden oder den SX*-Befehl zusammen mit der Option -h für eine Ausnahme verwenden, treten die folgenden Aktionen auf.

Get-Help	Statusname	BESCHREIBUNG
SXE	Verarbeitete	Das Ereignis gilt als behandelt, wenn die Ausführung fortgesetzt wird.
SXD,SXN,SXI	Nicht verarbeitet	Das Ereignis gilt als nicht behandelt, wenn die Ausführung fortgesetzt wird.

Um die Verarbeitung status mithilfe der grafischen WinDbg-Benutzeroberfläche festzulegen, wählen Sie im Menü Debuggendie Option Ereignisfilter aus, wählen Sie das gewünschte Ereignis aus der Liste im Dialogfeld Ereignisfilter aus, und wählen Sie dann Behandelt oder Nicht verarbeitet aus.

Automatische Befehle

Mit dem Debugger können Sie auch Befehle festlegen, die automatisch ausgeführt werden, wenn das Ereignis oder die Ausnahme einen Umbruch in den Debugger verursacht. Sie können eine Befehlszeichenfolge für die erste Chance und eine Befehlszeichenfolge für die zweite Chance festlegen. Sie können diese Zeichenfolgen mit dem Befehl SX\* oder debuggen | Ereignisfilterbefehl . Jede Befehlszeichenfolge kann mehrere Befehle enthalten, die durch Semikolons getrennt sind.

Diese Befehle werden unabhängig von der unterbrechungsfreien status ausgeführt. Das heißt, wenn der Break status "Ignore" lautet, wird der Befehl weiterhin ausgeführt. Wenn der Break status "Second-chance break" ist, wird der Erste-Chance-Befehl ausgeführt, wenn die Ausnahme zum ersten Mal auftritt, bevor andere Ausnahmehandler beteiligt sind. Die Befehlszeichenfolge kann mit einem Ausführungsbefehl wie g (Go), gh (Go with Exception Handled) oder gn (Go with Exception Not Handled) enden.

Ereignisdefinitionen und -standardwerte

Sie können die Unterbrechung status ändern oder status der folgenden Ausnahmen behandeln. Die Standardunterbrechung status wird angegeben.

Die Standardbehandlung der folgenden Ausnahmen status ist immer "Not Handled". Achten Sie darauf, diese status zu ändern. Wenn Sie diese status in "Handled" ändern, werden alle Ausnahmen dieses Typs der ersten und zweiten Chance als behandelt betrachtet, und diese Konfiguration umgeht alle Ausnahmebehandlungsroutinen.

Ereigniscode	Bedeutung	Standardunterbrechungs-status
asrt	Assertionsfehler	Break
av	Zugriffsverletzung	Break
Dm	Falsch ausgerichtete Daten	Break
dz	Ganzzahlige Division durch 0 (Null)	Break
c000008e	Gleitkommateilung durch 0 (Null)	Break
eh	C++-EH-Ausnahme	Pause der zweiten Chance
Gp	Schutzseitenverletzung	Break
Ii	Ungültige Anweisung	Pause der zweiten Chance
Iov	Ganzzahliger Überlauf	Break
Ip	In-Page-E/A-Fehler	Break
Isc	Ungültiger Systemaufruf	Break
lsq	Ungültige Sperrsequenz	Break
Sbo	Stack buffer overflow (Stapelpufferüberlauf)	Break
Sov	Stapelüberlauf	Break
Wkd	Aktivierungsdebugger	Break
Aph	Anwendungshänger Diese Ausnahme wird ausgelöst, wenn das Windows-Betriebssystem zu dem Schluss kommt, dass ein Prozess nicht mehr reagiert (d. h. nicht mehr reagiert).	Break
3c	Beendigung der Untergeordneten Anwendung	Pause der zweiten Chance
chhc	Ungültiges Handle	Break
Number	Beliebige nummerierte Ausnahme	Pause der zweiten Chance

Hinweis Sie können den asrt-Break status für eine bestimmte Adresse überschreiben, indem Sie den Befehl ah (Assertionsbehandlung) verwenden. Die Ereigniscodes ch und hc verweisen auf dieselbe Ausnahme. Wenn Sie den Break status steuern, verwenden Sie sx* ch. Wenn Sie die Verarbeitung status steuern, verwenden Sie sx* hc.

Sie können die Unterbrechung status ändern oder status der folgenden Ausnahmen behandeln. Die Standardunterbrechung status wird angegeben.

Die standardhandhabbaren status der folgenden Ausnahmen lautet immer "Handled". Da diese Ausnahmen für die Kommunikation mit dem Debugger verwendet werden, sollten Sie ihre status in der Regel nicht in "Nicht behandelt" ändern. Diese status bewirkt, dass andere Ausnahmehandler die Ausnahmen abfangen, wenn der Debugger sie ignoriert.

Eine Anwendung kann DBG_COMMAND_EXCEPTION (dbce) verwenden, um mit dem Debugger zu kommunizieren. Diese Ausnahme ähnelt einem Haltepunkt, aber Sie können den SX*-Befehl verwenden, um auf eine bestimmte Weise zu reagieren, wenn diese Ausnahme auftritt.

Ereigniscode	Bedeutung	Standardunterbrechungs-status
dbce	Ausnahme für spezielle Debuggerbefehle	Ignorieren
vcpp	Spezielle Visual C++-Ausnahme	Ignorieren
Wos	WOW64-Ausnahme in einem schritt	Break
Wob	WOW64-Breakpoint-Ausnahme:	Break
Sse ssec	Einzelschritt-Ausnahme	Break
Bpe bpec	Breakpoint-Ausnahme	Break
Cce Cc	STRG+C oder STRG+BREAK Diese Ausnahme wird ausgelöst, wenn das Ziel eine Konsolenanwendung ist und STRG+C oder STRG+BREAK an das Ziel übergeben wird.	Break

Hinweis Die letzten drei Ausnahmen in der vorherigen Tabelle weisen zwei unterschiedliche Ereigniscodes auf. Wenn Sie deren Unterbrechung status steuern, verwenden Sie sse, bpe und cce. Wenn Sie die Verarbeitung status steuern, verwenden Sie ssec, bpec und cc.

Die folgenden Ausnahmen sind nützlich, wenn Sie verwalteten Code debuggen.

Ereigniscode	Bedeutung	Standard status
Clr	Common Language Runtime-Ausnahme	Pause mit zweiter Chance Nicht verarbeitet
clrn	Common Language Runtime-Ausnahme für Benachrichtigungen	Pause mit zweiter Chance Verarbeitete

Clr

Common Language Runtime-Ausnahme

Pause mit zweiter Chance

Nicht verarbeitet

clrn

Common Language Runtime-Ausnahme für Benachrichtigungen