volcado son sistema sirve que para memoria los errores crear archivos archivo debugging windbg dump

debugging - son - para que sirve el volcado de memoria



WinDbg x64: no se puede depurar un volcado de memoria: no se pudo cargar la DLL de acceso a datos (4)

Adjunté WinDbg a un proceso en ejecución y tuve el proceso bloqueado (tengo una pregunta separada respecto a ese caso). Una vez que el programa falló, WinDbg se detuvo y me permitió depurar el programa. Tomé un volcado para una investigación más profunda con un comando ".dump / ma".

El programa se compiló como "Cualquier CPU" y usé WinDbg x64 para tomar el volcado. Ahora abro WinDbg x64 en la misma computadora otra vez y abro el volcado de memoria. Esto es lo que dice:

Loading Dump File [C:/crashdump.dmp] User Mini Dump File with Full Memory: Only application data is available Symbol search path is: SRV*c:/symbols*http://msdl.microsoft.com/download/symbols Executable search path is: Windows 7 Version 7601 (Service Pack 1) MP (8 procs) Free x64 Product: WinNt, suite: SingleUserTS Machine Name: Debug session time: Mon Aug 15 10:24:57.000 2011 (UTC + 1:00) System Uptime: 17 days 0:54:39.021 Process Uptime: 12 days 14:01:31.000 ................................................................ ............................................................... This dump file has an exception of interest stored in it. The stored exception information can be accessed via .ecxr. (1be0.b78): Access violation - code c0000005 (first/second chance not available) *** WARNING: symbols timestamp is wrong 0x4dd2333e 0x4da4281c for clr.dll clr!WKS::gc_heap::find_first_object+0x92: 000007fe`ea129a1d f70100000080 test dword ptr [rcx],80000000h ds:00000000`00003d80=????????

Luego trato de cargar SOS por ".load sos clr" y se produce un error en:

The call to LoadLibrary(sos clr) failed, Win32 error 0n2 "The system cannot find the file specified." Please check your debugger configuration and/or network access.

Intentando con ".loadby sos clr" y funciona. Ahora quiero ver la pila con "! Clrstack" y quedarme aquí:

Failed to load data access DLL, 0x80004005 Verify that 1) you have a recent build of the debugger (6.2.14 or newer) 2) the file mscordacwks.dll that matches your version of clr.dll is in the version directory 3) or, if you are debugging a dump file, verify that the file mscordacwks_<arch>_<arch>_<version>.dll is on your symbol path. 4) you are debugging on the same architecture as the dump file. For example, an IA64 dump file must be debugged on an IA64 machine. You can also run the debugger command .cordll to control the debugger''s load of mscordacwks.dll. .cordll -ve -u -l will do a verbose reload. If that succeeds, the SOS command should work on retry. If you are debugging a minidump, you need to make sure that your executable path is pointing to clr.dll as well.

Probé ".symfix" y ".reload":

0:027> .symfix 0:027> .reload ..................*** WARNING: symbols timestamp is wrong 0x4dd2333e 0x4da4281c for clr.dll .............................................. ...............................................................

Atascado. Al mismo tiempo, cuando el proceso se ejecuta en WinDgb, puedo pausar la ejecución, cargar SOS y ejecutar el comando "! Clrstack" con éxito.

¿Algunas ideas? Gracias.

ACTUALIZACIÓN - Siguió los pasos proporcionados en la segunda respuesta, aún no funciona.

1) Ruta de mis símbolos: SRV * c: / symbols * http: //msdl.microsoft.com/download/symbols; srv *

2) CLR cargado: 4.0.30319. 237 :

