2009-05-06 10 views
1

J'ai couru kd par erreur et j'ai obtenu une sortie qui m'a intériorisé, une référence à une ligne de code dans mon module que je ne peux pas voir sur la pile d'appel d'un thread. Les lignes n'étaient pas le début de la méthode donc je ne pense pas que la référence est à un pointeur de fonction, mais peut-être le résultat d'une exception stockée dans la mémoire ??? Bien sûr, cela arrive à être ce que je cherche ...Que fait la commande windbg "kd"?

Mise à jour:

La trace de la pile de l'exception est:

0:000> kb 
    *** Stack trace for last set context - .thread/.cxr resets it 
ChildEBP RetAddr Args to Child    
0174f168 734ea84f 2cb9e950 00000000 2cb9e950 kernel32!LoadTimeZoneInformation+0x2b 
0174f1c4 734ead92 00000022 00000001 000685d0 msvbvm60! RUN_INSTMGR::ExecuteInitTerm+0x178 
0174f1f8 734ea9ee 00000000 0000002f 2dbc2abc msvbvm60! RUN_INSTMGR::CreateObjInstanceWithParts+0x1e4 
0174f278 7350414e 2cb9e96c 00000000 0174f2f0 msvbvm60! RUN_INSTMGR::CreateObjInstance+0x14d 
0174f2e4 734fa071 00000000 2cb9e96c 0174f2fc msvbvm60!RcmConstructObjectInstance+0x75 
0174f31c 00976ef1 2cb9e950 00591bc0 0174fddc msvbvm60!__vbaNew+0x21 

et dans notre code (créer un nouveau formulaire classe dérivée)

la sortie dds:

0:000> dds esp-0x40 esp+0x100 
0174f05c 00000000 
0174f060 00000000 
0174f064 00000000 
0174f068 00000000 
0174f06c 00000000 
0174f070 00000000 
0174f074 00000000 
0174f078 00000000 
0174f07c 00000000 
0174f080 00000000 
0174f084 00000000 
0174f088 00000000 
0174f08c 00000000 
0174f090 00000000 
0174f094 00000000 
0174f098 00000000 
0174f09c 007f4f9b ourDll!formDerivedClass::Form_Initialize+0x10b [C:\Buildbox\formDerivedClass.frm @ 1452] 

etc

qui semble indiquer qu'Initialize est appelée même si elle ne figure pas dans la trace de pile de cette exception ou de l'un des threads. Comme suggéré, il pourrait tout être une discordance entre pdbs et dlls, mais il semble une coïncidence que nous finissions dans les bonnes classes et méthodes

Répondre

1

Kd signifie "pile dump." De la documentation:

La commande kd affiche la pile brute . Chaque valeur DWORD est affichée sur sur une ligne distincte. Les informations de symbole sont affichées pour les lignes avec les symboles associés. Ce format crée une liste plus détaillée que les autres commandes k * . La commande kd est équivalente à une commande dds (Display Memory) qui utilise l'adresse de la pile comme son paramètre.

Essayez .hh pour obtenir l'aide du débogueur à l'intérieur de ntsd/windbg.

Voir aussi "dds esp-esp 0x40 + 0x80"

+1

Alors pourquoi ces lignes de pile sont elles si elles ne font pas partie d'une pile d'appels sur un thread? Y a-t-il une commande pour retracer l'un d'entre eux à la fonction d'appel afin que je puisse voir pourquoi ils sont là? – Oskar

+1

C'est difficile à dire sans voir la sortie. Si vous déboguez du code optimisé (release), les piles peuvent devenir plutôt funky. Le débogueur essaye juste de faire correspondre des adresses avec des symboles - parfois il se trompe. Si cela n'a vraiment aucun sens, cela pourrait être une corruption de pile ou vous avez les mauvais symboles chargés (pdb ne correspond pas). –

+1

Je suis presque sûr que les pdbs correspondent (nous avons reconstruit le binaire pour obtenir les pdbs plus tôt). Mise à jour de la question maintenant avec plus d'info – Oskar

0

Excusez-moi, mais il semble un peu comme vous avez couru en fait la commande "kb" - avec un "B", pas un "D". C'est ce qui apparaît dans la session ci-dessus, et les exemples sur http://www.debuginfo.com/articles/easywindbg.html semblent certainement produire une sortie similaire ...