WinDbg symboles manquants pour le code géré

Question

Je ne parviens pas à faire utiliser WinDbg à l'aide des fichiers PDB pour mon . NET fichiers DLL. Le hang dump que je regarde provient d’une version de production, mais j’ai des fichiers PDB d’une version de débogage du même code.

J'ai défini le chemin du symbole pour inclure un dossier local et le serveur de symboles Microsoft.

C:\websymbols\foo;srv*c:\websymbols*http://msdl.microsoft.com/download/symbols

Je mets tous mes fichiers PDB dans C: \ websymbols \ foo . Cependant, les listes de piles gérées ne contiennent aucun nom de méthode.

Effectuez un rechargement, .reload / f , me dit:

DBGHELP: No debug info for FOO.dll.  Searching for dbg file
SYMSRV:  c:\websymbols\foo\FOO.dbg\49B7F17C10000\FOO.dbg not found
SYMSRV:  c:\websymbols\FOO.dbg\49B7F17C10000\FOO.dbg not found
SYMSRV:  http://msdl.microsoft.com/download/symbols/FOO.dbg/49B7F17C10000/FOO.dbg not found
DBGHELP: .\FOO.dbg - file not found
DBGHELP: .\dll\FOO.dbg - path not found
DBGHELP: .\symbols\dll\FOO.dbg - path not found
DBGHELP: FOO.dll missing debug info.  Searching for pdb anyway
DBGHELP: Can't use symbol server for FOO.pdb - no header information available
DBGHELP: FOO.pdb - file not found
*** WARNING: Unable to verify checksum for FOO.dll
*** ERROR: Module load completed but symbols could not be loaded for FOO.dll
DBGHELP: FOO - no symbols loaded

Lors de la connexion de WinDbg au service dans un environnement de test, les piles gérées s'affichent correctement avec les noms de méthodes. Dépôt de mémoire et analyse locale du fichier DMP, je ne vois pas les noms dans les piles gérées. Qu'est-ce que je peux faire de mal?

Answer 1

Vous avez besoin des mêmes fichiers PDB. Les symboles de débogage ne fonctionneront pas avec un vidage au détail. Et vous avez besoin du fichier PDB provenant exactement de la même version.

Chaque fois que vous relâchez des bits dans la nature, votre équipe de construction doit stocker les fichiers PDB privés à titre de référence, au cas où vous devriez regarder six mois plus tard… [

Answer 2

Vous ne pouvez plus rien y faire pour le moment. Comme John Robbins dit :

  

La chose la plus importante à tous   les développeurs doivent savoir: les fichiers PDB sont   aussi important que le code source! ... j'ai   été à d'innombrables entreprises pour aider   les déboguer ces bugs coûtant des centaines   de milliers de dollars et personne ne peut   trouver les fichiers PDB pour la construction   s'exécutant sur un serveur de production.   Sans les fichiers PDB correspondants, vous   vient de faire votre défi de débogage   presque impossible.

Vous pouvez tenter votre chance avec un outil diabolique appelé ChkMatch , qui trompe VS accepter n'importe quel PDB que vous lancez. Sachez simplement que les chances d'obtenir des piles significatives sont proches de zéro. La structure de PE est extrêmement sensible aux modifications de code et, techniquement, même deux versions de source identique sont ne garantit pas le même PE .

[edit:] Désolé, vous venez de remarquer que vous utilisez WinDBG. Dans ce cas, comme le dit Remus, .reload / f / i peut réaliser le même tour (avec les mêmes risques).

Answer 3

OK, j'ai posé la mauvaise question. Je n'ai même pas besoin de symboles pour le code .NET (comme Remus l'a fait remarquer). Donc, ce n’est pas la réponse à ma question, mais c’est la solution à mon problème, qui semble être lié à la version .NET de la machine sur laquelle WinDbg est en cours d’exécution.

Je reçois des informations de pile significatives lorsque .chain me dit ceci:

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\sos: image 2.0.50727.**1433**, API 1.0.0, built Tue Oct 23 20:41:30 2007

(identique à celui utilisé sur le serveur sur lequel le vidage a été effectué.)

Je ne reçois aucune information autre que les adresses de ! clrstack lorsqu'elle est exécutée sur des ordinateurs où .chain m'indique:

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\sos: image 2.0.50727.**3053**, API 1.0.0, built Fri Jul 25 07:08:38 2008