0:027> lm v clr Unknown option ''r'' start end module name 00000000`77b60000 00000000`77d09000 ntdll (pdb symbols) c:/symbols/ntdll.pdb/6192BFDB9F04442995FFCB0BE95172E12/ntdll.pdb Loaded symbol image file: ntdll.dll Image path: C:/Windows/System32/ntdll.dll Image name: ntdll.dll Timestamp: Sat Nov 20 13:11:21 2010 (4CE7C8F9) CheckSum: 001B55EA ImageSize: 001A9000 File version: 6.1.7601.17514 Product version: 6.1.7601.17514 File flags: 0 (Mask 3F) File OS: 40004 NT Win32 File type: 2.0 Dll File date: 00000000.00000000 Translations: 0409.04b0 CompanyName: Microsoft Corporation ProductName: Microsoft® Windows® Operating System InternalName: ntdll.dll OriginalFilename: ntdll.dll ProductVersion: 6.1.7601.17514 FileVersion: 6.1.7601.17514 (win7sp1_rtm.101119-1850) FileDescription: NT Layer DLL LegalCopyright: © Microsoft Corporation. All rights reserved. 000007fe`e9fb0000 000007fe`ea915000 clr # (pdb symbols) c:/symbols/clr.pdb/1A7EA01DA29549DAB2B0BD012A6C5BA12/clr.pdb Loaded symbol image file: clr.dll Image path: C:/Windows/Microsoft.NET/Framework64/v4.0.30319/clr.dll Image name: clr.dll Timestamp: Tue May 17 09:35:10 2011 (4DD2333E) CheckSum: 00967144 ImageSize: 00965000 File version: 4.0.30319.237 Product version: 4.0.30319.237 File flags: 8 (Mask 3F) Private File OS: 4 Unknown Win32 File type: 2.0 Dll File date: 00000000.00000000 Translations: 0409.04b0 CompanyName: Microsoft Corporation ProductName: Microsoft® .NET Framework InternalName: clr.dll OriginalFilename: clr.dll ProductVersion: 4.0.30319.235 FileVersion: 4.0.30319.235 (RTMGDR.030319-2300) PrivateBuild: DDBLD240 FileDescription: Microsoft .NET Runtime Common Language Runtime - WorkStation LegalCopyright: © Microsoft Corporation. All rights reserved. Comments: Flavor=Retail

3) "C: / Windows / Microsoft.NET / Framework64 / v4.0.30319 / mscordacwks.dll" tiene la versión 4.0.30319. 239

4) Encontré que al cargar el volcado en WinDbg, se carga el "mscordacwks.dll" correcto desde la web, por lo tanto, en la carpeta "C: / symbols / mscordacwks_AMD64_AMD64_4.0.30319.237.dll / 4DD2333E965000" Tengo el archivo " mscordacwks_AMD64_AMD64_4.0.30319.237.dll ".

5)

0:027> .cordll -ve -u -l CLR DLL status: No load attempts

6)

0:027> !sym noisy noisy mode - symbol prompts on 0:027> .restart Loading Dump File [C:/crashdump.dmp] User Mini Dump File with Full Memory: Only application data is available DBGHELP: Symbol Search Path: srv*;srv*c:/symbols*http://msdl.microsoft.com/download/symbols DBGHELP: Symbol Search Path: cache*;SRV*http://msdl.microsoft.com/download/symbols;srv*c:/symbols*http://msdl.microsoft.com/download/symbols DBGHELP: Symbol Search Path: cache*;SRV*http://msdl.microsoft.com/download/symbols;srv*c:/symbols*http://msdl.microsoft.com/download/symbols Symbol search path is: srv*;SRV*c:/symbols*http://msdl.microsoft.com/download/symbols Executable search path is: Windows 7 Version 7601 (Service Pack 1) MP (8 procs) Free x64 Product: WinNt, suite: SingleUserTS Machine Name: Debug session time: Mon Aug 15 10:24:57.000 2011 (UTC + 1:00) System Uptime: 17 days 0:54:39.021 Process Uptime: 12 days 14:01:31.000 ................................................................ ............................................................... DBGHELP: ntdll - public symbols C:/Program Files/Debugging Tools for Windows (x64)/sym/ntdll.pdb/6192BFDB9F04442995FFCB0BE95172E12/ntdll.pdb DBGHELP: Symbol Search Path: cache*;SRV*http://msdl.microsoft.com/download/symbols;srv*c:/symbols*http://msdl.microsoft.com/download/symbols DBGHELP: Symbol Search Path: cache*;SRV*http://msdl.microsoft.com/download/symbols;srv*c:/symbols*http://msdl.microsoft.com/download/symbols This dump file has an exception of interest stored in it. The stored exception information can be accessed via .ecxr. (1be0.b78): Access violation - code c0000005 (first/second chance not available) *** WARNING: symbols timestamp is wrong 0x4dd2333e 0x4da4281c for clr.dll DBGHELP: clr - public symbols C:/Program Files/Debugging Tools for Windows (x64)/sym/clr.pdb/1A7EA01DA29549DAB2B0BD012A6C5BA12/clr.pdb clr!WKS::gc_heap::find_first_object+0x92: 000007fe`ea129a1d f70100000080 test dword ptr [rcx],80000000h ds:00000000`00003d80=????????

7)

