c# - son - Depuración de archivos de volcado en Visual Studio

para que sirve el volcado de memoria

Question

Estoy usando Visual Studio 2010 Professional Edition y Windows Vista.

En primer lugar, tengo este código. Como puede ver, ¡bloqueará el programa!

using System;

namespace Crash
{
    class Program
    {
        static void Main(string[] args)
        {
            string a = null;

            if (a.Length == 12)
            {
                // ^^ Crash
            }
        }
    }
}

El programa se bloqueará en la declaración if. Ahora, quiero descubrir que se bloqueó en esa declaración if.

Si "Comience sin depurar" desde Visual Studio, Crash.exe se bloquea. Utiliza 1,356kb de memoria. Obtengo la opción Vista de Cerrar Programa / Depurar. Si elijo Debug, puedo abrir una nueva instancia de Visual Studio y me señala una NullReferenceException en la sentencia if. Esto es bueno.

Ahora déjame suponer que se bloquea en otra computadora, y les pido que me den un archivo de volcado a través del Administrador de tareas. Es 54,567kb. ¡Por qué tan grande! ¡Es vasto! De todos modos, estoy menos interesado en eso (un poco)

Si abro ese vertedero con Windbg, mi ojo no entrenado me sirve muy poco:

Microsoft (R) Windows Debugger Version 6.12.0002.633 X86
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:/Users/Richard/Desktop/Crash.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 Server 2008/Windows Vista Version 6002 (Service Pack 2) MP (4 procs) Free x86 compatible
Product: WinNt, suite: SingleUserTS Personal
Machine Name:
Debug session time: Sat Jan 15 11:07:36.000 2011 (UTC + 0:00)
System Uptime: 0 days 4:24:57.783
Process Uptime: 0 days 0:00:05.000
........................
eax=002afd40 ebx=77afa6b4 ecx=002afd48 edx=00000001 esi=001cdaa4 edi=00000000
eip=77bf5e74 esp=001cda5c ebp=001cdacc iopl=0         nv up ei ng nz ac pe cy
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000297
ntdll!KiFastSystemCallRet:
77bf5e74 c3              ret

Sin embargo, esto me interesa menos. Por lo que puedo decir, necesito escribir comandos para obtener resultados útiles, y Visual Studio es mejor.

Entonces lo abro con Visual Studio. Puedo elegir "Depurar solo con nativos", pero obtengo muchas cosas que significan algo para personas inteligentes como tú, ¡y no soy inteligente! Tengo estas dos pantallas:

Entonces, mi pregunta:

¿Cómo le muestro Visual Studio a mi código fuente?

Además, ¿hay alguna manera de obtener un archivo de volcado más pequeño? Parece ridículamente grande, incluso después de la compresión. No entiendo por qué no podría haber uno que sea solo un poquito más grande que la huella del programa, y ​​aún así tener una buena depuración, con el código fuente.

Answer 1

Debería suministrar el archivo relacionado pdb (base de datos de programa) al depurador para que pueda cargar los símbolos. También para obtener una mejor vista, use el servidor de símbolo público de Microsoft. Este artículo contiene información sobre él.

Answer 2

La característica anunciada de que Visual Studio 2010 le permite depurar archivos de volcado y paso a través del código fuente administrado viene con un gotcha: funciona solo para ensamblajes .NET 4.0 . Estos son los pasos:

1. Cree un archivo de volcado de bloqueo en otra computadora usando el Administrador de tareas
2. Abra la solución en VS2010
3. Abra el archivo .DMP (Archivo-> Abrir ...)
4. Haga clic en Debug With Mixed (Esto será visible solo para .NET 4.0)
5. Se abrirá el código fuente y podrá inspeccionar la causa exacta y la ubicación de la excepción

En lo que respecta a la depuración con solo nativo, Visual Studio no es más útil que WinDbg.

Answer 3

Las herramientas que está utilizando aquí nunca fueron diseñadas para solucionar problemas de bloqueo de programas administrados. Minidumps y Windbg es lo que utilizas para descubrir qué está mal con el código escrito en C o C ++. Herramientas bastante importantes, estos son lenguajes cuyos tiempos de ejecución no tienen soporte para el tipo de regalos que puede obtener de un programa administrado bloqueado. Como una excepción con un seguimiento de pila.

La razón por la que los tamaños de minivolcado son tan diferentes es por el mini en minivolcado. Por diseño, estaba destinado a capturar una pequeña instantánea del proceso. El argumento relevante es DumpType en la función MiniDumpWriteDump . Hay un código realmente inteligente en esta función que puede determinar qué partes del estado del proceso no necesitan ser registradas porque no es probable que lo use en la sesión del depurador. Que puede anular proporcionando indicadores de tipo de vuelco adicionales. El minivolcado que genera Explorer tiene todas esas banderas activadas, obtienes todo el kit y el caboodle.

Lo cual es bastante importante para un programa administrado. La heurística utilizada por este creador de minivolcados es solo apropiada para código no administrado. La depuración de un volcado de programa administrado solo funciona bien cuando se incluye todo el montón recogido de basura en el volcado. Sí, será un vertedero grande, el mini ya no se aplica.

Su próximo problema es que obtiene el alma de la vista de la máquina a partir de los datos del minivolcado. Sus capturas de pantalla muestran el código de la máquina. Si se encuentra dentro de Windows en esos disparos, observe cómo ntdll.dll se encuentra en la parte superior de la pila. Las entradas mscorwks.dll son el CLR. Más abajo, fuera de la vista, deberías ver los cuadros de pila de tu propio código. Sin embargo, verá el código máquina generado por el compilador JIT. No es tu código C #.

Hay un complemento de Windbg llamado sos.dll que amplía el conjunto de comandos de Windbg para poder inspeccionar los datos administrados. Simplemente google "sos.dll" para obtener buenos éxitos. Sin embargo, esto todavía está muy lejos del tipo de experiencia de depuración que obtendrá del depurador de Visual Studio. Que es íntimamente consciente del código administrado, muy diferente de Windbg o el depurador VS que puede cargar minivolcados. Sos fue diseñado para solucionar problemas de CLR.

No hubo mejoras dramáticas en VS2010 aparte de la página de información de minivolcado que ahora ve. Lo que realmente no hace mucho en absoluto. Sospecho que el equipo de depuradores tiene esto en su lista de tareas pendientes, sin duda hay algunos problemas fundamentales que superar. Particularmente en el formato de minivolcado y código de creación. Use connect.microsoft.com para proporcionar comentarios, le prestan atención y permiten que los votos afecten a su lista de prioridades.