2011-07-06 2 views
7

J'ai tout un tas de minidumps qui ont été enregistrés pendant l'exécution d'une application via MiniDumpWriteDump. Les minidumps ont été créés sur une machine avec une version de système d'exploitation différente de celle de ma machine de développement.Comment extraire des traces de pile de minidumps?

Maintenant j'essaye d'écrire un programme pour extraire des traces de pile des minidumps, using dbghelp.dll. Je marche MINIDUMP_MODULE_LIST et appelle SymLoadModule64, mais cela ne parvient pas à télécharger les pdbs (kernel32 etc.) à partir du serveur de symboles publics. Si j'ajoute "C: \ Windows \ System32" au chemin du symbole, il trouve les dll et télécharge les symboles, mais bien sûr ils ne correspondent pas aux dll du minidump, donc les résultats sont inutiles.

Alors, comment puis-je dire dbghelp.dll pour télécharger et utiliser le bon pdbs?

[modifier]

J'ai oublié de dire que SymLoadModule64 ne prend un nom de fichier et aucune information de version/contrôle, donc évidemment avec SymLoadModule64 seul, il est impossible de comprendre dbghelp qui pdb à télécharger.

Les informations sont actuellement disponibles dans MINIDUMP_MODULE_LIST mais je ne sais pas comment les transmettre à l'API dbghelp. Il y a SymLoadModuleEx qui prend des paramètres supplémentaires, mais je n'ai aucune idée si c'est ce dont j'ai besoin ou ce que je devrais passer pour les paramètres supplémentaires.

[modifier]

Pas de chance jusqu'à présent, mais je l'ai remarqué il y a aussi dbgeng.dll distribués avec dbghelp.dll dans le SDK de débogage. MSDN semble assez bien documenté et dit que c'est le même moteur que Windbg. Peut-être que je peux l'utiliser pour extraire les traces de la pile.

Si quelqu'un peut me diriger vers une introduction à l'utilisation de dbgeng.dll pour traiter les minidumps, cela aiderait probablement aussi, car le MSDN ne documente que les composants individuels mais pas comment ils fonctionnent ensemble.

+0

Vous avez peut-être fait de vous minidump trop mini. Bricoler avec l'argument DumpType. Assurez-vous que la liste Debug + Windows + Modules affiche un chemin DLL, une version et un horodatage précis. –

+0

Non, ce n'est pas un problème, je peux très bien charger les minidumps dans WinDbg et il télécharge correctement les PDB. C'est juste que je veux automatiser la récupération de la pile au lieu d'inspecter les dumps manuellement dans WinDbg. – Zarat

+1

Si vous voulez aller la route de piratage, vous pouvez simplement passer des commandes à ntsd et capturer la sortie –

Répondre

8

Juste au cas où quelqu'un d'autre veut automatiser l'extraction de traces de la pile de décharges, voici ce que je fini par faire:

Comme je l'ai mentionné dans la mise à jour, il est possible d'utiliser dbgeng.dll au lieu de dbghelp.dll, qui semble être le même moteur que WinDbg utilise. Après quelques essais et erreurs, voici comment obtenir une bonne trace de pile avec le même mécanisme de chargement de symboles que WinDbg.

  • appel DebugCreate pour obtenir une instance du moteur de débogage
  • requête pour IDebugClient4, IDebugControl4, IDebugSymbols3
  • utilisation IDebugSymbols3.SetSymbolOptions pour configurer les symboles sont chargés (voir MSDN pour les options WinDbg utilise)
  • utilisation IDebugSymbols3.SetSymbolPath pour définir le chemin de symbole comme vous le feriez dans WinDbg
  • utilisation IDebugClient4.OpenDumpFileWide pour ouvrir la décharge
  • utilisation IDebugCo ntrol4.WaitForEvent d'attendre jusqu'à ce que la décharge est chargé
  • utilisation IDebugSymbols3.SetScopeFromStoredEvent pour sélectionner l'exception stockée dans la décharge
  • utilisation IDebugControl4.GetStackTrace pour aller chercher les quelques dernières trames pile
  • utilisation IDebugClient4.SetOutputCallbacks pour enregistrer un auditeur recevant la trace de pile décodé
  • utilisation IDebugControl4.OutputStackTrace pour traiter l'empilement des trames
  • utilisation IDebugClient4.SetOutputCallbacks pour désenregistrer le rappel
  • libérer les interfaces

L'appel à WaitForEvent semble être important car sans cela, les appels suivants ne parviennent pas à extraire la trace de la pile.

Aussi il semble toujours y avoir une fuite de mémoire là-dedans, ne peut pas dire si je ne nettoie pas correctement ou quelque chose d'interne à dbgeng.dll, mais je peux simplement redémarrer le processus tous les 20 dumps ou alors, donc je n'a pas enquêté plus.

Questions connexes