0:027> !clrstack SYMSRV: C:/Program Files/Debugging Tools for Windows (x64)/sym/mscordacwks_AMD64_AMD64_4.0.30319.237.dll/4DD2333E965000/mscordacwks_AMD64_AMD64_4.0.30319.237.dll not found SYMSRV: mscordacwks_AMD64_AMD64_4.0.30319.237.dll from http://msdl.microsoft.com/download/symbols: 502892 bytes - copied DBGHELP: C:/Program Files/Debugging Tools for Windows (x64)/sym/mscordacwks_AMD64_AMD64_4.0.30319.237.dll/4DD2333E965000/mscordacwks_AMD64_AMD64_4.0.30319.237.dll cached to C:/Program Files/Debugging Tools for Windows (x64)/sym/mscordacwks_AMD64_AMD64_4.0.30319.237.dll/4DD233F317b000/mscordacwks_AMD64_AMD64_4.0.30319.237.dll DBGHELP: C:/Program Files/Debugging Tools for Windows (x64)/sym/mscordacwks_AMD64_AMD64_4.0.30319.237.dll/4DD233F317b000/mscordacwks_AMD64_AMD64_4.0.30319.237.dll - OK Failed to load data access DLL, 0x80004005 Verify that 1) you have a recent build of the debugger (6.2.14 or newer) 2) the file mscordacwks.dll that matches your version of clr.dll is in the version directory 3) or, if you are debugging a dump file, verify that the file mscordacwks_<arch>_<arch>_<version>.dll is on your symbol path. 4) you are debugging on the same architecture as the dump file. For example, an IA64 dump file must be debugged on an IA64 machine. You can also run the debugger command .cordll to control the debugger''s load of mscordacwks.dll. .cordll -ve -u -l will do a verbose reload. If that succeeds, the SOS command should work on retry. If you are debugging a minidump, you need to make sure that your executable path is pointing to clr.dll as well.

¿El proceso que está intentando depurar es de 32 bits? ¿Qué dice la lista de procesos de administrador de tareas? Si su proceso de 32 bits necesita usar windbg de 32 bits. De lo contrario, no veo por qué .load sos clr debería fallar.

ps: (windbg noob alert), así que me disculpo si esto suena cojo. Sólo trato de ayudar.

Acabo de pasar el día depurando un montón de casos en los que nos encontramos con este escenario. El SOS + CLR en el mismo cuadro que el bloqueo no pudo cargarse dentro de WinDbg, y "lm v" informó dos versiones diferentes para el mismo módulo:

0:011> lm vM *clr.dll start end module name 000007fe`f2f50000 000007fe`f38b0000 clr # (pdb symbols) c:/symbols/clr.pdb/EDFF900AC9B94C1D9B32696A7759891A2/clr.pdb Loaded symbol image file: clr.dll Image path: C:/Windows/Microsoft.NET/Framework64/v4.0.30319/clr.dll Image name: clr.dll Timestamp: Sun Apr 21 03:36:04 2013 (5173C114) CheckSum: 0095F379 ImageSize: 00960000 File version: 4.0.30319.18052 Product version: 4.0.30319.18052 File flags: 8 (Mask 3F) Private File OS: 4 Unknown Win32 File type: 2.0 Dll File date: 00000000.00000000 Translations: 0409.04b0 CompanyName: Microsoft Corporation ProductName: Microsoft® .NET Framework InternalName: clr.dll OriginalFilename: clr.dll ProductVersion: 4.0.30319.18047 FileVersion: 4.0.30319.18047 built by: FX45RTMGDR PrivateBuild: DDBLD320 FileDescription: Microsoft .NET Runtime Common Language Runtime - WorkStation LegalCopyright: © Microsoft Corporation. All rights reserved. Comments: Flavor=Retail

Detalles de respaldo

El archivo Timestamp (0x5173C114), Checksum (0x0095F379) y la Versión (4.0.30319.18052) almacenados en la estructura MINIDUMP_MODULE en el minidump''s module-list-stream fueron para el CLR más nuevo. Abriendo el archivo minidump abriéndolo y observando directamente los datos del flujo:

