2009-09-22 9 views
1

J'ai écrit une application en C++/CLR. Il utilise une lib/dll native. En de rares occasions, il bloque l'initié de cette DLL native. J'ai alors une stacktrace, mais seulement jusqu'à la partie gérée, la partie native interne est laissée de côté. Y a-t-il un moyen de laisser afficher toute la pile?Comment obtenir une pile complète à partir d'un exe/dll en mode mixte écrasé?

J'ai fait le test suivant: J'ai ajouté une ligne de code à l'intérieur de la DLL native qui la fait toujours planter. Quand je l'exécute en doubleclicking l'exe, j'obtiens une stacktrace de la partie gérée comme avant. Si je l'exécute à partir VS2008 avec un débogueur attaché (en appuyant simplement sur F5), et il se bloque, je vois l'ensemble de la pile, les parties managées et non gérées. Comme le bug actuall se produit si rarement, je voudrais ajouter quelque chose à mon application qui affiche en quelque sorte toute la pile sans que les utilisateurs l'installent et l'exécutent via VS. Y-a-t-il un moyen de faire ça?

Thx Marc

Répondre

0

En utilisant Process Explorer de Sysinternals (http://technet.microsoft.com/de-de/sysinternals/bb896653.aspx), vous pouvez regarder la pile d'un processus qui est en cours d'exécution. Peut-être que cela vous aidera ...

+0

Bien que ce soit un programme intéressant dont je n'étais pas conscient, quand je regarde la pile d'un programme écrasé, peu importe s'il s'agit d'une application gérée ou native, j'obtiens la piletrace suivante du thread principal: (voir stacktrace dans le commentaire suivant) ce qui ne m'aide pas. :( – marc40000

+0

wow64cpu.dll! TurboDispatchJumpAddressEnd + 0x690 wow64cpu.dll! TurboDispatchJumpAddressEnd + 0xe3 wow64.dll! Wow64SystemServiceEx + 0x1ce wow64.dll! Wow64LdrpInitialize + 0x429 ntdll.dll! RtlResetRtlTranslations + 0x1b08 ntdll.dll! RtlResetRtlTranslations + 0xc63 ntdll.dll! LdrInitializeThunk + 0xe ntdll.dll! NTWaitForMultipleObjects + 0x15 Kernel32.dll! WaitForMultipleObjectsEx + 0x8E kernel32.dll! WaitForMultipleObjects + 0x18 Kernel32.dll! CheckForReadOnlyResource + 0x175 Kernel32.dll! CheckForReadOnlyResource + 0x212 kernel32 .dll! UnhandledExceptionFilter + 0x163 kernel32.dll! andledExceptionFilter + 0xe0 – marc40000

+0

ntdll.dll! RtlKnownExceptionFilter + 0xb7 ntdll.dll! RtlInitializeExceptionChain + 0x36 – marc40000

0

Il est très non trivial, que je peux vous recommander des liens suivants:

Fast capture stack trace on windows/64-bit/mixed mode

Resolve managed and native stack trace - which API to use?

Mais ce que j'ai essayé - même si vous utilisez la détermination de la pile comme ceci: si vous obtenez une exception du côté natif, elle se propagera en tant que SEHException du côté géré, et lorsque vous aurez le contrôle du côté géré, la pile d'appel partielle est déjà perdue. (Partie autochtone). Il est possible de déterminer la pile d'appel natif en cas d'exception, mais cela doit être écrit encore.

Je pourrais faire ce travail en tant que pigiste si nécessaire.

Questions connexes