J'essaie de parcourir une pile contenant des images gérées et natives sur un processus x64 à l'aide de StackWalk64. Tout fonctionne bien jusqu'à la première ou deuxième trame gérée, après quoi StackWalk64 ne peut pas comprendre l'adresse de retour de la trame et échoue. J'utilise SymFunctionTableAccess64 pour le rappel d'accès à la table des fonctions et le gestionnaire de symboles a été initialisé avec SymInitialize(). Y a-t-il un peu de magie à faire dans dbghelp pour qu'il marche correctement sur les cadres gérés?Comment marchez-vous une pile en mode mixte (géré + natif) avec dbghelp! StackWalk64?
Exemple callstack qui échoue:
UnmanagedFrame1
UnmanagedFrame2
UnmanagedFrame3
ManagedFrame1 <----- (StackWalk64 fails after this frame)
ManagedFrame2
UnmanagedFrame4
UnmanagedFrame5
ntdll!RtlUserThreadStart
Note: cette question n'est pas sur la façon de résoudre les cadres gérés à des symboles/noms de méthodes/etc, je veux simplement marcher la pile complète sans tenir compte de la résolution des symboles/etc.
De même, IDebugControl4 :: GetContextStackTrace fonctionne correctement, mais DbgEng utilise un rappel de table de fonctions personnalisé et ne délègue pas simplement à SymFunctionTableAccess64. Je suppose que le problème est que le CLR utilise RtlInstallFunctionTableCallback pour installer une table de fonctions de rappel (qui pointe vers mscordacwks), et SymFunctionTableAccess64 n'est pas assez intelligent pour suivre cela. J'ai passé du temps à essayer d'écrire un rappel d'accès à une table de fonction personnalisée pour traverser la chaîne de la table des fonctions et appeler le rappel dans mscordacwks, mais il est devenu assez sommaire et n'a pas vraiment fonctionné.
Le développeur VS Profiler qui a écrit le mécanisme de chemin de pile a un brevet à ce sujet. C'est non trivial. – linuxuser27
Avez-vous une source pour cela? – Steve