MINIDUMP_MODULE : (pack:8 size:112) +0x000 .BaseOfImage UInt64 : 8791579230208 (0x7FEF2F50000) +0x008 .SizeOfImage UInt32 : 9830400 (0x960000) +0x00C .CheckSum UInt32 : 9827193 (0x95F379) +0x010 .TimeDateStamp UInt32 : 1366540564 (0x5173C114) +0x014 .ModuleNameRva UInt32 : 107828 (0x1A534) +0x018 .VersionInfo tagVS_FIXEDFILEINFO : (pack:8 size:52) +0x000 .dwSignature UInt32 : 4277077181 (0xFEEF04BD) +0x004 .dwStrucVersion UInt32 : 65536 (0x10000) +0x008 .dwFileVersionMS UInt32 : 262144 (0x40000) +0x00C .dwFileVersionLS UInt32 : 1987004036 (0x766F4684)

Al dividir las palabras altas y bajas de dwFileVersionMS obtenemos 4 y 0.
Al dividir las palabras altas y bajas de dwFileVersionLS obtenemos 30319 y 18052.


Usando dumpchk.exe , y viendo los detalles del módulo en el PEB, podemos ver una marca de tiempo diferente (0x515530CE), una que corresponde a la versión anterior (18047):

7fef2f50000 515530ce Mar 28 23:12:30 2013 C:/Windows/Microsoft.NET/Framework64/v4.0.30319/clr.dll


Mirando la memoria en bruto en el volcado de memoria donde se carga clr.dll, puede ver la suma de comprobación (0x00965F80) y la marca de tiempo (0x515530CE) de la versión 4.0.30319.18047:

0:011> db 000007fe`f2f50000 000007fe`f2f50000 4d 5a 90 00 03 00 00 00-04 00 00 00 ff ff 00 00 MZ.............. 000007fe`f2f50010 b8 00 00 00 00 00 00 00-40 00 00 00 00 00 00 00 ........@....... 000007fe`f2f50020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 000007fe`f2f50030 00 00 00 00 00 00 00 00-00 00 00 00 18 01 00 00 ................ 000007fe`f2f50040 0e 1f ba 0e 00 b4 09 cd-21 b8 01 4c cd 21 54 68 ........!..L.!Th 000007fe`f2f50050 69 73 20 70 72 6f 67 72-61 6d 20 63 61 6e 6e 6f is program canno 000007fe`f2f50060 74 20 62 65 20 72 75 6e-20 69 6e 20 44 4f 53 20 t be run in DOS 000007fe`f2f50070 6d 6f 64 65 2e 0d 0d 0a-24 00 00 00 00 00 00 00 mode....$....... 0:011> db 000007fe`f2f50080 39 e4 28 ed 7d 85 46 be-7d 85 46 be 7d 85 46 be 9.(.}.F.}.F.}.F. 000007fe`f2f50090 81 f2 f8 be 79 85 46 be-81 f2 fa be 74 85 46 be ....y.F.....t.F. 000007fe`f2f500a0 74 fd c5 be 73 85 46 be-74 fd c2 be c9 85 46 be t...s.F.t.....F. 000007fe`f2f500b0 ee 41 8d be 7f 85 46 be-e3 25 81 be 7c 85 46 be .A....F..%..|.F. 000007fe`f2f500c0 ee 41 88 be 6b 85 46 be-ee 41 89 be 78 85 46 be .A..k.F..A..x.F. 000007fe`f2f500d0 ee 41 8b be 64 85 46 be-7d 85 47 be ca 87 46 be .A..d.F.}.G...F. 000007fe`f2f500e0 81 f2 ff be 76 85 46 be-ee 41 9e be 70 87 46 be ....v.F..A..p.F. 000007fe`f2f500f0 ee 41 8c be 7c 85 46 be-ee 41 8f be 7c 85 46 be .A..|.F..A..|.F. 0:011> 000007fe`f2f50100 ee 41 8a be 7c 85 46 be-52 69 63 68 7d 85 46 be .A..|.F.Rich}.F. 000007fe`f2f50110 00 00 00 00 00 00 00 00-50 45 00 00 64 86 06 00 ........PE..d... 000007fe`f2f50120 ce 30 55 51 00 00 00 00-00 00 00 00 f0 00 22 20 .0UQ.........." 000007fe`f2f50130 0b 02 0b 00 00 90 69 00-00 c2 2b 00 00 00 00 00 ......i...+..... 000007fe`f2f50140 40 51 13 00 00 10 00 00-00 00 f5 f2 fe 07 00 00 @Q.............. 000007fe`f2f50150 00 10 00 00 00 02 00 00-06 00 00 00 0a 00 00 00 ................ 000007fe`f2f50160 06 00 00 00 00 00 00 00-00 e0 95 00 00 04 00 00 ................ 000007fe`f2f50170 80 5f 96 00 02 00 60 01-00 00 10 00 00 00 00 00 ._....`.........

