Tengo una aplicación C++/CLI de modo mixto que usa WPF. Los bloqueos de nuestros clientes se informan como minivolcados a nuestro propio servidor.¿Cómo puedo obtener rastros de pila completos para minivolcados de modo mixto cuando están involucradas imágenes nativas (WPF)?
Cuando trato de investigar un minivolcado utilizando los comandos! Pe o! Clrstack de windbg sos-extension, A menudo obtengo información incompleta para los marcos de pila de los ensamblajes de WPF, p.
SP IP Function
0013E370 564618E3 PresentationFramework_ni!Unknown+0x1bf
0013E3A4 56461258 PresentationFramework_ni!Unknown+0x58
0013E3CC 5634C6D8 PresentationFramework_ni!Unknown+0x18
0013E3D8 55C04AA2 PresentationFramework_ni!Unknown+0x502
...
La pila de decodificación también es muy lenta en este caso. !
Usando SYM ruidosa muestra una gran cantidad de mensajes de lo siguiente de
SYMSRV: C:\Symbols\PresentationFramework.ni.dll\488F142Edab000\PresentationFramework.ni.dll not found
SYMSRV: http://msdl.microsoft.com/download/symbols/PresentationFramework.ni.dll/488F142Edab000/PresentationFramework.ni.dll not found
DBGHELP: C:\Program Files (x86)\Debugging Tools for Windows (x86)\PresentationFramework.ni.dll - file not found
DBGHELP: PresentationFramework.ni.dll not found in c:\Windows\System32
SYMSRV: C:\Symbols\PresentationFramework.ni.dll\488F142Edab000\PresentationFramework.ni.dll not found
SYMSRV: http://msdl.microsoft.com/download/symbols/PresentationFramework.ni.dll/488F142Edab000/PresentationFramework.ni.dll not found
DBGENG: C:\WINDOWS\assembly\NativeImages_v2.0.50727_32\PresentationFramewo#\9519494798a88867406b5755e1dbded6\PresentationFramework.ni.dll - Couldn't map image from disk.
SYMSRV: C:\Symbols\PresentationFramework.dll\488F142E50e000\PresentationFramework.dll not found
SYMSRV: http://msdl.microsoft.com/download/symbols/PresentationFramework.dll/488F142E50e000/PresentationFramework.dll not found
DBGHELP: C:\Program Files (x86)\Debugging Tools for Windows (x86)\PresentationFramework.dll - file not found
DBGHELP: PresentationFramework.dll not found in c:\Windows\System32
SYMSRV: C:\Symbols\PresentationFramework.dll\488F142E50e000\PresentationFramework.dll not found
SYMSRV: http://msdl.microsoft.com/download/symbols/PresentationFramework.dll/488F142E50e000/PresentationFramework.dll not found
DBGENG: C:\WINDOWS\assembly\GAC_MSIL\PresentationFramework\3.0.0.0__31bf3856ad364e35\PresentationFramework.dll image header does not match memory image header.
DBGENG: C:\WINDOWS\assembly\GAC_MSIL\PresentationFramework\3.0.0.0__31bf3856ad364e35\PresentationFramework.dll - Couldn't map image from disk.
Solía
c: \ Windows \ System32; SRV * C: \ Symbols * http: // MSDL. microsoft.com/download/symbols
como el símbolo de windbg y la ruta de la imagen.
Según lo que he entendido, esto solo sucede con las imágenes nativas .NET si la máquina en la que se produjo el bloqueo y la máquina con el depurador difieren en términos de la versión de Windows, versión .NET de SP. Lo he visto principalmente para imágenes nativas de WPF.
¿Qué puedo hacer para evitar este problema?
actualización a mi pregunta inicial:
me olvidó mencionar que tuve problemas con un problema similar con diferentes versiones mscordacwks DLL. Para usar SOS, se necesita la versión de mscordacwks.dll utilizada en la computadora bloqueada en la computadora de deglución. Así que comencé a recopilar varias versiones de este dll de diferentes combinaciones de Windows y SP y las puse en nuestro propio servidor de símbolos. Esto es bastante incómodo, por supuesto, y más aún porque necesitan ser nombrados siguiendo una convención especial (por ejemplo, mscordacwks_x86_x86_2.0.50727.4952.dll).
Si entiendo correctamente la respuesta de Rick desde abajo, tengo que hacer algo similar para las imágenes nativas de los ensamblados .NET a los que hacemos referencia. He intentado esto manualmente con un ejemplo (WindowsBase.ni.dll) pero no pude almacenar este dll en nuestro servidor de símbolos fácilmente. Parece que las imágenes nativas no son entendidas por symstore. El mensaje de error es de symstore:
SYMSTORE MESSAGE: Skipping file .\WindowsBase.ni.dll - not a known file type.
Así que trató de ponerlo en un directorio extra y lo añadió a mi símbolo o ruta de la imagen y luego SOS decodifica la WindowsBase_ni enmarca correctamente.
Pero todo esto parece un montón de molesto trabajo de configuración manual: obtener todas las imágenes nativas para varias versiones de .NET (qué pasa con los SP y las actualizaciones de seguridad), configurando el depurador manualmente porque no se puede usar el ...
¿Es esta la única manera?
Probablemente no sea un problema si puede controlar el entorno de sus clientes.Pero parece una pesadilla de depuración post-mortem para orgnizations que crean aplicaciones de modo mixto para grandes bases de usuarios.
Gracias por su explicación detallada! Pero todavía espero que haya otra manera ... He agregado más detalles a mi pregunta en la nueva sección "Actualización a mi pregunta inicial" –
@ Peter: Gracias por la información adicional. Su investigación muestra que realmente necesita las imágenes nativas (.ni.dll) para los ensamblajes, no los ensamblados en sí. De hecho, WinDbg no quiere el ensamblaje, solo su PDB y su imagen nativa, y el PDB de su imagen nativa. Solo veo dos soluciones. 1) Recoja todas las imágenes nativas relavadas y haga que estén disponibles para WinDbg, o 2) Recoja un volcado completo en lugar de minivolcado. Ninguno de los dos es muy atractivo. –
Lástima ... ¡Pero gracias de nuevo por tratar de ayudarme! Pero parece que Microsoft nos está dejando solos en esta área. Supongo que tengo que probar tu solución 1). ¿Sabes cómo solucionar el problema del almacén de archivos que mencioné (tratando de almacenar la imagen nativa falla)? –