¿Qué posibilidades hay para el análisis post mortem en .NET (por ejemplo, después de un bloqueo de un programa)?

Question

Supongamos que hay un programa C #, que se usa como un servicio de Windows. Supongamos que el servicio se ha vuelto loco y está consumiendo CPU y memoria como un loco. Necesita reiniciarse muy pronto, porque es un sistema de producción. Por lo tanto, no tengo mucho tiempo para recopilar información sobre el tiempo de ejecución. Tal vez un vistazo rápido al administrador de tareas ... eso es todo.

Después de eso, todo lo que tengo son los archivos de registro log4net y el registro de eventos de Windows para el análisis post mortem.

Supongamos que he descubierto la razón del problema. Alguien más lo arregla y tal vez el programador agrega algunos registros adicionales, por lo que la próxima vez puedo encontrar un problema similar más rápido. Sin embargo: sigo dependiendo de la calidad de los archivos de registro y espero que la próxima vez un problema se revele de alguna manera en los registros.

¿Existen otras formas de hacer análisis post mortem? ¿Tal vez algo como volcados de subprocesos (como en Java), volcados de memoria u otra cosa que pueda ayudar en el análisis post mortem? ¿Quizás alguna herramienta de .NET framework incorporada pueda ayudar?

Estoy muy interesado en experiencias reales de proyectos y en cómo trataría de abordar esta cuestión de mantenimiento, que creo que es muy real para la mayoría de los programadores.

Answer 1

Como Marc dice que WinDbg + SoS te permitirá depurar muchos problemas, realmente no puedes resolverlos en Visual Studio. Hay algunos excelentes tutoriales este blog .

Para problemas de memoria, también puede consultar los contadores de rendimiento de .NET en Perfmon. Podrías ver dónde se encuentran los objetos (qué generación) y cuánto tiempo se dedica a la recolección de basura. Eso debería darte información útil. Si desea saber por qué no se recopilan objetos, WinDbg y SoS es el camino a seguir. Para guiarlo a través de una sesión simple, los pasos son:

1. Inspeccione el montón usando !dumpheap -stat, busque un gran número de instancias. Probablemente tengas una idea de lo que esperarías encontrar en el montón en cualquier momento dado, así que si algo parece fuera de lo común, investiga eso.

2. Elija una instancia aleatoria y haga un !gcroot en la dirección de la instancia. Eso le dirá por qué el objeto no se está recolectando.

3. Repetir

Los candidatos probables para mantener las cosas vivas más tiempo del que deberían son: eventos, estadísticas y la cola del finalizador, por nombrar algunos.

También puede consultar mi respuesta para esta pregunta para ver más cosas de WinDbg.

Answer 2

Puede hacer volcados de memoria con .NET y mirarlos con windbg / sos (y sosassist). No es simple, pero funciona. Pero bastante duro. Búsquedas en & Quot; + windbg + .NET & Quot; debería resultar interesante.

Aparte de eso, ¿contadores de recursos? ¿archivos de registro? Hay muchas cosas que puede ver que se pueden habilitar con bastante facilidad.

Answer 3

Desafortunadamente, he tenido que hacer una buena cantidad de esto: la mejor herramienta que he encontrado es cordbg que viene con el sdk (necesitará la versión correcta para su versión .net). http://msdn.microsoft.com/en-us/library/a6zb7c8d. aspx para más detalles.

Adjuntar al proceso en ejecución en cordbg (a < [pid] >), adjuntar a cada hilo en ejecución (t < [tid] >) luego volcar la pila para cada hilo (w).

Automatizar esta tarea con un pequeño script vb y luego volcarlo en un archivo le permitirá ejecutar esta herramienta varias veces, capturando la salida a un archivo. La comparación de todas las pilas de hilos le dará una muy buena idea de dónde está pasando su aplicación su tiempo.

Lo bueno de este enfoque, especialmente con la automatización de los volcados, es que puede obtener rápidamente toda la información y reiniciar el proceso en el menor tiempo posible.

Answer 4

Un gran recurso para el análisis post mortem con WinDbg y SOS es Tess Ferrandez ' serie de entradas de blog sobre el tema.

EDITAR: Enlace actualizado

Answer 5

Si el proceso aún está activo, puede ejecutar el Managed Stack Explorer en contra para obtener una instantánea rápida de lo que está haciendo. Puede ejecutar esto sin una instalación explícita.

Aparte de eso, un volcado completo + windbg + SOS le brinda la mayor cantidad de información, pero obtenerla no es trivial.