También salté hacia adelante en la memoria y miré el recurso de la Versión en la memoria y vi la cadena de la versión 18047.


Así que ahora tenemos un minidump con información conflictiva sobre qué versión de clr.dll estaba realmente en uso.

Qué lo causó

También descubrí que nuestro departamento de TI lanzó recientemente un puñado de actualizaciones de Windows, por lo que:

  • Mientras se ejecutaba una aplicación, se instaló una actualización del CLR.
  • El archivo en C: / Windows / Microsoft.NET / Framework64 / v4.0.30319 / se actualizó a la versión más reciente (4.0.30319.18052)
  • La aplicación se estrelló
  • Aparentemente, MiniDumpWriteDump usó la información del archivo en el disco al almacenar la lista de módulos en el archivo de volcado por caída (4.0.30319.18052)
  • WinDbg no pudo correlacionar la versión estampada en el volcado de memoria con lo que había en la memoria del proceso, ya que tenía información conflictiva.

Para verificar esto, modifiqué manualmente la entrada MINIDUMP_MODULE para clr.dll para cambiar la suma de comprobación, la marca de tiempo y la versión de 18052 a 18047. Después de volver a cargar el archivo .dmp pirateado en WinDbg y configurar el exepath a los dlls sos + clr adecuados, Pude ejecutar con éxito los comandos sos y obtener un seguimiento de pila válido.

Línea de fondo

Básicamente, terminamos con un archivo minidump que tiene información contradictoria sobre qué versión de clr.dll se carga en el proceso, lo que evita que SOS identifique el motor clr correcto. Este es probablemente un error en MiniDumpWriteDump, ya que guarda el archivo de volcado de caída. Pero solo debería suceder cuando la versión de respaldo del CLR se haya actualizado mientras su aplicación se estaba ejecutando.

Parece que hizo una instalación personalizada de windbg y no seleccionó todas las extensiones que necesita. El error de Win32 n2 es generalmente una señal de este problema.

Presiono esto regularmente cuando depuro con minidumps del sitio. No estoy seguro de cómo sucedió en tu caso. Por lo general, ocurre cuando la versión de CLR que se cargó cuando se realizó el volcado no está disponible en su máquina de depuración. En su caso, son la misma máquina, por lo que probablemente todo debería funcionar. Estoy seguro de que habrá otros que puedan explicar exactamente por qué no lo es.

Mientras tanto, esto es lo que hago con los volcados de mi sitio. Windbg está buscando "la versión correcta" de mscordacwks.dll. Así que le damos esa versión y le decimos dónde buscarla.

Primero, si falsifico todo esto, al eliminar mscordacwks.dll, windbg se apaga y lo carga desde el servidor de símbolos de microsoft, así que asegúrese de que sus símbolos estén configurados correctamente para descargar símbolos del servidor de símbolos de microsoft y vuelva a intentarlo .

Ahora, suponiendo que no funcionó, compruebe exactamente qué versión es la "versión correcta". Enumere la información del módulo con "lm v clr" y verifique la versión de CLR que está REALMENTE cargada. El mío es 4.0.30319.239. Ok - ahora encuentra esa versión de mscordacwks.dll. Supongamos que se puede encontrar en la instalación normal de .NET framework en su máquina (C: / Windows / Microsoft.NET / Framework64 / v4.0.30319). ¡Verifique las coincidencias de la versión exactamente (clic derecho, propiedades, etc.)! Tómelo y colóquelo en un lugar seguro (uso D: / Symbols / _Images). Siga las instrucciones que le dio windbg para cambiar el nombre del archivo. mscordacwks_ .dll sería mscordacwks_AMD64_AMD64_4.0.30319.239.dll.

Ahora configure la ruta de la imagen ejecutable (".exepath D: / Symbols / _Images") para que windbg sepa dónde lo ha puesto.

Ahora tiene "la versión correcta de mscordacwks", y le cambió el nombre para que Windbg sepa lo que está buscando y le dijo dónde lo puso.

Si ese STILL no funciona, intente ".cordll -ve -u -l" y también "! Sym ruidoso" para activar el registro detallado tanto de la carga del cordll como del servidor de símbolos, luego intente! CLRStack nuevamente. Tal vez la salida de esos dos comandos te dirá exactamente qué está intentando cargar y puedes averiguar por qué no lo hará ...