WinDBG - Feststellung der tatsächlichen (nicht verwalteten) Ausnahme

Ich versuche, hier finden Sie die aktuelle Ausnahme in einem managed-unmanaged mixed code.

Das problem ist, dass ich eine .Net-Klasse, die fängt alle nicht behandelten Ausnahmen und erstellt dann ein dump, also wenn ich mir den dump gibt es gemischte managed-unmanaged-code, und ich kann nicht wirklich auf die tatsächliche, nicht verwaltete Ausnahme.
Und was noch schlimmer ist, die .Net zu haben scheint, seine eigene Ausnahme, so !analysieren -v gibt mir die Ausnahme.

So, hier ist was ich habe:

Ich finden kann, wo die exception passiert ist (durch die Suche nach dem 1003f Wort), dann tun .cxr man, dass die tatsächliche Stelle im code.

Wenn ich eine !dumpstack bekomme ich so etwas wie:

//My module stuff and then:
122bf71c 08bf5242 (MethodDesc 0x4bf71ac +0x5a <Module>.dbg.NativeExceptionHandler())
122bf734 08bf5242 (MethodDesc 0x4bf71ac +0x5a <Module>.dbg.NativeExceptionHandler())
122bf73c 08bf51ce (MethodDesc 0x4bf71dc +0x6 <Module>.dbg.OnUnhandledNativeException(_EXCEPTION_POINTERS*)), calling (MethodDesc 0x4bf71ac +0 <Module>.dbg.NativeExceptionHandler())
122bf75c 08bf51ce (MethodDesc 0x4bf71dc +0x6 <Module>.dbg.OnUnhandledNativeException(_EXCEPTION_POINTERS*)), calling (MethodDesc 0x4bf71ac +0 <Module>.dbg.NativeExceptionHandler())
122bf760 3944bf15 3944bf15
122bf778 7c35f0c3 msvcr71!__CxxUnhandledExceptionFilter+0x46, calling 091f15a2
122bf784 7c864191 kernel32!UnhandledExceptionFilter+0x1c7
122bf7ac 7c812afb kernel32!RaiseException+0x53, calling ntdll!RtlRaiseException
122bf7f4 7857df60 msvcr90!_CxxThrowException+0x48 [f:\prebuild\eh\throw.cpp:161], calling kernel32!RaiseException
122bf828 785436c5 msvcr90!__set_flsgetvalue+0xf [f:\src\tidtable.c:256], calling kernel32!TlsGetValue
122bf834 785438b3 msvcr90!_getptd_noexit+0x74 [f:\src\tidtable.c:616], calling ntdll!RtlSetLastWin32Error
122bf844 785438c5 msvcr90!_getptd+0x8 [f:\src\tidtable.c:641], calling msvcr90!_getptd_noexit [f:\src\tidtable.c:566]
122bf84c 7857c98c msvcr90!__FrameUnwindToState+0xd9 [f:\prebuild\eh\frame.cpp:1161], calling msvcr90!_getptd [f:\src\tidtable.c:640]
122bf850 7857c972 msvcr90!__FrameUnwindToState+0xbf [f:\prebuild\eh\frame.cpp:1182], calling msvcr90!__SEH_epilog4
122bf860 785436c5 msvcr90!__set_flsgetvalue+0xf [f:\src\tidtable.c:256], calling kernel32!TlsGetValue
122bf870 785436c5 msvcr90!__set_flsgetvalue+0xf [f:\src\tidtable.c:256], calling kernel32!TlsGetValue
122bf87c 785438b3 msvcr90!_getptd_noexit+0x74 [f:\src\tidtable.c:616], calling ntdll!RtlSetLastWin32Error
122bf88c 785438c5 msvcr90!_getptd+0x8 [f:\src\tidtable.c:641], calling msvcr90!_getptd_noexit [f:\src\tidtable.c:566]
122bf894 7857d06a msvcr90!CallCatchBlock+0x148 [f:\prebuild\eh\frame.cpp:1503], calling msvcr90!_getptd [f:\src\tidtable.c:640]
122bf898 7857d03c msvcr90!CallCatchBlock+0x11a [f:\prebuild\eh\frame.cpp:1520], calling msvcr90!__SEH_epilog4
122bf8e8 7857d03c msvcr90!CallCatchBlock+0x11a [f:\prebuild\eh\frame.cpp:1520], calling msvcr90!__SEH_epilog4
122bf8ec 7857d486 msvcr90!CatchIt+0x5e [f:\prebuild\eh\frame.cpp:1275], calling msvcr90!CallCatchBlock [f:\prebuild\eh\frame.cpp:1433]
122bf91c 7857d576 msvcr90!FindHandlerForForeignException+0xdb [f:\prebuild\eh\frame.cpp:976], calling msvcr90!CatchIt [f:\prebuild\eh\frame.cpp:1219]
122bf950 785436c5 msvcr90!__set_flsgetvalue+0xf [f:\src\tidtable.c:256], calling kernel32!TlsGetValue
122bf95c 785438b3 msvcr90!_getptd_noexit+0x74 [f:\src\tidtable.c:616], calling ntdll!RtlSetLastWin32Error
122bf96c 785438c5 msvcr90!_getptd+0x8 [f:\src\tidtable.c:641], calling msvcr90!_getptd_noexit [f:\src\tidtable.c:566]
122bf974 7857d8c8 msvcr90!FindHandler+0x334 [f:\prebuild\eh\frame.cpp:879], calling msvcr90!_getptd [f:\src\tidtable.c:640]
122bf988 785436c5 msvcr90!__set_flsgetvalue+0xf [f:\src\tidtable.c:256], calling kernel32!TlsGetValue
122bf994 785438b3 msvcr90!_getptd_noexit+0x74 [f:\src\tidtable.c:616], calling ntdll!RtlSetLastWin32Error
122bf998 7c910323 ntdll!RtlpImageNtHeader+0x56, calling ntdll!_SEH_epilog
122bf9b0 7c90d98a ntdll!NtQueryVirtualMemory+0xc
122bf9b4 7c880b54 kernel32!_ValidateEH3RN+0xb6, calling ntdll!ZwQueryVirtualMemory
122bf9f4 7c83ab50 kernel32!BaseThreadStart+0x4d, calling kernel32!UnhandledExceptionFilter
122bf9fc 7c839b39 kernel32!_except_handler3+0x61
122bfa24 7c9032a8 ntdll!ExecuteHandler2+0x26
122bfa48 7c90327a ntdll!ExecuteHandler+0x24, calling ntdll!ExecuteHandler2
122bfa6c 7c92aa0f ntdll!RtlDispatchException+0xb1, calling ntdll!RtlpExecuteHandlerForException
122bfa98 78591795 msvcr90!_except_handler3+0x69
122bfac0 7c9032a8 ntdll!ExecuteHandler2+0x26
122bfae4 7c90327a ntdll!ExecuteHandler+0x24, calling ntdll!ExecuteHandler2
122bfaf8 7c90e48a ntdll!KiUserExceptionDispatcher+0xe, calling ntdll!RtlDispatchException
122bfdf8 064fdd84 MyModule!Class::MyFunction::Update+0xe4 [c:\MyCode.cpp:12345] ====> Exception cxr@122bfb2c
122bfb60 7c910222 ntdll!RtlpAllocateFromHeapLookaside+0x42, calling ntdll!_SEH_epilog

