Résolution du symbole WinDbg

lors de L'utilisation de WinDbg, où les fichiers de symboles privés (pdb?) être placé?

Ma situation est: j'ai une DLL que je veux déboguer. J'ai le code source et les fichiers de symboles pour cette DLL. Cette DLL est appelée par une autre DLL (pour laquelle je n'ai pas de symboles ou de source) qui, à son tour, est appelée 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 que

*** avertissement: Impossible à vérifier somme de contrôle C:TheProgramSomeSubfolderAnotherSubfolderMyDll.dll

cet avertissement je pense est la raison pour laquelle je reçois le type suivant de messages dans la pile d'appels:

MyDll!AClass:: AFunction+SomeHexAddress

Mon fichier de structure ressemble à quelque chose comme ceci:

L'exe: C:TheProgramprogram.exe

l'appel dll: CTheProgramSomeSubfoldercaller.???

mon DLL que je veux déboguer: C:TheProgramSomeSubfolderAnotherSubfolderMyDll.dll

Note: je mets le chemin du fichier de symbole et le chemin du fichier Source à l'endroit où la DLL de débogage a été générée, dans mon espace de travail sur un lecteur différent de l'exe.. Mais j'ai copié les fichiers de carte de l'APB + et je l'ai mis sur la dll que je voulais déboguer..

30
demandé sur krebstar 2009-01-23 06:03:10

4 réponses

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 posez aussi la question, " Où est-ce que je mets mes symboles pour ma DLL dans le chemin des symboles?"

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

étapes à suivre pour identifier les symboles mal appariés.

  1. !sym bruyant
  2. .recharger
  3. x MyDll!*classe*

    *Ceci recharge votre dll, alternativement vous pouvez taper kb pour afficher la pile d'appels de la DLL qui devrait la charger aussi.
  4. !sym quiet!--5-->
    *Réinitialisation du retour à l'original calme symbole de chargement

vous pouvez aussi exécuter

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

Note: Si vous avez un checksum, alors Windbg peut faire correspondre le checksum de la DLL avec le checksum de L'APB. Chaque environnement de développement a une façon différente de générer un somme de contrôle.

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

si vous avez MyDll.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 l'a suggéré ci-dessus...

cependant si vous avez juste L'APB localement, vous pouvez mettre le chemin vers L'APB en premier avant de sortir vers le serveur de symboles comme ceci

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

de cette façon Windbg devrait avoir l'air local à votre SomSubFolder dir avant d'essayer d'utiliser le cache du serveur de symboles.

Merci, Aaron

42
répondu AaronBa 2009-02-21 21:46:29

peu importe où vous mettez des fichiers de symboles privés tant que vous pouvez dire au débogueur où ils sont.

L'avertissement que vous voyez ne pas avoir un effet sur la trace de pile, mais le fait que vous manquez des symboles pour l'appelant.DLL et app.EXE .

configurer les 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!AClass:: AFunction+Somehexadress
ne signifie en fait rien tant Qu'une adresse est raisonnable (et à condition que MyDll.apb a été trouvé et chargé!) - il ressemble à une entrée de pile d'appel correcte.

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

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

4
répondu deemok 2014-03-10 10:03:08

dans le cadre de notre processus de construction, nous copions les fichiers privés PDB et les fichiers EXE/DLL libérés sur un serveur de symboles. Dans sa forme la plus simple, c'est juste un chemin UNC, mais vous pouvez le configurer pour l'accès en utilisant HTTP.

pour copier vos fichiers de sortie, utilisez le SYMSTORE.Programme EXE.

ensuite, configurez votre débogueur (nous utilisons Visual Studio et WinDbg) pour regarder 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

(c' doit être sur une seule ligne)

cela configure WinDbg pour regarder sur le serveur de symboles de Microsoft (cache les fichiers C:\WebSymbols) et aussi pour regarder dans un magasin de symboles local (\symsvr\Symbols).

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

3
répondu Roger Lipscombe 2009-01-23 10:25:36

une option est de laisser les fichiers de symboles où ils sont (c'est à dire dans la construction du dossier de sortie) et ensuite utiliser -o option de ligne de commande WinDbg pour localiser ces fichiers. En utilisant cette approche doit 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
répondu jussij 2009-01-23 04:15:13