WinDbg Dr. Watson minidump: ¿requiere pdb / dll originalmente creado para la versión instalada?

Question

Tengo un archivo mindmp del bloqueo de la aplicación de un objetivo. ¿Es posible para mí reconstruir los archivos dll / pdb para una versión de software y tener los símbolos de carga de windbg correctamente?

Mi problema es que nuestros archivos pdb solo se guardan para las versiones principales (desafortunadamente). Esta es una compilación diaria, que puedo reconstruir yo mismo, pero me estoy equivocando con errores.

Con! sym ruidoso en: El encabezado de la imagen "no coincide con el encabezado de la imagen de memoria" "

DBGENG:  C:\...\XXX.dll image header does not match memory image header.
DBGENG:  XXX.dll - Partial symbol image load missing image info
DBGHELP: Module is not fully loaded into memory.
DBGHELP: Searching for symbols using debugger-provided data.
DBGHELP: C:\...\XXX.pdb - mismatched pdb

Tenga en cuenta que he creado la pdb con la dll, son del mismo directorio RELEASE (¿debería estar creando una depuración?)

Las tesis son compilaciones de lanzamiento (ya que las compilaciones de lanzamiento están instaladas en el destino y se cuelgan). ¿Debería estar utilizando de alguna manera las dll de compilación de depuración para obtener más información sobre los símbolos?

Answer 1

En mi experiencia, probablemente no.

Si tiene el directorio de compilación exacto y la compilación con exactamente la misma configuración del compilador, esto podría funcionar. Definitivamente no podrá cargar símbolos de una compilación de depuración contra un volcado de descarga de la versión.

Deberá activar las opciones de 'cargar cualquier cosa': .symopt + 0x40 para que windbg ignore las diferencias de marca de tiempo.

Answer 2

La utilidad ChkMatch está diseñada para este escenario exacto. Siempre que tenga el .EXE original, puede volver a compilar las fuentes (con la misma configuración del compilador y del compilador) y parchear el nuevo .PDB para que coincida con el antiguo .EXE.

En este ejemplo, OriginalExecutable.exe es el ejecutable que ya no tiene un archivo .PDB, y RebuiltPDB.pdb se produjo al reconstruir el original fuente.

chkmatch -m OriginalExecutable.exe RebuiltPDB.pdb

Ahora, siempre que los dos archivos tengan sus nombres originales, el depurador debería aceptarlos como un par coincidente.

Answer 3

si aún tiene el código fuente exacto desde el que se compiló la imagen, luego reconstrúyalo produciendo un nuevo archivo pdb y luego indique a WinDbg que cargue este pdb a la fuerza cuando abra el volcado de seguridad, funcionó una vez en mi práctica.

Answer 4

Los archivos PDB están vinculados a sus archivos EXE mediante un GUID y una " age " (Es un número de secuencia). Estos están incrustados en el EXE, y en el PDB. El GUID se regenera en cada compilación completa, y la " edad " se cambia en cada construcción incremental.

El depurador los utiliza para asegurarse de que está buscando en el PDB correcto el archivo EXE.

No conocía el " chkmatch " herramienta mencionada por SteveMan, pero sospecho que funciona parcheando el GUID / age para que coincidan.

Answer 5

Esto es demasiado tarde para ayudar a Doug, pero por el bien de cualquiera que encuentre esta pregunta, otro hilo ( ¿Es posible cargar símbolos no coincidentes en Visual Studio? ) señaló una manera de hacer que WinDbg acepte archivos .PDB no coincidentes

.symopt_0x40