Frage SEH unter Windows, Call-Stack-Traceback ist weg


Ich lese das hier Artikel über die SEH unter Windows. und hier ist der Quellcode von myseh.cpp

Ich debuggte myseh.cpp. Ich habe 2 Haltepunkte gesetzt printf("Hello from an exception handler\n"); in Zeile: 24 und DWORD handler = (DWORD)_except_handler; in Zeile: 36 jeweils.

Dann lief ich es und es brach um Linie: 36. Ich sah den Stack-Trace wie folgt.

enter image description here Wie geht es, AccessViolationException  aufgetreten wegen mov [eax], 1 Dann brach es bei Linie: 24. Ich sah den Stack-Trace wie folgt. enter image description here

Derselbe Thread aber der Rahmen von main war weg! Anstatt von _except_handle. Und ESP sprang von 0018f6c8 zu 0018ef34Es ist eine große Lücke zwischen 0018f6c8 und 0018ef34 Nach der Ausnahme behandelt.

ich weiß das _except_handle muss im Benutzermodus und nicht im Kernelmodus ausgeführt werden. Nach _except_handle zurückgegeben, der Thread in Ring0 und dann Windows-Kernel CONTEXT geändert EAX zu &scratch & und kehrte dann zu Ring3 zurück. So lief Thread ständig.

Ich bin neugierig auf den Mechanismus von Fenstern, die mit Ausnahme umgehen: Warum zum Rahmen Berufung main war weg?

WARUM das ESP sprang von 0018f6c8 zu 0018ef34? (Ich meine eine große Tonhöhe), Gehören diese ESP-Adressen zum selben Thread-Stack ??? Hat der Kernel einige Tricks auf ESP in Ring3 gespielt ??? Wenn ja, WARUM wählte er die Adresse von 0018ef34 als Handler Rückruf-Frame? Danke vielmals!


5
2018-01-07 09:28


Ursprung


Antworten:


Sie verwenden die Standard-Debugger-Einstellungen, nicht gut genug, um alle Details anzuzeigen. Sie wurden ausgewählt, damit Sie sich auf Ihren eigenen Code konzentrieren und die Debug-Sitzung so schnell wie möglich starten können.

Der Block [Externer Code] teilt Ihnen mit, dass Teile des Stapelrahmens nicht zu dem von Ihnen geschriebenen Code gehören. Sie gehören nicht zum Betriebssystem. Verwenden Sie Extras> Optionen> Debugging> Allgemein und deaktivieren Sie die Option "Nur Code aktivieren".

Die Warnung [Frames unten ist möglicherweise falsch ...] weist darauf hin, dass der Debugger keine genauen PDBs hat, um den Stack korrekt zu durchlaufen. Verwenden Sie Extras> Optionen> Debugging> Symbole und aktivieren Sie die Option "Microsoft Symbol Servers" und wählen Sie einen Cache-Speicherort aus. Der Debugger lädt nun die zu debuggenden PDBs über die Betriebssystem-DLLs herunter. Könnte eine Weile dauern, es ist nur einmal gemacht.

Sie können die große ESP-Änderung durchdenken, die CONTEXT-Struktur ist ziemlich groß und belegt Platz auf dem Stapel.

Nach diesen Änderungen sollten Sie nun etwas Ähnliches sehen:

ConsoleApplication1942.exe!_except_handler(_EXCEPTION_RECORD * ExceptionRecord, void * EstablisherFrame, _CONTEXT * ContextRecord, void * DispatcherContext) Line 22    C++
ntdll.dll!ExecuteHandler2@20()  Unknown
ntdll.dll!ExecuteHandler@20()   Unknown
ntdll.dll!_KiUserExceptionDispatcher@8()    Unknown
ConsoleApplication1942.exe!main() Line 46   C++
ConsoleApplication1942.exe!invoke_main() Line 64    C++
ConsoleApplication1942.exe!__scrt_common_main_seh() Line 255    C++
ConsoleApplication1942.exe!__scrt_common_main() Line 300    C++
ConsoleApplication1942.exe!mainCRTStartup() Line 17 C++
kernel32.dll!@BaseThreadInitThunk@12()  Unknown
ntdll.dll!__RtlUserThreadStart()    Unknown
ntdll.dll!__RtlUserThreadStart@8()  Unknown

Auf Win10 Version 1607 und VS2015 Update 2 aufgezeichnet. Dies ist nicht die richtige Art, SEH-Handler zu schreiben, finden Sie ein besseres Beispiel in dieser Beitrag.


7
2018-01-07 13:09