Verwenden der !analyze-Erweiterung
Der erste Schritt beim Debuggen eines abgestürzten Zielcomputers oder einer abgestürzten Anwendung besteht darin, den Erweiterungsbefehl !analyze zu verwenden. Diese Erweiterung führt eine große Menge an automatisierten Analysen durch. Die Ergebnisse dieser Analyse werden im Fenster Debuggerbefehl angezeigt.
Sie sollten die Option -v für eine vollständig ausführliche Anzeige von Daten verwenden. Ausführliche Informationen zu anderen Optionen finden Sie auf der !analyze-Referenzseite .
Ein User-Mode !analyze -v Beispiel
In diesem Beispiel wird der Debugger an eine Anwendung im Benutzermodus angefügt, bei der eine Ausnahme aufgetreten ist.
0:000> !analyze -v
*******************************************************************************
* *
* Exception Analysis *
* *
*******************************************************************************
Debugger SolutionDb Connection::Open failed 80004005
Wenn Sie mit dem Internet verbunden sind, versucht der Debugger, auf eine Datenbank mit Absturzlösungen zuzugreifen, die von Microsoft verwaltet werden. In diesem Fall wurde eine Fehlermeldung angezeigt, die angibt, dass entweder Ihr Computer nicht auf das Internet zugreifen konnte oder dass die Website nicht funktionierte.
FAULTING_IP:
ntdll!PropertyLengthAsVariant+73
77f97704 cc int 3
Das Feld FAULTING_IP zeigt den Anweisungszeiger zum Zeitpunkt des Fehlers an.
EXCEPTION_RECORD: ffffffff -- (.exr ffffffffffffffff)
ExceptionAddress: 77f97704 (ntdll!PropertyLengthAsVariant+0x00000073)
ExceptionCode: 80000003 (Break instruction exception)
ExceptionFlags: 00000000
NumberParameters: 3
Parameter[0]: 00000000
Parameter[1]: 00010101
Parameter[2]: ffffffff
Das Feld EXCEPTION_RECORD zeigt den Ausnahmedatensatz für diesen Absturz an. Diese Informationen können auch mit dem Befehl .exr (Ausnahmedatensatz anzeigen) angezeigt werden.
BUGCHECK_STR: 80000003
Das Feld BUGCHECK_STR zeigt den Ausnahmecode an. Der Name ist eine falsche Bezeichnung– der Begriff Fehlerüberprüfung bedeutet tatsächlich einen Kernelmodusabsturz. Beim Debuggen im Benutzermodus wird der Ausnahmecode angezeigt, in diesem Fall 0x80000003.
DEFAULT_BUCKET_ID: APPLICATION_FAULT
Das Feld DEFAULT_BUCKET_ID zeigt die allgemeine Fehlerkategorie an, zu der dieser Fehler gehört.
PROCESS_NAME: MyApp.exe
Das Feld PROCESS_NAME gibt den Namen des Prozesses an, der die Ausnahme ausgelöst hat.
LAST_CONTROL_TRANSFER: from 01050963 to 77f97704
Das Feld LAST_CONTROL_TRANSFER zeigt den letzten Aufruf auf dem Stapel an. In diesem Fall 0x01050963 der Code an der Adresse eine Funktion bei 0x77F97704 aufgerufen. Sie können diese Adressen mit dem Befehl ln (List Nearest Symbols) verwenden, um zu bestimmen, in welchen Modulen und Funktionen sich diese Adressen befinden.
STACK_TEXT:
0006b9dc 01050963 00000000 0006ba04 000603fd ntdll!PropertyLengthAsVariant+0x73
0006b9f0 010509af 00000002 0006ba04 77e1a449 MyApp!FatalErrorBox+0x55 [D:\source_files\MyApp\util.c @ 541]
0006da04 01029f4e 01069850 0000034f 01069828 MyApp!ShowAssert+0x47 [D:\source_files\MyApp\util.c @ 579]
0006db6c 010590c3 000e01ea 0006fee4 0006feec MyApp!SelectColor+0x103 [D:\source_files\MyApp\colors.c @ 849]
0006fe04 77e11d0a 000e01ea 00000111 0000413c MyApp!MainWndProc+0x1322 [D:\source_files\MyApp\MyApp.c @ 1031]
0006fe24 77e11bc8 01057da1 000e01ea 00000111 USER32!UserCallWinProc+0x18
0006feb0 77e172b4 0006fee4 00000001 010518bf USER32!DispatchMessageWorker+0x2d0
0006febc 010518bf 0006fee4 00000000 01057c5d USER32!DispatchMessageA+0xb
0006fec8 01057c5d 0006fee4 77f82b95 77f83920 MyApp!ProcessQCQPMessage+0x3b [D:\source_files\MyApp\util.c @ 2212]
0006ff70 01062cbf 00000001 00683ed8 00682b88 MyApp!main+0x1e6 [D:\source_files\MyApp\MyApp.c @ 263]
0006ffc0 77e9ca90 77f82b95 77f83920 7ffdf000 MyApp!mainCRTStartup+0xff [D:\source_files\MyApp\crtexe.c @ 338]
0006fff0 00000000 01062bc0 00000000 000000c8 KERNEL32!BaseProcessStart+0x3d
Das Feld STACK_TEXT zeigt eine Stapelablaufverfolgung der fehlerhaften Komponente an.
FOLLOWUP_IP:
MyApp!FatalErrorBox+55
01050963 5e pop esi
FOLLOWUP_NAME: dbg
SYMBOL_NAME: MyApp!FatalErrorBox+55
MODULE_NAME: MyApp
IMAGE_NAME: MyApp.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 383490a9
Wenn !analyze die Anweisung bestimmt, die den Fehler wahrscheinlich verursacht hat, wird sie im Feld FOLLOWUP_IP angezeigt. Die Felder SYMBOL_NAME, MODULE_NAME, IMAGE_NAME und DEBUG_FLR_IMAGE_TIMESTAMP zeigen das Symbol, das Modul, den Bildnamen und den Bildzeitstempel an, der dieser Anweisung entspricht.
STACK_COMMAND: .ecxr ; kb
Das Feld STACK_COMMAND zeigt den Befehl an, der zum Abrufen des STACK_TEXT verwendet wurde. Mit diesem Befehl können Sie diese Stapelablaufverfolgungsanzeige wiederholen oder ändern, um verwandte Stapelinformationen abzurufen.
BUCKET_ID: 80000003_MyApp!FatalErrorBox+55
Das Feld BUCKET_ID zeigt die spezifische Fehlerkategorie an, zu der der aktuelle Fehler gehört. Mit dieser Kategorie kann der Debugger ermitteln, welche weiteren Informationen in der Analyseausgabe angezeigt werden sollen.
Followup: dbg
---------
Informationen zu den Feldern FOLLOWUP_NAME und Nachverfolgung finden Sie unter Das Nachverfolgungsfeld und die triage.ini-Datei.
Es gibt eine Vielzahl weiterer Felder, die angezeigt werden können:
Wenn das Steuerelement an eine ungültige Adresse übertragen wurde, enthält das Feld FAULTING_IP diese ungültige Adresse. Anstelle des felds FOLLOWUP_IP zeigt das Feld FAILED_INSTRUCTION_ADDRESS den zerlegten Code dieser Adresse an, obwohl diese Disassemblierung wahrscheinlich bedeutungslos ist. In dieser Situation verweisen die Felder SYMBOL_NAME, MODULE_NAME, IMAGE_NAME und DEBUG_FLR_IMAGE_TIMESTAMP auf den Aufrufer dieser Anweisung.
Wenn der Prozessor fehlgeht, werden möglicherweise die Felder SINGLE_BIT_ERROR, TWO_BIT_ERROR oder POSSIBLE_INVALID_CONTROL_TRANSFER angezeigt.
Wenn speicherbeschädigungen aufgetreten sind, gibt das Feld CHKIMG_EXTENSION den Erweiterungsbefehl !chkimg an, der für die Untersuchung verwendet werden soll.
Ein Kernel-Mode !analyze -v Beispiel
In diesem Beispiel wird der Debugger an einen Computer angefügt, der gerade abgestürzt ist.
kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pagable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Das erste Element der Anzeige zeigt den Fehlerprüfungscode und Informationen zu dieser Art von Fehlerprüfung an. Einige der angezeigten Texte gelten möglicherweise nicht für diese spezifische instance. Weitere Informationen zu den einzelnen Fehlerüberprüfungen finden Sie im Abschnitt Fehlerüberprüfungscodereferenz .
Arguments:
Arg1: 00000004, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, value 0 = read operation, 1 = write operation
Arg4: f832035c, address which referenced memory
Die Fehlerüberprüfungsparameter werden als Nächstes angezeigt. Ihnen folgt jeweils eine Beschreibung. Der dritte Parameter ist z. B. 1, und im folgenden Kommentar wird erläutert, dass dies darauf hindeutet, dass ein Schreibvorgang fehlgeschlagen ist.
## Debugging Details:
WRITE_ADDRESS: 00000004 Nonpaged pool
CURRENT_IRQL: 2
Die nächsten Felder variieren je nach Art des Absturzes. In diesem Fall werden WRITE_ADDRESS und CURRENT_IRQL Felder angezeigt. Dabei werden einfach die Informationen neu angegeben, die in den Fehlerüberprüfungsparametern angezeigt werden. Wenn Sie die Anweisung "Nonpaged pool" mit dem Fehlerüberprüfungstext vergleichen, der lautet: "Es wurde versucht, auf eine pagbare (oder vollständig ungültige) Adresse zuzugreifen", können wir feststellen, dass die Adresse ungültig war. Die ungültige Adresse wurde in diesem Fall 0x00000004.
FAULTING_IP:
USBPORT!USBPORT_BadRequestFlush+7c
f832035c 894204 mov [edx+0x4],eax
Das Feld FAULTING_IP zeigt den Anweisungszeiger zum Zeitpunkt des Fehlers an.
DEFAULT_BUCKET_ID: DRIVER_FAULT
Das Feld DEFAULT_BUCKET_ID zeigt die allgemeine Fehlerkategorie an, zu der dieser Fehler gehört.
BUGCHECK_STR: 0xD1
Das Feld BUGCHECK_STR zeigt den Code der Fehlerüberprüfung an, den wir bereits gesehen haben. In einigen Fällen werden zusätzliche Triageinformationen angefügt.
TRAP_FRAME: f8950dfc -- (.trap fffffffff8950dfc)
.trap fffffffff8950dfc
ErrCode = 00000002
eax=81cc86dc ebx=81cc80e0 ecx=81e55688 edx=00000000 esi=81cc8028 edi=8052cf3c
eip=f832035c esp=f8950e70 ebp=f8950e90 iopl=0 nv up ei pl nz ac po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010216
USBPORT!USBPORT_BadRequestFlush+7c:
f832035c 894204 mov [edx+0x4],eax ds:0023:00000004=????????
.trap
Resetting default context
Das Feld TRAP_FRAME zeigt den Trapframe für diesen Absturz an. Diese Informationen können auch mit dem Befehl TRAP (Trap Frame anzeigen) angezeigt werden.
LAST_CONTROL_TRANSFER: from f83206e0 to f832035c
Das Feld LAST_CONTROL_TRANSFER zeigt den letzten Aufruf auf dem Stapel an. In diesem Fall 0xF83206E0 der Code an der Adresse eine Funktion bei 0xF832035C aufgerufen. Sie können den Befehl ln (List Nearest Symbols) verwenden, um zu bestimmen, in welchem Modul und welcher Funktion sich diese Adressen befinden.
STACK_TEXT:
f8950e90 f83206e0 024c7262 00000000 f8950edc USBPORT!USBPORT_BadRequestFlush+0x7c
f8950eb0 804f5561 81cc8644 81cc8028 6d9a2f30 USBPORT!USBPORT_DM_TimerDpc+0x10c
f8950fb4 804f5644 6e4be98e 00000000 ffdff000 nt!KiTimerListExpire+0xf3
f8950fe0 8052c47c 8053cf20 00000000 00002e42 nt!KiTimerExpiration+0xb0
f8950ff4 8052c16a efdefd44 00000000 00000000 nt!KiRetireDpcList+0x31
Das Feld STACK_TEXT zeigt eine Stapelablaufverfolgung der fehlerhaften Komponente an.
FOLLOWUP_IP:
USBPORT!USBPORT_BadRequestFlush+7c
f832035c 894204 mov [edx+0x4],eax
Das Feld FOLLOWUP_IP zeigt die Demontage der Anweisung an, die den Fehler wahrscheinlich verursacht hat.
FOLLOWUP_NAME: usbtri
SYMBOL_NAME: USBPORT!USBPORT_BadRequestFlush+7c
MODULE_NAME: USBPORT
IMAGE_NAME: USBPORT.SYS
DEBUG_FLR_IMAGE_TIMESTAMP: 3b7d868b
Die Felder SYMBOL_NAME, MODULE_NAME, IMAGE_NAME und DBG_FLR_IMAGE_TIMESTAMP zeigen das Symbol, das Modul, das Bild und den Bildzeitstempel an, der dieser Anweisung entspricht (sofern gültig) oder dem Aufrufer dieser Anweisung (falls nicht).
STACK_COMMAND: .trap fffffffff8950dfc ; kb
Das Feld STACK_COMMAND zeigt den Befehl an, der zum Abrufen des STACK_TEXT verwendet wurde. Mit diesem Befehl können Sie diese Stapelablaufverfolgungsanzeige wiederholen oder ändern, um verwandte Stapelinformationen abzurufen.
BUCKET_ID: 0xD1_W_USBPORT!USBPORT_BadRequestFlush+7c
Das Feld BUCKET_ID zeigt die spezifische Fehlerkategorie an, zu der der aktuelle Fehler gehört. Mit dieser Kategorie kann der Debugger ermitteln, welche weiteren Informationen in der Analyseausgabe angezeigt werden sollen.
Informationen zu den Feldern FOLLOWUP_NAME und Nachverfolgung finden Sie unter Das Nachverfolgungsfeld und die triage.ini-Datei.
Es gibt eine Vielzahl weiterer Felder, die angezeigt werden können:
Wenn das Steuerelement an eine ungültige Adresse übertragen wurde, enthält das Feld FAULTING_IP diese ungültige Adresse. Anstelle des felds FOLLOWUP_IP zeigt das Feld FAILED_INSTRUCTION_ADDRESS den zerlegten Code dieser Adresse an, obwohl diese Disassemblierung wahrscheinlich bedeutungslos ist. In dieser Situation verweisen die Felder SYMBOL_NAME, MODULE_NAME, IMAGE_NAME und DBG_FLR_IMAGE_TIMESTAMP auf den Aufrufer dieser Anweisung.
Wenn der Prozessor fehlgeht, werden möglicherweise die Felder SINGLE_BIT_ERROR, TWO_BIT_ERROR oder POSSIBLE_INVALID_CONTROL_TRANSFER angezeigt.
Wenn speicherbeschädigungen aufgetreten sind, gibt das Feld CHKIMG_EXTENSION den Erweiterungsbefehl !chkimg an, der für die Untersuchung verwendet werden soll.
Wenn eine Fehlerüberprüfung im Code eines Gerätetreibers aufgetreten ist, wird sein Name möglicherweise im Feld BUGCHECKING_DRIVER angezeigt.
Das Nachverfolgungsfeld und die triage.ini-Datei
Sowohl im Benutzermodus als auch im Kernelmodus zeigt das Feld Followup in der Anzeige Informationen über den Besitzer des aktuellen Stapelrahmens an, sofern dies bestimmt werden kann. Diese Informationen werden wie folgt bestimmt:
Wenn die Erweiterung !analyze verwendet wird, beginnt der Debugger mit dem oberen Frame im Stapel und bestimmt, ob er für den Fehler verantwortlich ist. Ist dies nicht der Fall, wird der nächste Frame analysiert. Dieser Prozess wird fortgesetzt, bis ein möglicherweise fehlerhafter Frame gefunden wird.
Der Debugger versucht, den Besitzer des Moduls und der Funktion in diesem Frame zu ermitteln. Wenn der Besitzer ermittelt werden kann, gilt dieser Frame als fehlerhaft.
Wenn der Besitzer nicht bestimmt werden kann, wird der Debugger an den nächsten Stapelrahmen usw. übergeben, bis der Besitzer bestimmt ist (oder der Stapel vollständig untersucht wird). Der erste Frame, dessen Besitzer in dieser Suche gefunden wird, gilt als fehlerhaft. Wenn der Stapel erschöpft ist, ohne dass Informationen gefunden wurden, wird kein Nachverfolgungsfeld angezeigt.
Der Besitzer des fehlerhaften Frames wird im Feld Followup angezeigt. Wenn !analyze -v verwendet wird, verweisen die Felder FOLLOWUP_IP, SYMBOL_NAME, MODULE_NAME, IMAGE_NAME und DBG_FLR_IMAGE_TIMESTAMP auf diesen Frame.
Damit das Feld Followup nützliche Informationen anzeigt, müssen Sie zuerst eine triage.ini Datei erstellen, die die Namen der Modul- und Funktionsbesitzer enthält.
Die triage.ini-Datei sollte die Besitzer aller Module identifizieren, die möglicherweise Fehler aufweisen können. Sie können eine Informationszeichenfolge anstelle eines tatsächlichen Besitzers verwenden, aber diese Zeichenfolge darf keine Leerzeichen enthalten. Wenn Sie sicher sind, dass ein Modul keinen Fehler verursacht, können Sie dieses Modul weglassen oder angeben, dass es übersprungen werden soll. Es ist auch möglich, Besitzer einzelner Funktionen anzugeben, was dem Triageprozess eine noch feinere Granularität verleiht.
Ausführliche Informationen zur Syntax der triage.ini-Datei finden Sie unter Angeben von Modul- und Funktionsbesitzern.
Zusätzliche !analyze-Techniken
Wenn kein Absturz oder keine Ausnahme aufgetreten ist, zeigt !analyze einen sehr kurzen Text an, der die aktuelle status des Ziels angibt. In bestimmten Situationen können Sie die Analyse so erzwingen, als ob ein Absturz aufgetreten wäre. Verwenden Sie !analyze -f , um diese Aufgabe auszuführen.
Wenn im Benutzermodus eine Ausnahme aufgetreten ist, Sie aber glauben, dass das zugrunde liegende Problem ein hung Thread ist, legen Sie den aktuellen Thread auf den thread fest, den Sie untersuchen, und verwenden Sie dann !analyze -hang. Diese Erweiterung führt eine Threadstapelanalyse durch, um festzustellen, ob Threads andere Threads blockieren.
Wenn im Kernelmodus eine Fehlerüberprüfung aufgetreten ist, Sie aber glauben, dass das zugrunde liegende Problem ein hängendes Thread ist, verwenden Sie !analyze -hang. Diese Erweiterung untersucht Sperren, die vom System gehalten werden, und überprüft die DPC-Warteschlangenkette und zeigt alle Hinweise auf hängende Threads an. Wenn Sie der Meinung sind, dass das Problem ein Kernelmodus-Ressourcen-Deadlock ist, verwenden Sie die Erweiterung !deadlock zusammen mit der Option Deadlockerkennung von Driver Verifier.
Sie können bekannte Probleme auch automatisch ignorieren. Dazu müssen Sie zunächst eine XML-Datei erstellen, die eine formatierte Liste bekannter Probleme enthält. Verwenden Sie die Erweiterung !analyze -c -loadKnownIssuesFile , um diese Datei zu laden. Wenn dann eine Ausnahme oder eine Unterbrechung auftritt, verwenden Sie die Erweiterung !analyze -c . Wenn die Ausnahme mit einem der bekannten Probleme übereinstimmt, wird die Ausführung des Ziels fortgesetzt. Wenn die Ausführung des Ziels nicht fortgesetzt wird, können Sie !analyze -v verwenden, um die Ursache des Problems zu ermitteln.
Weitere Informationen
Weitere Informationen finden Sie in diesen Themen.
Bug Check Code Reference (Referenz zu Fehlerüberprüfungscodes)
Absturzabbildanalyse mithilfe der Windows-Debugger (WinDbg)
Analysieren einer Kernel-Mode-Speicherabbilddatei mit WinDbg
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für