visual studio - visual - Cualquier configuración de VC++ recomendada para un mejor análisis de PDB en compilaciones de versiones
visual studio core (7)
¿Hay alguna configuración de VC ++ que deba conocer para generar mejores archivos de PDB que contengan más información?
Tengo un sistema de análisis de volcado de emergencia basado en el proyecto crashrpt .
Además, mi servidor de generació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é a la ruta de origen en la configuración de VC ++, pero cuando miro a través de 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.
¿Visual Studio te está pidiendo la ruta al archivo fuente?
No.
Si no es así, no cree que tenga símbolos para la pila de llamadas. Establecer la ruta de origen debería funcionar sin tener que mapear la ubicación original exacta.
Los símbolos se cargan con éxito. Muestra la pila de llamadas, pero hacer doble clic en una entrada no me lleva al código fuente. Por supuesto, puedo buscar archivos en la línea en cuestión, pero este es un trabajo difícil :)
¿Visual Studio te está pidiendo la ruta al archivo fuente? Si no es así, no cree que tenga símbolos para la pila de llamadas. Establecer la ruta de origen debería funcionar sin tener que mapear la ubicación original exacta.
Puede ver si los símbolos se cargan mirando la ventana ''modules'' en Visual Studio.
Asumiendo que está construyendo un AP, entonces no creo que haya ninguna opción que controle directamente la cantidad de información en el AP. Puedes cambiar el tipo de optimizaciones realizadas por el compilador para mejorar la depuración, pero esto costará rendimiento, como señala tu compañero de trabajo, deshabilitar en línea ayudará a hacer las cosas más obvias en el archivo de bloqueo, pero costará en tiempo de ejecución.
Dependiendo de la naturaleza de su aplicación, le recomiendo que trabaje con archivos de volcado completo si puede, son más grandes, pero le doy toda la información sobre el proceso ... y con qué frecuencia se bloquea de todos modos :)
En caso de que 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 volcados de bloqueos que permitirán ver el estado completo del programa, 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 gire ( tal vez algunas) optimizaciones desactivadas.
Además, creo que la desactivación de las funciones en línea y la optimización de todo el programa ayudarán 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 ayudarán 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 la versión 5.1 de dbghelp.dll que usamos. Sin embargo, podríamos actualizarlo a la versión más nueva, 6.9. Acabo de consultar el EULA para herramientas de depuración de MS: el dbghelp.dll más nuevo todavía está en condiciones de redistribuirse.
Podría intentar usar el comando subst MS-DOS para asignar su directorio de código fuente a la unidad D :.
"¿Hay alguna configuración de VC ++ que deba conocer?"
Asegúrese de desactivar la omisión de puntero de marco. El blog de Larry osterman tiene los detalles históricos sobre fpo y los problemas que causa con la depuración.
Los símbolos se cargan con éxito. 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á usando Windbg?) ... en VS debería solicitar la fuente la primera vez si no encuentra la ubicación. Sin embargo, también mantiene una lista de las fuentes que no se encontraron, por lo que no se las solicita cada vez. A veces, la lista de no mirar es difícil ... para obtener una copia de seguridad necesita ir al explorador de solución / nodo de solución / propiedades / propiedades de depuración y editar la lista de archivos en el panel inferior.
Finalmente, podría estar usando ''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 con las ubicaciones de origen eliminadas (junto con otros datos). Los símbolos públicos para los componentes del sistema operativo de Windows son pdbs eliminados. Para su propio código, estos simplemente causan dolor y no valen la pena a menos que proporcione sus pdbs a los externos. ¿Cómo tendrías uno de estos horribles pdbs despojados? Puede tenerlos si usa "binplace" con el comando -a.
¡Buena suerte! Una historia correcta de mini volcado es un regalo del cielo para la depuración de la producción.
Este es el procedimiento que utilicé después de algunos problemas similares 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 se produjera el bloqueo.
b) Copió todos los archivos EXE, DLL y PDB a la máquina de desarrollo (a una carpeta temporal) junto con el minivolcado (en la misma carpeta). Usó Visual Studio para cargar el minivolcado desde esa carpeta.
Como VS encontró los archivos de origen donde se compilaron originalmente, siempre fue capaz de identificarlos y cargarlos correctamente. Al igual que con usted, en la máquina de producción el disco utilizado no era C :, sino en la máquina de desarrollo.
Dos consejos más:
Una cosa que hice a menudo fue copiar un EXE / DLL reconstruido y olvidar copiar el nuevo PDB. Esto arruinó el ciclo de depuración, VS no podría mostrarme la pila de llamadas.
A veces, obtuve una pila de llamadas que no tenía sentido en VS. Después de un dolor de cabeza, descubrí que windbg siempre me mostraba la pila correcta, pero a menudo VS no lo hacía. No sé por qué.
Si compila directamente desde su sistema de gestión de código fuente, debe anotar sus archivos pdb con los orígenes del archivo. Esto le permite buscar automáticamente los archivos fuente exactos durante la depuración. (Este es el mismo proceso utilizado para recuperar el código fuente del framework .Net).
Consulte http://msdn.microsoft.com/en-us/magazine/cc163563.aspx para obtener más información. Si usa subversion como su SCM, puede verificar el proyecto SourceServerSharp.