debugging - symbolic - Resolución de símbolo WinDbg

symbols windbg

Question

Al usar WinDbg, ¿dónde deberían colocarse los archivos de símbolos privados (pdb?).

Mi situación es la siguiente: tengo una DLL que quiero depurar. Tengo el código fuente y los archivos de símbolos para esta DLL. Esta DLL es llamada por otra DLL (para la cual no tengo símbolos o fuente) que, a su vez, es invocada por un EXE (para el que tampoco tengo símbolos ni fuentes).

Mi problema es que recibo una advertencia que dice

*** ADVERTENCIA: no se puede verificar la suma de comprobación para C: / TheProgram / SomeSubfolder / AnotherSubfolder / MyDll.dll

Esta advertencia, creo, es la razón por la cual recibo el siguiente tipo de mensajes en la pila de llamadas:

MyDll! AClass :: AFunction + SomeHexAddress

Mi estructura de archivos se ve así:

El exe: C: / TheProgram / program.exe

El dll que llama: C / TheProgram / SomeSubfolder / caller. ???

Mi DLL que quiero depurar: C: / TheProgram / SomeSubfolder / AnotherSubfolder / MyDll.dll

Nota: Establecí la ruta del archivo de símbolo y la ruta del archivo de origen en donde se generó la DLL de depuración, en mi espacio de trabajo en una unidad diferente del exe ... Pero copié los archivos de mapas pdb + y los puse en el dll que quería depurar..

Answer 1

Como parte de nuestro proceso de compilación, copiamos los archivos privados de PDB y los archivos EXE / DLL liberados en un servidor de símbolos. En su forma más simple, esta es solo una ruta UNC, pero puede configurarla para acceder usando HTTP.

Para copiar sus archivos de salida, use el programa SYMSTORE.EXE.

Luego, configure su depurador (usamos Visual Studio y WinDbg) para buscar en esa ruta. Para WinDbg, la forma más sencilla de hacerlo es establecer una variable de entorno:

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

(Todo debería estar en una línea)

Esto configura WinDbg para buscar en el servidor de símbolos de Microsoft (almacenando en caché los archivos en C: / WebSymbols) y también para buscar en un almacén de símbolos local ( //symsvr/Symbols ).

También usamos las herramientas del Servidor de origen para almacenar detalles de SVN en el archivo PDB, lo que significa que podemos volver al archivo de origen exacto utilizado para crear una versión en particular. Busque en .../Debugging Tools for Windows (x86)/srcsrv .

Answer 2

Lo siento por la respuesta tardía.
En su publicación, menciona que está viendo el siguiente mensaje de error.

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

También hace la pregunta, "¿dónde pongo mis símbolos para mi DLL en la ruta del símbolo?"

Aquí hay una respuesta para el primer problema:

Pasos para identificar símbolos que no coinciden.

1. ! sym ruidoso!
2. .recargar
3. x MyDll! * clase *
   * Esto recarga su dll, alternativamente puede escribir kb para mostrar la pila de llamadas de la DLL que también debe cargarla.
4. ! sym tranquilo
   * Restablecimiento de nuevo a la carga original silenciosa del símbolo

También puedes correr

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

Nota: Si tiene una suma de comprobación, Windbg puede hacer coincidir la suma de comprobación de la DLL con la suma de comprobación de la PDB. Cada entorno de desarrollo tiene una forma diferente de generar una suma de comprobación.

Aquí está la respuesta a las preguntas sobre dónde colocar los PDB

Si tiene MyDll.pdb agregado a un almacén de símbolos, puede usar la siguiente sintaxis

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

Como Roger ha sugerido anteriormente ...

Sin embargo, si solo tiene el PDB localmente, es posible que desee poner la ruta al PDB primero antes de ir al servidor de símbolos como este

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

De esta forma, Windbg debería verse localmente en su directorio SomSubFolder antes de intentar usar el caché del servidor Symbols.

Gracias, Aaron

Answer 3

No importa dónde coloque los archivos de símbolos privados, siempre que pueda decirle al depurador dónde están.

La advertencia que está viendo no tiene ningún efecto en el seguimiento de la pila, pero el hecho de que le falten símbolos para caller.DLL y app.EXE sí lo hace .

La configuración de símbolos en windbg (localmente) es tan simple como usar:

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

Usted viendo:

MyDll! AClass :: AFunction + SomeHexAddress

en realidad no significa nada siempre que SomeHexAddress sea razonable (¡y siempre que se haya encontrado y cargado MyDll.pdb!) - parece una entrada de pila de llamadas adecuada.

Ahora, mi pregunta sería, ¿cuál es el problema con el que estás atrapado?

PD: no necesitas el archivo .map con windbg.

Answer 4

Una opción es dejar los archivos de símbolos donde están ( es decir, en la carpeta de salida de compilación ) y luego usar la opción de línea de comando WinDbg para localizar estos archivos. El uso de este enfoque debería garantizar que los archivos de símbolos estén siempre actualizados.

De la ayuda 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.