Freigeben über


Steuern von Ausnahmen und Ereignissen

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

Sie können den Umbruch status der folgenden Ereignisse ändern. Da es sich bei diesen Ereignissen nicht um Ausnahmen handelt, ist ihre Behandlung status irrelevant.

Ereigniscode Bedeutung Standardunterbrechung status

ser

Systemfehler

Ignorieren

cpr[:Process]

Prozesserstellung

Das Festlegen des Umbruchs status dieses Ereignisses gilt nur für das Debuggen im Benutzermodus. Dieses Ereignis tritt im Kernelmodus nicht auf.

Sie können dieses Ereignis nur steuern, wenn Sie das Debuggen untergeordneter Prozesse in CDB oder WinDbg aktiviert haben, entweder über dieBefehlszeilenoption -o oder über den Befehl .childdbg (Untergeordnete Prozesse debuggen).

Der Prozessname kann eine optionale Dateinamenerweiterung und ein Sternchen () oder Ein Fragezeichen (?) als Platzhalterzeichen enthalten. Der Debugger speichert nur die neueste cpr-Einstellung . Separate Einstellungen für separate Prozesse werden nicht unterstützt. Schließen Sie einen Doppelpunkt oder ein Leerzeichen zwischen cpr und Process ein.

Wenn Process nicht angegeben wird, gilt die Einstellung für alle untergeordneten Prozesserstellungen.

Ignorieren

epr[:Process]

Prozessausgang

Das Festlegen des Umbruchs status dieses Ereignisses gilt nur für das Debuggen im Benutzermodus. Dieses Ereignis tritt im Kernelmodus nicht auf.

Sie können dieses Ereignis nur steuern, wenn Sie das Debuggen untergeordneter Prozesse in CDB oder WinDbg aktiviert haben, entweder über dieBefehlszeilenoption -o oder über den Befehl .childdbg (Untergeordnete Prozesse debuggen).

Der Prozessname kann eine optionale Dateinamenerweiterung und ein Sternchen () oder Ein Fragezeichen (?) als Platzhalterzeichen enthalten. Der Debugger merkt sich nur die letzte epr-Einstellung . Separate Einstellungen für separate Prozesse werden nicht unterstützt. Schließen Sie einen Doppelpunkt oder ein Leerzeichen zwischen epr und Process ein.

Wenn Process nicht angegeben wird, gilt die Einstellung für jeden untergeordneten Prozessausgang.

Ignorieren

ct

Threaderstellung

Ignorieren

et

Threadausgang

Ignorieren

ld[:Module]

Modul laden

Wenn Sie Modul angeben, tritt der Umbruch auf, wenn das Modul mit diesem Namen geladen wird. Das Modul kann den Namen oder die Adresse des Moduls angeben. Wenn der Name verwendet wird, kann Module eine Vielzahl von Feldhalterzeichen und Bezeichnern enthalten. (Weitere Informationen zur Syntax finden Sie unter Zeichenfolgenplatzhaltersyntax.)

Der Debugger merkt sich nur die letzte ld-Einstellung . Separate Einstellungen für separate Module werden nicht unterstützt. Schließen Sie einen Doppelpunkt oder ein Leerzeichen zwischen ld und Module ein.

Wenn Module ausgelassen wird, wird das Ereignis ausgelöst, wenn ein Beliebiges Modul geladen wird.

Ausgabe

ud[:Module]

Modul entladen

Wenn Sie Modul angeben, tritt der Umbruch auf, wenn das Modul mit diesem Namen oder an dieser Basisadresse entladen wird. Das Modul kann den Namen oder die Adresse des Moduls angeben. Wenn der Name verwendet wird, kann Module ein exakter Name sein oder Einen Feldhalter enthalten. Wenn Module ein exakter Name ist, wird es mithilfe der aktuellen Debuggermodulliste sofort in eine Basisadresse aufgelöst und als Adresse gespeichert. Wenn Module Einen Feldhalter enthält, wird die Musterzeichenfolge für einen späteren Abgleich beibehalten, wenn Entladensereignisse auftreten.

Selten verfügt der Debugger über keine Namensinformationen für Entladen von Ereignissen und stimmt nur mit der Basisadresse überein. Wenn Module daher Einen Feldhalter enthält, kann der Debugger in diesem speziellen Entladefall keine Namensgleichung durchführen und unterbricht, wenn ein Modul entladen wird.

Der Debugger erinnert sich nur an die neueste ud-Einstellung . Separate Einstellungen für separate Module werden nicht unterstützt. Schließen Sie einen Doppelpunkt oder ein Leerzeichen zwischen ud und Module ein.

Wenn Module ausgelassen wird, wird das Ereignis ausgelöst, wenn ein Beliebiges Modul geladen wird.

Ausgabe

out[:Output]

Zielanwendungsausgabe

Wenn Sie Ausgabe angeben, tritt der Umbruch nur auf, wenn eine Ausgabe empfangen wird, die dem angegebenen Muster entspricht. Die Ausgabe kann eine Vielzahl von Wildcardzeichen und Bezeichnern enthalten. (Weitere Informationen zur Syntax finden Sie unter Zeichenfolgenplatzhaltersyntax.) Die Ausgabe darf jedoch keinen Doppelpunkt oder Leerzeichen enthalten. Bei der Eingabe wird nicht nach Groß- und Kleinschreibung unterschieden. Schließen Sie einen Doppelpunkt oder leer zwischen out und Output ein.

Ignorieren

Ibp

Anfänglicher Haltepunkt

(Dieses Ereignis tritt zu Beginn der Debugsitzung und nach dem Neustart des Zielcomputers auf.)

Im Benutzermodus: Brechen. Sie können diese status in "Ignorieren" ändern, indem Sie die Befehlszeilenoption-g verwenden.

Im Kernelmodus: Ignorieren. Sie können diese status mit einer Vielzahl von Methoden in "Aktiviert" ändern. Weitere Informationen zum Ändern dieser status finden Sie unter Absturz und Neustart des Zielcomputers.

Iml

Anfängliches Laden des Moduls

(Nur Kernelmodus)

Ignorieren. Sie können diese status mit einer Vielzahl von Methoden in "Break" ändern. Weitere Informationen zum Ändern dieser status finden Sie unter Absturz und Neustart des Zielcomputers.