Post mortem depuración crash-volcado sin tener la versión exacta de un archivo DLL de Windows en el servidor de símbolos

Question

Dentro de mi solicitud, yo uso la función MiniDumpWriteDump (ver dbghelp.dll) para escribir un archivo de volcado cada vez que mis bloqueos de la aplicación.

También uso un servidor de símbolos para almacenar todos mis archivos ejecutables y archivos PDB, por lo que cada vez que un cliente me envía un archivo crash-volcado, el depurador selecciona automáticamente la versión correcta del ejecutable y la información de depuración.

También la tienda de DLL de Windows (ntdll.dll, kernel32.dll, ...) y su información de depuración en el servidor de símbolos (usando Symchk). La información de depuración se obtiene de servidor de símbolos público de Microsoft.

La mayoría de las veces esto funciona perfecto, excepto cuando:

• se bloquea un cliente en uno de los DLL de Windows
• y el cliente utiliza la DLL que no he puesto en el servidor de símbolos

Esto se debe a que es bastante deshacer para almacenar todos los sabores de cada DLL de Windows en el servidor de símbolos (especialmente con los parches semanales).

Por lo tanto, si un cliente se estrella en, digamos, la versión 5.2.123.456 de NTDLL.DLL, y yo no puse esta versión exacta de la DLL en mi servidor de símbolos, entonces yo estoy atascado. Incluso servidor de símbolos pública de Microsoft no ayuda, ya que sólo proporciona la información de depuración, no de la propia DLL.

Mi solución actual es preguntar al cliente por su DLL, pero eso no siempre es fácil. Por lo tanto estoy buscando una solución mejor.

¿Hay una manera de conseguir el depurador muestra una pila de llamadas correcta, o cargar la información de depuración de una DLL específica, incluso si usted no tiene la versión exacta de la DLL?

Por otra parte, hay una manera de conseguir todas las versiones de todos (o el importante) de Windows DLL (de Microsoft)?

EDIT:

Por el momento me pareció una manera muy fácil de resolver este problema. Con la ModuleRescue utilidad (ver http://www.debuginfo.com/tools/modulerescue.html ) puede generar ficticia DLL desde un archivo de minivolcado. Con estos ficticia DLL, el depurador está satisfecho, y empieza a cargar correctamente los símbolos de depuración de los servidores de Microsoft.

Answer 1

Es posible relajar resolución símbolo de WinDBG; ver mi responder a una pregunta similar. Por otro lado, la solución que propongo aquí se basa en el hecho de que los archivos DLL son idénticos aparte de tener diferentes GUID que identifican sus símbolos de depuración. Una versión diferente de un archivo DLL es probable que va a tener una binaria diferente, por lo que los símbolos probablemente no van a coincidir correctamente incluso si usted puede conseguir que se carguen.

Answer 2

Estoy bastante seguro servidor de símbolos de Microsoft también proporciona los binarios. Busco en mi tienda y veo un montón de archivos de Microsoft .dll. He mi _NT_SYMBOL_PATH definido como

SRV*F:\Symbols\Microsoft*http://msdl.microsoft.com/download/symbols

De esta manera se buscará mi tienda local en primer lugar antes de intentar copiar hacia abajo desde un servidor público de Microsoft.

Answer 3

Puede tener múltiple servidores de símbolos en su ruta de símbolo. Así que simplemente configurar la ruta de símbolo para señalar a su propio servidor para sus propios módulos privadas, y para el servidor MS pública para los módulos del sistema operativo, consulte ruta de símbolo :

  

Esto se puede combinar fácilmente con la   Microsoft símbolo público almacén mediante   el siguiente ajuste inicial:

     

_NT_SYMBOL_PATH=srv*c:\mysymbols*http://msdl.microsoft.com/download/symbols;cache*c:\mysymbols

El href="http://msdn.microsoft.com/en-us/library/cc266473.aspx" rel="nofollow noreferrer"> Microsoft Pública Símbolo tienda se documenta como http://msdl.microsoft.com/download/symbols .

Answer 4

? ¿Qué parte no está funcionando?

Nunca he estado en su situación, exactamente, pero yo esperaría que el depurador para darle la parte correcta de la pila de llamadas que se encontraba en su código, hasta la llamada a la DLL oscuro. Por supuesto, a partir de ahí a los símbolos reales de choques no estaría disponible, pero no se puede ver lo que NTDLL API estaba siendo llamado y qué argumentos se hicieron pasar a esa llamada?

Usted no dice qué herramienta está utilizando para la depuración minidump:. WinDBG o VS