Appeler pile au runtime

Question

Je souhaite accéder à la pile d'appels lors de l'exécution dans une application C ++ native. Je n'utilise pas l'IDE. Comment afficher la pile d'appels?

Mise à jour: J'ai une fonction qui est appelée à partir de nombreux points dans l’application. Il se bloque à de rares occasions. Je cherchais un moyen d'obtenir le nom de l'appelant et de le consigner.

Answer 1

Je crois que cette page a la réponse que vous cherchez. Vous avez dit Visual C, je suppose donc que vous voulez dire Windows.

Answer 2

Consultez StackWalk64 .

Si vous avez l'habitude de faire cela sur .NET, alors vous êtes pris d'une mauvaise surprise.

Answer 3

Vous devriez envisager de définir votre filtre d'exception non géré et d'écrire une fichier minidump de l'intérieur. Ce n’est pas si compliqué que cela et est bien documenté . Respectez simplement le minimum de choses que vous faites une fois dans votre filtre d'exception non gérée (lisez ce qui peut tout se passe mal si vous faites preuve de créativité).

Mais pour être sûr (votre filtre d’exception non géré risque d’être écrasé par inadvertance), vous pouvez placer votre code dans __try / __ sauf bloquer et écrire le minidump depuis la fonction de filtrage (remarque: vous ne pouvez pas avoir d’objets nécessitant une décompresser dans une fonction avec __try / __ except block, si vous en avez, envisagez de les placer dans une fonction séparée):

long __stdcall myfilter (EXCEPTION_POINTERS * pexcept_info)
{
& nbsp; & nbsp; & nbsp; & nbsp; mycreateminidump (pexcept_info);
& nbsp; & nbsp; & nbsp; & nbsp; Renvoyer EXCEPTION_EXECUTE_HANDLER;
}
void myfunc ()
{
__try {
& nbsp; & nbsp; & nbsp; & nbsp; // votre logique ici
} __except (myfilter (GetExceptionInformation ())) {
& nbsp; & nbsp; & nbsp; & nbsp; // exception gérée
}
}

Vous pouvez ensuite inspecter le fichier de vidage avec un débogueur de votre choix. Visual Studio et les débogueurs du package des outils de débogage Windows peuvent gérer les mini-pompes.

Answer 4

Si vous voulez obtenir une pile d'appels du crash, vous voulez vraiment débogage post mortem . Si vous souhaitez vérifier une pile d’applications en cours d’exécution, il s’agit d’une des nombreuses fonctions SysInternals Process Explorer peut offrir.

Answer 5

Si vous n'êtes pas en train de déboguer, vous pouvez " planter " l'application pour produire un minidump (cela peut être fait de manière non invasive et permet à l'application de continuer à fonctionner). IIRC DrWatson vous laissera faire cela, sinon userdump du support technique de MS le fera.

Vous pouvez ensuite charger le dump dans windbg et y voir le callstack + variables, etc. Vous aurez besoin des symboles de votre application pour donner un sens à la trace.

Si vous recherchez des traces de style de code d'exécution plus simples, je vous recommande une classe simple que vous instanciez sur chaque méthode, le constructeur écrit le nom de la méthode à l'aide de OutputDebugString. Utilisez WinDebug pour afficher la trace lors de l’exécution du programme. (placez une forme de contrôle dans votre classe, même s’il s’agit simplement d’une variable globale ou d’une valeur de registre, ou d’un atome global pour pouvoir activer ou désactiver le traçage à volonté).

Answer 6

  

Il se bloque à de rares occasions. Je cherchais un moyen d'obtenir le nom de l'appelant et de le consigner.

Qu'entendez-vous par accident? Violation d'accès? Diviser par zéro? quoi exactement? Est-ce qu'il interagit avec les composants en mode noyau?

Activer l’appérificateur. cela devrait éliminer beaucoup de choses.

créer ceci:

Options d'exécution du fichier HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows NT \ CurrentVersion \ Image \ Nom_fichier.exe

sous cette clé, créez une nouvelle chaîne nom: débogueur valeur: c: \ pathtowindbg \ windbg.exe -gG -xe av

Si vous utilisez du code 32 bits avec WOW, vous devez le faire sous le noeud wow3264.