Résolution des symboles WinDbg

Question

Lors de l'utilisation de WinDbg, où le privé fichiers de symboles (apb?) être placé?

Ma situation est la suivante: j'ai une DLL qui je veux de débogage. J'ai le code source et les fichiers de symboles de cette DLL. Cette DLL est appelée par une autre DLL (que je n'ai pas de symboles ou de la source) qui, à son tour, est appelé par un fichier EXE (que je n'ai pas aussi de symboles ou de la source).

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

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

Cet avertissement, je pense, est la raison pourquoi je reçois ce type de messages dans la pile d'appel:

Madll!Classe::AFunction+SomeHexAddress

Mon fichier de structure ressemble à quelque chose comme ceci:

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

L'appel de la dll: C\TheProgram\SomeSubfolder\appelant.???

Ma DLL que je veux debug: C:\TheProgram\SomeSubfolder\AnotherSubfolder\MyDll.dll

Note: j'ai mis le Symbole chemin du Fichier et le chemin du fichier Source à l'endroit où la DLL de débogage a été généré, dans mon espace de travail sur un lecteur différent de l'exe.. Mais je l'ai copier le pdb + fichiers de mappage et de le mettre sur la dll que je voulais debug..

Answer 1

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

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

Vous aussi poser la question, "où dois-je placer mon symboles pour ma DLL dans le chemin de symbole?"

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

Les étapes pour identifier incompatibles symboles.

1. !sym bruyant
2. .recharger
3. x Madll!*classe*
   *Il recharge votre fichier dll, vous pouvez tapez kb pour afficher la pile d'appel de la DLL qui doit se charger aussi bien.
4. !sym calme
   *Réinitialisation du retour à l'original calme symbole de chargement

Aussi, vous pouvez l'exécuter

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

Remarque: Si vous avez une somme de contrôle, puis Windbg peut correspondre à la somme de contrôle de la DLL contre la somme de contrôle de l'APB. Chaque environnement de développement a une autre façon de générer une somme de contrôle.

Voici la réponse pour les questions sur l'endroit où placer la Pdb

Si vous avez Madll.apb ajouté à un symbole de magasin, puis vous pouvez utiliser la syntaxe suivante

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

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

Toutefois, si vous avez juste l'APB localement, vous voudrez peut-être mettre le chemin d'accès à l'APB, d'abord avant de sortir pour le serveur de symbole comme ceci

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

De cette façon, Windbg devrait ressembler à proximité de votre SomSubFolder dir avant d'essayer d'utiliser les Symboles de cache du Serveur.

Merci, Aaron

Answer 2

Il n'importe pas où vous avez placé les fichiers de symboles aussi longtemps que vous êtes en mesure de dire le débogueur où ils sont.

L'avertissement que vous avez vu n' ont aucun effet sur la trace de la pile, mais le fait que vous êtes symboles manquants pour caller.DLL et app.EXE n'.

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

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

Vous de voir:

Madll!Classe::AFunction+SomeHexAddress

en fait ne veut rien dire tant que SomeHexAddress est raisonnable (et à condition que Madll.apb a été trouvé et chargé!) - il ressemble à une bonne pile d'appel à l'entrée.

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

P. S. vous n'avez pas besoin .fichier de la carte avec windbg.

Answer 3

Dans le cadre de notre processus de construction, nous avons la copie privée fichiers PDB et la sorti EXE/DLL fichiers vers un serveur de symbole. Dans sa plus simple expression, c'est juste un chemin d'accès UNC, mais vous pouvez le configurer pour accéder à l'aide de HTTP.

La copie de vos fichiers de sortie, utilisez la SYMSTORE.EXE programme.

Ensuite, configurez votre débogueur (nous utiliser Visual Studio et WinDbg) à chercher dans cette voie. Pour WinDbg, de 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

(qui doit être sur une seule ligne)

Cela configure WinDbg de regarder sur le Serveur de symboles Microsoft (mise en cache des fichiers C:\WebSymbols) et aussi à regarder dans un symbole local de store (\\symsvr\Symbols).

Nous utilisons également la Source outils de Serveur pour stocker SVN de détails dans le fichier PDB, ce qui signifie que nous pouvons revenir à la source exacte de fichier utilisé pour générer une version en particulier. Regarder en ...\Debugging Tools for Windows (x86)\srcsrv.

Answer 4

Une option consiste à laisser les fichiers de symboles là où ils se trouvent ( c'est-à-dire dans le dossier de sortie de génération ), puis à utiliser l'option de ligne de commande -y WinDbg 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.