c# - visual - He encontrado un error en el JIT/CLR. Ahora, ¿cómo lo depuro o lo reproduzco?
system.windows.forms jitdebugging= true/ (7)
Me gustaría averiguar qué lo causa, o al menos escribir una reproducción más pequeña para enviar a Microsoft, pero no tengo idea de por dónde empezar.
"Reproducción más pequeña" definitivamente suena como una gran idea aquí ... incluso si "más pequeña" no significa "más rápido de reproducir".
Antes de comenzar, intente reproducir el error en otra máquina. Si no puede reproducirlo en otra máquina, eso sugiere un conjunto de pruebas completamente diferente: hardware, instalación, etc.
Además, comprueba que estás en la última versión de todo. Sería molesto pasar días depurando esto (lo cual es probable, me temo) y luego terminar con una respuesta de "Sí, lo sabemos, fue un error en .NET 4 que se corrigió en .NET 4.5 " por ejemplo. Si puedes reproducirlo en una variedad de versiones de framework, sería aún mejor :)
A continuación, recorte todo lo que pueda en el programa:
- ¿Tiene alguna interfaz de usuario? Si es posible, quita eso.
- ¿Utiliza una base de datos? Vea si puede eliminar todo el acceso a la base de datos: definitivamente cualquier salida que no se use más adelante, e idealmente también ingrese. Si puede codificar la entrada dentro de la aplicación, sería ideal, pero si no, los archivos son más simples para las reproducciones que para el acceso a la base de datos.
- ¿Es sensible a los datos? Nuevamente, sin saber mucho sobre la aplicación, es difícil saber si esto es útil, pero suponiendo que esté procesando una gran cantidad de datos, ¿puede utilizar una búsqueda binaria para encontrar una cantidad relativamente pequeña de datos que cause el problema?
- ¿ Tiene que ser multihilo? Si puede eliminar todos los subprocesos, obviamente eso puede llevar mucho más tiempo para reproducir el problema, pero ¿sigue ocurriendo?
- Intente eliminar bits de la lógica de negocios: si su aplicación tiene los componentes adecuados, probablemente pueda falsificar componentes significativos completos creando primero una implementación de código auxiliar y luego eliminando las llamadas.
Todo esto reducirá gradualmente el tamaño de la aplicación hasta que sea más manejable. En cada paso, deberá ejecutar la aplicación nuevamente hasta que se bloquee o esté convencido de que no se bloqueará. Si tiene muchas máquinas disponibles, eso debería ayudar ...
Tengo una aplicación C # de varios subprocesos, que es computacionalmente costosa y parece fallar constantemente después de 30-90 minutos de ejecución. El error que da es.
El tiempo de ejecución ha encontrado un error fatal. La dirección del error estaba en 0xec37ebae, en el hilo 0xbcc. El código de error es 0xc0000005. Este error puede ser un error en el CLR o en las partes inseguras o no verificables del código de usuario. Las fuentes comunes de este error incluyen errores de cálculo de referencias del usuario para interoperabilidad COM o PInvoke, que pueden dañar la pila.
(0xc0000005 es el código de error para la infracción de acceso )
Mi aplicación no invoca ningún código nativo, ni utiliza bloques inseguros, ni siquiera tipos no compatibles con CLS como uint . De hecho, la línea de código que el depurador dice que causó el bloqueo es
overallLength += distanceTravelled;
Donde ambos valores son de tipo double
Dado todo esto, creo que el bloqueo debe ser debido a un error en el compilador o CLR o JIT. Me gustaría averiguar qué lo causa, o al menos escribir una reproducción más pequeña para enviar a Microsoft, pero no tengo idea de por dónde empezar. Nunca he tenido que ver el binario CIL, la salida JIT compilada o el seguimiento de pila nativo (no hay un seguimiento de pila administrado en el momento del bloqueo) , así que no estoy seguro de cómo hacerlo. Ni siquiera puedo averiguar cómo ver el estado de todas las variables en el momento de la falla (VS lamentablemente no me dirá cómo lo hace después de las excepciones gestionadas, y enviarlas a la consola / archivo ralentizaría el proceso). aplicación 1000 veces, lo que obviamente no es una opción) .
Entonces, ¿cómo hago para depurar esto?
[Editar] Compilado bajo VS 2010 SP1, ejecutando la última versión de .Net 4.0 Client Profile. Aparentemente es ".Net 4.0C / .Net 4.0E, .Net CLR 1.1.4322"
Mi aplicación no invoca ningún código nativo, ni utiliza bloques inseguros, ni siquiera tipos no compatibles con CLS como uint
Puede pensar esto, pero el subprocesamiento, la sincronización a través del semáforo, excluyen todos los manejadores, todos son nativos. .net es una capa sobre el sistema operativo, .net en sí no admite código CLR puro para aplicaciones de subprocesamiento múltiple, esto se debe a que el sistema operativo ya lo hace.
Lo más probable es que este sea un error de sincronización de hilo. Probablemente, varios subprocesos intentan acceder a recursos compartidos como archivos, etc. que están fuera del límite de clr.
Puede pensar que no está accediendo a com, etc., pero cuando llama a cierta API como obtener la ruta de la carpeta del escritorio, etc. se le llama a través de la API de shell com.
Tienes las siguientes dos opciones,
- Publique su código para que podamos revisar el cuello de botella.
- Rediseñe su aplicación utilizando el marco de subprocesos paralelos .net, que incluye una variedad de algoritmos que requieren operaciones intensivas de CPU.
Los programas más probables fallan después de cierto período de tiempo a medida que las colecciones crecen y las operaciones no se ejecutan antes de que otro hilo interfiera. Por ejemplo, problema del consumidor productor, no notará ningún problema hasta que el productor se vuelva más lento o no termine su operación antes de que el consumidor entre en acción.
El error en clr es raro, porque clr es muy estable. Pero un código mal escrito puede hacer que el error aparezca como error en clr. Clr no puede y nunca detectará si el error está en su código o en clr mismo.
Descargar Debug Diagnostic Tool v1.2
- Ejecute el programa
- Añadir regla "Crash"
- Seleccione "Proceso específico"
- en la página Configuración avanzada establezca su excepción si sabe en qué excepción falla o si simplemente deja esta página como está
- Establecer ubicación de volcado de usuario
Ahora espere a que el proceso se bloquee, el archivo de registro es creado por DebugDiag. Ahora active la pestaña Advanced Analysis , seleccione Crash / Hang Analyzers en la lista superior y descargue el archivo en la lista inferior y presione Start Analysis . Esto generará un informe html para usted. Espera que hayas encontrado información útil en ese informe. Si tiene problemas con el análisis, cargue el informe html en algún lugar y coloque la URL aquí para que podamos concentrarnos en él.
Le sugeriré que abra un caso de soporte a través de http://support.microsoft.com inmediatamente, ya que los tipos de soporte pueden mostrarle cómo recopilar la información necesaria.
En términos generales, como @ paulsm4 y @psulek dijeron, puede utilizar WinDbg o Debug Diag para capturar volcados de fallos del proceso, y dentro de él, toda la información necesaria está incorporada. Sin embargo, si esta es la primera vez que usa esas herramientas, es posible que esté desconcertado. El equipo de soporte de Microsoft puede proporcionarle una guía paso a paso sobre ellos, o incluso pueden configurar una sesión de Live Meeting con usted para capturar los datos, ya que el programa falla con tanta frecuencia.
Una vez que esté familiarizado con las herramientas, en el futuro podrá realizar una solución de problemas similar más fácilmente,
Por cierto, es demasiado pronto para decir "He encontrado un error". Si bien obviamente no puede encontrar en su programa una dependencia del código nativo, es posible que todavía tenga una dependencia del código nativo. No deberíamos sacar una conclusión antes de depurar más en el problema.
tl; dr Asegúrate de que estás compilando en .Net 4.5
Esto suena sospechosamente como el mismo error encontrado here . Desde la página de MSDN :
Este error se puede encontrar cuando el recolector de basura está liberando y compactando la memoria. El error puede ocurrir cuando la recolección de basura simultánea está habilitada y se produce una combinación determinada de recolección de basura en primer plano y recolección de basura en segundo plano. Cuando ocurra esta situación, verá la misma pila de llamadas una y otra vez. En el montón verá un objeto libre y antes de que finalice verá otro objeto libre que corrompe el montón.
La solución es compilar a .Net 4.5. Si por alguna razón no puede hacer esto, también puede deshabilitar la recolección de basura simultánea deshabilitando gcConcurrent en el archivo app.config :
<configuration>
<runtime>
<gcConcurrent enabled="false"/>
</runtime>
</configuration>
O simplemente compilar a x86 .
¿Ejecutó una prueba de memoria para su máquina? La única vez que tuve síntomas comparables, uno de mis reguladores resultó ser defectuoso (en Win7 se incluye un muy buen probador de memoria; http://www.tomstricks.com/how-to-test-your-ram-or-memory-with-windows-memory-diagnostic-tool-in-windows-7/ )
También podría ser un problema de calentamiento / regulación si su CPU se calienta demasiado después de este período de tiempo. Aunque eso pasaría antes.
Debe haber un archivo de volcado que pueda analizar. Si nunca lo hizo, busque a alguien que lo haya hecho o envíelo a Microsoft.