Interprétation des piles dans les mini-pompes Windows

StackOverflow https://stackoverflow.com/questions/77887

Question

En tant que personne qui commence tout juste à comprendre les subtilités du débogage informatique, pour ma vie, je ne comprends pas comment lire le texte de pile d'un cliché dans Windbg. Je ne sais pas par où commencer pour les interpréter ou s'y prendre. Quelqu'un peut-il offrir une direction à cette pauvre âme?

c'est-à-dire (le seul vidage que j'ai sous la main avec moi en réalité) 

>b69dd8f0 bfa1e255 016d2fc0 89efc000 00000040 nv4_disp+0x48b94

b69dd8f4 016d2fc0 89efc000 00000040 00000006 nv4_disp+0x49255

b69dd8f8 89efc000 00000040 00000006 bfa1dcc0 0x16d2fc0

b69dd8fc 00000000 00000006 bfa1dcc0 e1e71018 0x89efc000

Je sais que le problème est lié au pilote d’affichage Nvidia, mais ce que je veux savoir, c’est comment lire réellement la pile (par exemple, quel est b69dd8f4?): - [

Était-ce utile?

La solution

Tout d'abord, vous devez configurer les symboles appropriés. Les symboles vous permettront de faire correspondre les adresses mémoire aux noms de fonction. Pour ce faire, vous devez créer un dossier local sur votre machine dans lequel vous allez stocker un cache local de symboles (par exemple: C: \ symboles). Ensuite, vous devez spécifier le chemin du serveur de symboles. Pour ce faire, accédez à: Fichier > Chemin du fichier de symboles et type: 

SRV*c:\symbols*http://msdl.microsoft.com/download/symbols

Pour plus d'informations sur la configuration correcte des symboles, ici .

Une fois que vous avez correctement configuré le serveur de symboles, vous pouvez ouvrir le minidump à partir de: Fichier > Ouvrez Crash Dump.

Une fois le minidump ouvert, il vous indiquera, à gauche de la ligne de commande, le thread en cours d'exécution lors de la génération du cliché. Si vous voulez voir ce que ce thread était en train d’exécuter, tapez: 

kpn 200

Cela peut prendre un certain temps à la première exécution, car il doit télécharger les symboles publics nécessaires liés à Microsoft pour la première fois. Une fois tous les symboles téléchargés, vous obtiendrez quelque chose comme: 

01 MODULE!CLASS.FUNCTIONNAME1(...)
02 MODULE!CLASS.FUNCTIONNAME2(...)
03 MODULE!CLASS.FUNCTIONNAME3(...)
04 MODULE!CLASS.FUNCTIONNAME4(...)

Où:

  • LE PREMIER NUMÉRO : indique le numéro du cadre
  • MODULE : la DLL contenant le code
  • CLASS : (uniquement sur le code C ++) vous montrera la classe qui contient le code
  • FUNCTIONAME : méthode appelée. Si vous avez les bons symboles, vous verrez également les paramètres.

Vous pouvez également voir quelque chose comme 

01 MODULE!+989823

Cela indique que vous n'avez pas le symbole approprié pour cette DLL et que vous ne pouvez donc voir que la méthode offset.

Alors, qu'est-ce qu'un callstack?

Imaginez que vous avez ce code: 

void main()
{
  method1();
}

void method1()
{
  method2();
}

int method2()
{
  return 20/0;
}

Dans ce code, method2 générera une exception puisque nous essayons de diviser par 0 et que le processus se bloquera. Si nous avions un minidump quand cela se produirait, nous verrions le callstack suivant: 

01 MYDLL!method2()
02 MYDLL!method1()
03 MYDLL!main()

Vous pouvez suivre de cette file d’appels que " main " appelé "méthode1" qui a ensuite appelé "méthode2" et cela a échoué.

Dans votre cas, vous avez ce callstack (qui, je suppose, est le résultat de l'exécution de la commande "kb") 

b69dd8f0 bfa1e255 016d2fc0 89efc000 00000040 nv4_disp+0x48b94
b69dd8f4 016d2fc0 89efc000 00000040 00000006 nv4_disp+0x49255
b69dd8f8 89efc000 00000040 00000006 bfa1dcc0 0x16d2fc0
b69dd8fc 00000000 00000006 bfa1dcc0 e1e71018 0x89efc000

La première colonne indique le pointeur du cadre enfant, la deuxième colonne indique l'adresse de retour de la méthode en cours d'exécution, les trois colonnes suivantes indiquent les 3 premiers paramètres transmis à la méthode et la dernière partie correspond au nom de la DLL. (nv4_disp) et le décalage de la méthode en cours d'exécution (+ 0x48b94). Comme vous n'avez pas les symboles, vous ne pouvez pas voir le nom de la méthode. Je doute que NVIDIA offre au public l’accès à leurs symboles. Par conséquent, vous ne pouvez pas obtenir beaucoup d’informations à partir d’ici.

Je vous recommande d’exécuter "kpn 200". Cela vous montrera l’appel complet et vous pourrez peut-être voir l’origine de la méthode qui a provoqué cet arrêt (s’il s’agissait d’une DLL Microsoft, vous devriez avoir les symboles appropriés dans les étapes que je vous ai fournies).

Au moins, vous savez que c'est lié à un bogue NVIDIA ;-) Essayez de mettre à jour les DLL de ce pilote vers la dernière version.

Si vous souhaitez en savoir plus sur le débogage WinDBG, je vous recommande les liens suivants:

Autres conseils

Un très bon tutoriel sur l'interprétation d'une trace de pile est disponible ici:

http://www.codeproject.com/KB/debug/cdbntsd2.aspx

Cependant, même avec un tutoriel comme celui-ci, il peut être très difficile (ou presque impossible) d'interpréter un vidage de pile sans les symboles appropriés disponibles / chargés.

Il peut être utile d'inclure un exemple de la pile que vous essayez de lire. Un bon conseil est de vous assurer que les symboles de débogage sont corrects pour tous les modules affichés dans la pile. Ceci inclut les symboles des modules du système d'exploitation. Microsoft a mis son serveur de symboles à la disposition du public.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top