Cualquier configuración de VC++ recomendada para un mejor análisis de PDB en las versiones de lanzamiento

Question

¿Existe alguna configuración de VC++ que deba conocer para generar mejores archivos PDB que contengan más información?

Tengo un sistema de análisis de volcado de memoria basado en el proyecto. crashrpt.

Además, mi servidor de compilación de producción tiene el código fuente instalado en D:\, pero mi máquina de desarrollo tiene el código fuente en C:\.Ingresé la ruta de origen en la configuración de VC++, pero cuando reviso la pila de llamadas de un bloqueo, no salta automáticamente a mi código fuente.Creo que si tuviera el código fuente de mi máquina de desarrollo en D:\ funcionaría.

Answer 1

"¿Hay alguna configuración de VC++ que deba conocer?"

Asegúrate de desactivar la omisión del puntero de fotograma.El blog de larry osterman tiene los detalles historicos sobre fpo y los problemas que causa con la depuración.

Los símbolos se cargaron exitosamente.Muestra la pila de llamadas, pero hacer doble clic en una entrada no me lleva al código fuente.

¿Qué versión de VS estás usando?(¿O estás usando Windbg?) ...en VS definitivamente debería solicitar la fuente la primera vez si no encuentra la ubicación.Sin embargo, también mantiene una lista de fuentes que "no se encontraron" para que no te la solicite cada vez.A veces la lista de no mirar es un fastidio...Para recuperar el mensaje, debe ir al Explorador de soluciones/nodo de solución/propiedades/propiedades de depuración y editar la lista de archivos en el panel inferior.

Finalmente, es posible que esté utilizando "símbolos eliminados".Estos son archivos pdb generados para proporcionar información de depuración para pasar la pila de llamadas más allá de FPO, pero sin las ubicaciones de origen (junto con otros datos).Los símbolos públicos de los componentes del sistema operativo Windows son pdbs eliminados.Para su propio código, estos simplemente causan dolor y no valen la pena a menos que proporcione sus pdb a externos.¿Cómo tendrías uno de estos horribles pdbs despojados?Es posible que los tenga si usa "binplace" con el comando -a.

¡Buena suerte!Una historia de minivolcado adecuada es una bendición para la depuración de producción.

Answer 2

Si compila directamente desde su sistema de administración de código fuente, debe anotar sus archivos pdb con los orígenes del archivo.Esto le permite recuperar automáticamente los archivos fuente exactos durante la depuración.(Este es el mismo proceso que se utiliza para recuperar el código fuente de .Net Framework).

Ver http://msdn.microsoft.com/en-us/magazine/cc163563.aspx para más información.Si utiliza subversion como SCM, puede consultar el proyecto SourceServerSharp.

Answer 3

Podrías intentar usar MS-DOS. sust. comando para asignar su directorio de código fuente a D:conducir.

Answer 4

Este es el procedimiento que utilicé después de un problema similar al tuyo:

a) Copié en el servidor de producción todos los archivos EXE y DLL que se crearon, cada uno con su PDB correspondiente en el mismo directorio, inicié el sistema y esperé a que ocurriera el bloqueo.

b) Copié todos los archivos EXE, DLL y PDB en la máquina de desarrollo (en una carpeta temporal) junto con el minivolcado (en la misma carpeta).Usé Visual Studio para cargar el minivolcado desde esa carpeta.

Dado que VS encontró los archivos fuente donde fueron compilados originalmente, siempre pudo identificarlos y cargarlos correctamente.Al igual que usted, en la máquina de producción la unidad utilizada no era C:, pero en la máquina de desarrollo sí.

Dos consejos más:

• Una cosa que hacía a menudo era copiar un EXE/DLL reconstruido y olvidarme de copiar el nuevo PDB.Esto arruinó el ciclo de depuración, VS no podría mostrarme la pila de llamadas.

• A veces recibía una pila de llamadas que no tenía sentido en VS.Después de un poco de dolor de cabeza, descubrí que windbg siempre me mostraba la pila correcta, pero VS a menudo no.No sé por qué.

Answer 5

Por si alguien está interesado, un compañero de trabajo me respondió esta pregunta por correo electrónico:

Artem escribió:

Hay una bandera para minidumpwritedump () que puede hacer mejores vertederos de choques que permitirán ver el estado del programa completo, con todas las variables globales, etc.En cuanto a las pilas de llamadas, dudo que puedan ser mejores debido a las optimizaciones ...A menos que apague (tal vez algunas) optimizaciones.

Además, creo que deshabilitar las funciones en línea y la optimización completa del programa ayudará bastante.

De hecho, hay muchos tipos de volcado, tal vez podría elegir uno lo suficientemente pequeño pero aún así tener más información http://msdn.microsoft.com/en-us/library/ms680519(VS.85).aspx

Sin embargo, esos tipos no ayudan con la pila de llamadas, solo afectan la cantidad de variables que podrá ver.

Noté que algunos de esos tipos de volcado no son compatibles con dbghelp.dll versión 5.1 que usamos.Sin embargo, podríamos actualizarlo a la versión más reciente y 6.9, acabo de verificar las herramientas de depuración de EULA para MS: la nueva dbghelp.dll todavía está bien para redistribuir.

Answer 6

¿Visual Studio le solicita la ruta al archivo fuente?Si no es así, entonces no cree que tenga símbolos para la pila de llamadas.Configurar la ruta de origen debería funcionar sin tener que asignar la ubicación original exacta.

Puede saber si los símbolos están cargados mirando la ventana 'módulos' en Visual Studio.

Suponiendo que esté creando una PDB, no creo que haya opciones que controlen la cantidad de información en la PDB directamente.Puede cambiar el tipo de optimizaciones realizadas por el compilador para mejorar la depuración, pero esto costará el rendimiento; como señala su compañero de trabajo, deshabilitar en línea ayudará a que las cosas sean más obvias en el archivo de fallo, pero tendrá un costo en tiempo de ejecución.

Dependiendo de la naturaleza de su aplicación, recomendaría trabajar con archivos de volcado completos si puede, son más grandes, pero le brindan toda la información sobre el proceso...y con qué frecuencia falla de todos modos :)

Answer 7

¿Visual Studio le está solicitando la ruta al archivo fuente?

No.

Si no es así, no cree que tenga símbolos para CallStack.Establecer la ruta de origen debe funcionar sin tener que mapear la ubicación original exacta.

Los símbolos se cargaron exitosamente.Muestra la pila de llamadas, pero hacer doble clic en una entrada no me lleva al código fuente.Por supuesto, puedo buscar en archivos la línea en cuestión, pero es un trabajo duro :)