WinDBG Trouver le réel (non géré) exception

J'essaie de trouver le véritable exception dans un géré non géré code mixte.

Le problème est que j'ai un .Net classe qui intercepte toutes les exceptions non gérées, puis crée un dump, donc quand je regarde le dump il y a mixte de gestion de code non managé, et je ne peux pas vraiment la réelle non géré exception.
Et pour aggraver les choses, l' .Net semble avoir sa propre exception !analyze-v me donne que l'exception.

Donc, voici ce que j'ai:

Je peux le trouver où l'exception s'est produite (par trouver le 1003f word), puis faire .cxr pour arriver à cette place réelle dans le code.

Quand je fais un !dumpstack je reçois quelque chose comme:

//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

De toute façon, la chose est, je ne peux pas l'exception. Je sais que c'est une mst exception, mais je ne suis pas sûr que l'on (dans la ligne de code il n'y a pas une exception personnalisée, et un certain nombre de choses ont mal tourné).

OriginalL'auteur Yochai Timmer | 2011-09-05

  1. 6

    De commutation, le contexte devrait vous ai apporté à la RaiseException() invocation. Si vous le chercher, il accepte un code d'exception et un tas d'application/compilateur spécifique de paramètres dans les paramètres du bloc. Visual studio compilateur passe l'objet d'exception comme l'un des paramètres, c'est à dire:

    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)
...

    Ensuite, vous pouvez utiliser dt 02bffb70 mymodule!std::bad_alloc pour inspecter l'objet de l'exception

    Merci, j'obtiens à peu près ce que vous obtenez, mais au lieu de la ligne avec le mymodule!std::bad_alloc::`vftable " je reçois 00000000 ... donc il n'y a rien que je peux obtenir à partir de là.
    Aucune idée de pourquoi ça serait 000000 là ? (avant l'exception descripteur)
    pouvez-vous dump arguments pour RaiseException dans votre cas?
    il serait également utile de prendre un coup d'oeil à la non géré pile (ko), après que vous avez fixé les symboles
    Je l'ai collé c'est une autre question, parce que vous m'a effectivement aidé à ce que je cherchais. stackoverflow.com/questions/7309072/...

    OriginalL'auteur deemok

  2. 1

    Vous pouvez essayer pour rechercher un contexte de signature dans le processus de la mémoire:

    s-d 0 L10000000/4 0001003f

    avec un peu de chance ce sera de retour d'une adresse mémoire où le contexte a été trouvée, vous pouvez ensuite définir le contexte actuel de cet emplacement avec .cxr.

    Cela fonctionne parce que le CONTEXTE de la structure dans windows, créé lorsqu'une exception est levée, commence toujours par le 0001003f valeur (valable uniquement pour les architectures X86!)

    (conseil prises à partir de l'Avancée de Débogage de Windows livre)

    J'ai trouvé le contexte déjà, et a trouvé la ligne exacte où l'exception s'est produite. Le truc, c'est qu'après je cahnge au contexte .cxr je ne sais pas comment ge lla exception de l'information.
    désolé, je n'ai pas de lire attentivement la question et de la pensée que vous avez été à la recherche pour le contexte, en premier lieu,

    OriginalL'auteur floyd73