¿Qué me proporciona el PDB durante la depuración y cómo sé que está funcionando?

Question

Tengo que usar un componente de terceros sin código fuente. Tengo el archivo DLL de lanzamiento y el archivo PDB de lanzamiento. Vamos a llamarlo 'CorporateComponent.dll'. Mi propio código crea objetos a partir de esta DLL y llama a métodos sobre estos objetos.

CorpObject o = new CorpObject(); 
Int32 result = o.DoSomethingLousy(); 

Durante la depuración, el método 'DoSomethingLousy' arroja una excepción. ¿Qué hace el archivo PDB por mí? Si hace algo bueno, ¿cómo puedo estar seguro de que lo estoy usando?

Answer 1

Para confirmar si está utilizando el PDB proporcionado, CorporateComponent.pdb, durante la depuración dentro del IDE de Visual Studio, revise la ventana de salida y ubique la línea lo que indica que CorporateComponent.dll está cargado y seguido por la cadena Symbols loaded.

Para ilustrar de un proyecto de mina:

The thread 0x6a0 has exited with code 0 (0x0). 
The thread 0x1f78 has exited with code 0 (0x0). 
'AvayaConfigurationService.vshost.exe' (Managed): Loaded 'C:\Development\Src\trunk\ntity\AvayaConfigurationService\AvayaConfigurationService\bin\Debug \AvayaConfigurationService.exe', Symbols loaded. 
'AvayaConfigurationService.vshost.exe' (Managed): Loaded 'C:\Development\Src\trunk\ntity\AvayaConfigurationService\AvayaConfigurationService\bin\Debug\IPOConfigService.dll', No symbols loaded. 

Loaded 'C:\Development\src...\bin\Debug\AvayaConfigurationService.exe', Symbols loaded.

Esto indica que el AP se encontró y se carga por el depurador IDE.

Según lo indicado por otros Al examinar los marcos de pila dentro de su aplicación, debería poder ver los símbolos de CorporateComponent.pdb. Si no lo hace, tal vez el tercero no incluyó la información del símbolo en la versión PDB de lanzamiento.

Answer 2

El PDB es un archivo de base de datos que asigna las instrucciones a sus números de línea en el código original para que cuando obtenga un seguimiento de pila obtenga los números de línea para el código. Si se trata de una DLL no administrada, el archivo PDB también le dará los nombres de las funciones en el seguimiento de la pila, mientras que esa información generalmente solo está disponible para las DLL administradas sin PDB.

Answer 3

Lo principal que obtengo del pdb son los números de línea y los nombres reales de los métodos para los rastros de pila.

Answer 4

El pdb contiene información que el depurador necesita para leer correctamente la pila. Sus trazados de pila contendrán números de línea y nombres de símbolos de los marcos de pila dentro de los módulos para los que tiene el pdb.

Voy a dar ejemplos de dos usos. El primero es la respuesta obvia. El segundo explica los pdb indexados por fuente.

primero ejemplo de uso ...

Dependiendo de convención de llamada, y que optimizaciones del compilador utilizado, puede que no sea posible que el depurador para desconectar manualmente la pila a través de un módulo para el que no tiene un AP. Esto puede suceder con ciertas bibliotecas de terceros e incluso algunas partes del sistema operativo.

Considere un escenario en el que encuentra una infracción de acceso dentro del sistema operativo de Windows. El seguimiento de la pila no se desenrolla en su propia aplicación porque ese componente del sistema operativo usa una convención de llamadas especial que confunde al depurador. Si configura la ruta de su símbolo para descargar los pdb del sistema operativo público, es muy probable que la traza de la pila se desenrolle en su aplicación. Eso le permite ver exactamente qué argumentos pasó su propio código en la llamada al sistema operativo. (Y ejemplo similar de AV en el interior de una biblioteca tercera parte o incluso dentro de su propio código)

segundo ejemplo de uso ...

APP de tener otra propiedad muy útil - que puede integrarse con algunos sistemas de control de origen usando una característica que Microsoft llama "indexación de fuente". Un pdb indexado en origen contiene comandos de control de origen que especifican cómo obtener del control de origen las versiones de archivo exactas que se usaron para compilar el componente. Los depuradores de Microsoft entienden cómo ejecutar los comandos para obtener automáticamente los archivos durante una sesión de depuración. Esta es una característica poderosa que evita que el generador de errores tenga que sincronizar manualmente un árbol fuente con la etiqueta correcta para una compilación determinada. Es especialmente útil para las sesiones remotas de depuración y para analizar los volcados de emergencia post-mortem.

La instalación de "herramientas de depuración para windows" (windbg) contiene un documento llamado srcsrv.doc que proporciona un ejemplo que demuestra cómo usar srctool.exe para determinar qué archivos de origen están indexados en un determinado pdb.

Para responder a su pregunta "¿cómo sé?", La función de "módulos" en el depurador puede indicar qué módulos tienen un pdb correspondiente. En windbg utiliza el comando "lml". En Visual Studio, seleccione módulos de algún lugar de los menús de depuración.(Lo siento, no tengo a mano una versión actual de visual studio)