Sowieso, also das Ding ist, ich kann nicht die tatsächliche Ausnahme. Ich weiß, es ist eine Geschlechtskrankheit Ausnahme, aber ich bin mir nicht sicher, welche (in dieser Zeile des Codes gibt es nicht eine benutzerdefinierte Ausnahme, und eine Reihe von Dingen könnte schief gegangen sein).

InformationsquelleAutor Yochai Timmer | 2011-09-05

6

Schalt-Kontext haben sollte brachte Sie auf die RaiseException () - Aufruf. Wenn Sie suchen, nimmt er eine Ausnahme-code und eine Reihe von Anwendungs - /compiler-spezifische Parameter in der Parameter-block. Visual studio compiler übergibt exception-Objekt als Parameter, also:
```
0:003:x86> .cxr <addr-of-context-record>
0:003:x86> dds 2bffb28 la
02bffb28  02bffb60
02bffb2c  7222872d MSVCR100!CxxThrowException+0x45  ; this is the RaiseException() call
02bffb30  e06d7363 ; c++ exception code
02bffb34  00000001 ; flags
02bffb38  00000003 ; number of parameters
02bffb3c  02bffb54 ; parameters
...

0:003:x86> dpp 02bffb54 l3
02bffb54  19930520 ; compiler magic
02bffb58  02bffb70 0016c8b0 mymodule!std::bad_alloc::`vftable'
02bffb5c  0016f088 ; exception descriptor area (compiler-specific)
...
```
Dann können Sie dt 02bffb70 mymodule!std::bad_alloc zu inspizieren, um das exception-Objekt

Danke, ich bekommen in etwa, was Sie bekommen, aber statt die Zeile mit dem mymodule!std::bad_alloc::`vftable' ich bekommen 00000000 ... es gibt also nichts, was ich bekommen kann von dort aus.
Keine Ahnung warum, es wäre 000000 gibt es ? (vor der Ausnahme-Deskriptor)
können Sie dump-Argumente zu RaiseException in Ihrem Fall?
es würde auch hilfreich sein, einen Blick auf die nicht verwalteten Stapel (kb), nachdem Sie gelöst haben, die Symbole
Ich habe klebte es wie eine andere Frage, da man ja eigentlich geholfen, mich mit dem, was ich suchte. stackoverflow.com/questions/7309072/...

InformationsquelleAutor deemok
1

Können Sie versuchen, diese zu suchen, um ein Kontext-Signatur in der Prozess-Speicher:

s -d 0 L10000000/4 0001003f

mit etwas Glück das liefert eine Speicheradresse, wo der Zusammenhang gefunden wurde, können Sie den aktuellen Kontext, um diesen Ort mit .cxr.

Dies funktioniert, weil die CONTEXT-Struktur in windows erstellt, wenn eine Ausnahme ausgelöst wird, beginnt immer mit der 0001003f Wert (nur gültig für X86!)

(Tipp stammt aus der Advanced Windows Debugging-Buch)

Ich fand den Rahmen schon, und fand die genaue Zeile wo die exception passiert. Die Sache ist die, dass, nachdem ich cahnge, um den Kontext mit .cxr ich weiß nicht, wie ge tthe Ausnahme Informationen.
sorry, ich wusste nicht, Lesen Sie die Frage sorgfältig durch und dachte, Sie waren auf der Suche für den Kontext, in den ersten Platz

InformationsquelleAutor floyd73

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.