J'ai un processus exécuté sous Windows Server 2003 SP2. Lorsque je veux vérifier la trace d'une pile de l'un de ses threads, il est toujours limité à 9 entrées. Ces entrées sont résolues correctement (j'ai des PDB en place) mais la liste est juste coupée au milieu.Trace de pile limité dans Process Explorer
Connaissez-vous une limitation dans Process Explorer?
Je suppose que vous pensez que la trace de la pile complète pour ce thread doit avoir plus de 9 entrées. Vous ne mentionnez pas si OS 32 bits ou OS 64 bits, mais je supposerai OS 32 bits, puis couvrir 64 bits comme une réflexion après coup. Parfois, lorsque vous collectez une trace de pile sur des systèmes 32 bits, vous ne pouvez collecter aucun élément pour la trace de pile ou vous pouvez uniquement collecter une quantité limitée d'informations de pile, même si vous savez que la pile est plus profonde. Les raisons en sont les suivantes:
Différentes conventions d'appel placent des données à différents endroits de la pile, ce qui rend la marche de la pile difficile. Je peux penser à 4 définitions, 3 en usage courant, une plus exotique: cdecl, fastcall, stdcall, nu. Pour les versions de version, l'optimiseur de code peut supprimer les pointeurs de trame en utilisant une technique connue sous le nom FPO (Frame Pointer Omission). Sans le FPO (et parfois, même avec les données FPO dans un fichier PDB), vous ne pouvez pas marcher avec succès sur la pile des appels. Hooks - toutes les DLL auxiliaires, antivirus, crochets de débogage, code instrumenté, malware, etc, peuvent gâcher la callstack à un point parce qu'ils ont inséré leur propre code stub sur la callstack et cette petite section peut ne pas être walkable par le marcheur de pile.
Machines virtuelles de type bytecode. Selon la façon dont la machine virtuelle est écrite, la machine virtuelle peut placer des trampolines sur la pile d'appel pour faciliter son exécution. Cela rendra la pile difficile à marcher avec succès.
En raison de la variété des conventions d'appel sur 32 bits de Windows (à la fois Microsoft et d'autres fournisseurs), il est difficile de comprendre ce qui s'attendre lorsque vous passez d'une image à l'autre.
Pour les systèmes 64 bits il y a une convention d'appel spécifiée. Cela rend la vie beaucoup plus facile. Cela dit, vous avez toujours le problème des DLL auxiliaires et des hooks qui font leur propre truc avec la pile et qui peuvent encore vous causer des problèmes en marchant dans la pile.
Je doute qu'il existe une limitation dans Process Explorer. Je pense que le problème est que le fait de marcher sur la pile d'appel pour ce thread est problématique à cause de l'une des raisons que j'ai énumérées ci-dessus.