Windows fichier de vidage (hdmp) - information sans fichiers pdb

Question

J'ai reçu des fichiers de vidage (.mdmp et .hdmp) à partir d'un plantage de notre logiciel en raison d'une fuite de mémoire (qui était sur un autre ordinateur). Le logiciel se compose d'un fichier exe et de nombreux fichiers .dll. J'ai le code source (partie C++, partie delphi) mais je n'ai pas les fichiers .pdb pour cette construction exacte.

Je peux ouvrir le mdmp/hdmp dans Visual Studio ou dans WinDbg. Mais je ne gagne pas beaucoup d'informations parce que je n'ai pas les fichiers .pdb. Depuis le fichier hdmp est ~ 4gb gros, j'espère que j'ai déjà beaucoup d'informations, même sans les fichiers pdb. Mais je ne suis pas une trace de pile vraiment d'autres informations ou USEFULL, par exemple lorsque j'utilise la commande

!analyze -v 

Est-il possible d'une certaine manière d'obtenir de meilleurs résultats? Puis-je savoir d'une manière ou d'une autre combien de mémoire chaque DLL utilise (ou plutôt quels processus sont connectés à des DLLs spécifiques)? Puisque j'ai le code source, puis-je utiliser des fichiers pdb nouvellement générés (pour les modules C++)? Même s'ils ne sont pas précis à 100%. Ce serait déjà une aide précieuse, pour savoir quel module a causé la fuite de mémoire!

Answer 1

Vous pouvez charger des fichiers pdb sans une correspondance exacte du version.for que vous devez utiliser la commande .symopt +40 qui est charge quoi que ce soit SYMOPT_LOAD_ANYTHING

0:000> .symopt 
Symbol options are 0x30237: 
    0x00000001 - SYMOPT_CASE_INSENSITIVE 
    0x00000002 - SYMOPT_UNDNAME 
    0x00000004 - SYMOPT_DEFERRED_LOADS 
    0x00000010 - SYMOPT_LOAD_LINES 
    0x00000020 - SYMOPT_OMAP_FIND_NEAREST 
    0x00000200 - SYMOPT_FAIL_CRITICAL_ERRORS 
    0x00010000 - SYMOPT_AUTO_PUBLICS 
    0x00020000 - SYMOPT_NO_IMAGE_SEARCH 

Maintenant, vous devez exécuter une autre commande !sym noisy .Cette permettra Mode bruyant

0:000> !sym noisy 
noisy mode - symbol prompts on 

Une fois que vous faites cela, u peut exécuter la commande analyser et vous commencer à obtenir tous les symboles messages de chargement et où windbg recherche le symbole.

assurez-vous d'ajouter le chemin des fichiers pdb sur le chemin des symboles qui WinDBg regards en utilisant .sympath

0:000> .sympath 
Symbol search path is: srv*c:\symcache*http://msdl.microsoft.com/download/symbols 
Expanded Symbol search path is: srv*c:\symcache*http://msdl.microsoft.com/download/symbols 

S'il vous plaît noter que, parfois, même si l'on ajoute le sympath, certains fichiers de symboles, il regardera dans certains dossiers Dans ce cas, ce que je fais est de copier les fichiers pdb dans le dossier où windbg cherche.

par exemple.

DBGHELP: ntdll - symboles publics
c: \ symcache \ wntdll.pdb \ B5ACAC3B4A6C4515AF416D60366399652 \ wntdll.pdb

Je vais juste copier le fichier pdb à c: \ symcache \ wntdll.pdb \ B5ACAC3B4A6C4515AF416D60366399652.

ayant dit que

Une fuite de mémoire C++ natif est difficile d'analyser sans une décharge leaktrack .

S'il vous plaît essayer d'utiliser DebugDiag native memory leak analysis et il devrait vous dire ce tas prend le memory.If il est un peu tas bibliothèque personnalisée, vous pouvez essayer de mettre à jour ce composant particulier.Articles suivants pourraient vous aider

debugging-native-memory-leaks-with-debug-diag-1-1

walkthrough-troubleshooting-a-native-memory-leak

using-debugdiags-leaktrack-with-procdumps-reflected-process-dumps