web-dev-qa-db-fra.com

Résolution des symboles WinDbg

Lorsque vous utilisez WinDbg, où placer les fichiers de symboles privés (pdb?)?

Ma situation est la suivante: j'ai un DLL que je veux déboguer. J'ai le code source et les fichiers de symboles pour cette DLL. Ce DLL est appelé par un autre DLL (pour laquelle je n'ai ni symboles ni source) qui, à son tour, est appelé par un EXE (pour lequel je n'ai pas non plus de symboles ou de source)).

Mon problème est que je reçois un avertissement qui dit

*** AVERTISSEMENT: impossible de vérifier la somme de contrôle pour C:\TheProgram\SomeSubfolder\AnotherSubfolder\MyDll.dll

Je pense que cet avertissement est la raison pour laquelle j'obtiens le type de messages suivant dans la pile d'appels:

MyDll! AClass :: AFunction + SomeHexAddress

Ma structure de fichiers ressemble à ceci:

L'exe: C:\TheProgram\program.exe

La DLL appelante: C\TheProgram\SomeSubfolder\caller. ???

Mon DLL que je veux déboguer: C:\TheProgram\SomeSubfolder\AnotherSubfolder\MyDll.dll

Remarque: J'ai défini le chemin du fichier de symboles et le chemin du fichier source à l'endroit où le débogage DLL a été généré, dans mon espace de travail sur un lecteur différent de l'exe .. Mais j'ai copié les fichiers de carte pdb + et le mettre sur la DLL que je voulais déboguer ..

34
krebstar

Désolé pour la réponse tardive.
Dans votre message, vous mentionnez que vous voyez le message d'erreur suivant.

*** WARNING: Unable to verify checksum for C:\TheProgram\SomeSubfolder\AnotherSubfolder\MyDll.dll

Vous posez également la question "Où dois-je placer mes symboles pour mon DLL dans le chemin du symbole?"

Voici une réponse pour le premier problème:

Étapes pour identifier les symboles incompatibles.

  1. ! sym bruyant
  2. .recharger
  3. x MyDll! * classe *
    * Cela recharge votre DLL, vous pouvez également taper kb pour afficher la pile d'appels de la DLL qui devrait également la charger.
  4. ! sym calme
    * Réinitialiser le chargement du symbole silencieux d'origine

Vous pouvez également exécuter

0:001> lmv m myDll  *(and examine the Checksum)

Remarque: Si vous avez une somme de contrôle, Windbg peut faire correspondre la somme de contrôle de DLL avec la somme de contrôle de la PDB. Chaque environnement de développement a une manière différente de générer une somme de contrôle.

Voici la réponse aux questions sur où placer les PDB

Si vous avez ajouté MyDll.pdb à un magasin de symboles, vous pouvez utiliser la syntaxe suivante

.sympath SRV*c:\symcache*http://msdl.Microsoft.com/download/symbols 

Comme Roger l'a suggéré ci-dessus ...

Cependant, si vous n'avez que la PDB localement, vous voudrez peut-être d'abord mettre le chemin vers la PDB avant de vous rendre sur le serveur de symboles comme celui-ci

.sympath C:\TheProgram\SomeSubfolder\AnotherSubfolder\;SRV*c:\symcache*http://msdl.Microsoft.com/download/symbols

De cette façon, Windbg doit ressembler localement à votre répertoire SomSubFolder avant d'essayer d'utiliser le cache du serveur de symboles.

Merci, Aaron

46
AaronBa

Peu importe où vous placez des fichiers de symboles privés tant que vous êtes en mesure de dire au débogueur où ils se trouvent.

L'avertissement que vous voyez ne fait pas avoir un effet sur la trace de la pile, mais le fait qu'il manque des symboles pour caller.DLL et app.EXE est-ce que.

La configuration des symboles dans windbg (localement) est aussi simple que d'utiliser:

.sympath [+] path_to_pdbs
*et
. symfix + path_to_system_pdb_store

Vous voyez:

MyDll! AClass :: AFunction + SomeHexAddress

Maintenant, ma question serait, quel est le problème avec lequel vous êtes coincé?

P.S. vous n'avez pas besoin du fichier .map avec windbg.

4
deemok

Dans le cadre de notre processus de génération, nous copions les fichiers PDB privés et les fichiers EXE/DLL publiés sur un serveur de symboles. Dans sa forme la plus simple, ce n'est qu'un chemin UNC, mais vous pouvez le configurer pour l'accès à l'aide de HTTP.

Pour copier vos fichiers de sortie, utilisez le programme SYMSTORE.EXE.

Ensuite, configurez votre débogueur (nous utilisons Visual Studio et WinDbg) pour rechercher dans ce chemin. Pour WinDbg, la façon la plus simple de le faire est de définir une variable d'environnement:

_NT_SYMBOL_PATH=
    SRV*C:\WebSymbols*http://msdl.Microsoft.com/download/symbols;
    \\symsvr\Symbols

(cela devrait être sur une seule ligne)

Cela configure WinDbg pour rechercher sur le Microsoft Symbol Server (mise en cache des fichiers dans C:\WebSymbols) et également pour rechercher dans un magasin de symboles local (\\symsvr\Symbols).

Nous utilisons également les outils du serveur source pour stocker les détails SVN dans le fichier PDB, ce qui signifie que nous pouvons revenir au fichier source exact utilisé pour créer une version particulière. Regardez dans ...\Debugging Tools for Windows (x86)\srcsrv.

3
Roger Lipscombe

Une option consiste à laisser les fichiers de symboles où ils se trouvent ( c'est-à-dire dans le dossier de sortie de la construction ), puis à utiliser - y WinDbg option de ligne de commande pour localiser ces fichiers. L'utilisation de cette approche devrait garantir que les fichiers de symboles sont toujours à jour.

Dans l'aide de Microsoft:

-y SymbolPath 
Specifies the symbol search path. Separate multiple paths with a 
semicolon (;). If the path contains spaces, it should be enclosed 
in quotation marks. For details, and for other ways to change this 
path, see Symbol Path. 
2
jussij