La aplicación se bloquea con “Error interno en .NET Runtime”

Tenemos una aplicación escrita contra .NET 4.0 que durante el fin de semana se colgó, colocando el siguiente mensaje en el registro de eventos:

Aplicación: PnrRetrieverService.exe Framework Version: v4.0.30319
Descripción: El proceso finalizó debido a un error interno en .NET Runtime en IP 791F9AAA (79140000) con el código de salida 80131506.

Esto está en un cuadro de Windows Server 2003 R2 Standard Edition. Buscar en Google este error no ha revelado nada pertinente. Por ejemplo, esto no ocurre en VS Studio, sino en un cuadro de producción; cuando el servicio finalmente se reinició, no experimentó más problemas.

¿Cómo se puede diagnosticar un error en .NET Runtime?

con el código de salida 80131506

Eso es desagradable, ExecutionEngineException. Comenzando con .NET 4.0, esta excepción termina inmediatamente el progtwig. La causa genérica es la corrupción del estado del montón recolectado de basura. Lo cual a su vez es causado invariablemente por un código no administrado. La ubicación exacta en el código en el que se genera esta excepción no es útil, la corrupción normalmente se produce mucho antes de que se detecte el daño.

Encontrar la causa exacta de esto va a ser difícil. Revise cualquier código no administrado que su servicio pueda estar usando. Sospeche los problemas ambientales si no hay un candidato obvio, los escáneres de malware que se portan mal son notorios. Si se repite muy mal, entonces sospeche problemas de hardware como errores de RAM blandos.

Un error en la implementación concurrente de Garbage Collection en x64 .Net 4 puede causar esto como se indica en la siguiente entrada de microsoft KB:

ExecutionEngineException se produce durante la recolección de basura

Primero debe hacer una exploración profunda de minivolcado para asegurarse de que el problema ocurrió durante una recolección de basura.

La ubicación del minivolcado generalmente se puede encontrar en una entrada de Informe de errores de Windows en el registro de eventos que sigue a la entrada del locking. Entonces, ¡diviértete con WinDbg!

La última documentación sobre el uso del elemento de configuración , para deshabilitar la recolección de basura de fondo concurrente o (en .NET 4 y posterior), se puede encontrar aquí .

He experimentado “errores internos” en el tiempo de ejecución de .NET que resultaron ser causados ​​por errores en mi código; no piense que solo porque fue un “error interno” en el tiempo de ejecución de .NET que no haya un error en su código como causa raíz. Siempre siempre culpe siempre a su propio código antes de culpar a otro.

Es de esperar que tenga la información de registro y de seguimiento de la stack / excepción para indicarle dónde empezar a buscar, o que puede repetir el estado del sistema antes del locking.

Para quienes llegan aquí desde Google, eventualmente me he encontrado con esta pregunta , y esta respuesta específica resolvió mi problema. Me puse en contacto con Microsoft para obtener la revisión a través del chat en vivo en support.microsoft.com y me enviaron un enlace a la revisión por correo electrónico.

Podría ser un error con GC concurrente http://support.microsoft.com/kb/2679415

Después de años de luchar con este tema en una serie de aplicaciones, parece que Microsoft finalmente lo ha aceptado como un error en .NET 4 CLR que hace que esto ocurra. http://support.microsoft.com/kb/2640103 .

Anteriormente lo había estado “arreglando” al forzar al recolector de elementos no utilizados a ejecutarse en modo de servidor (gcServer enabled = “true” en app.config) como se describe en el artículo de Microsoft vinculado por Think Before Coding. En esencia, esto fuerza a todos los hilos de la aplicación a pausar durante la recolección, eliminando la posibilidad de que otros hilos accedan a la memoria manipulada por el GC. Me complace descubrir que mis años de búsqueda en vano de un “error” en mi código o en otras bibliotecas no administradas de terceros no fueron más que infructuosas porque el error radicaba en el código de Microsoft, no en el mío.

En mi caso, esta excepción se produjo cuando el espacio en disco había terminado y .NET no puede asignar memoria en la memoria virtual de Windows.

En el registro de eventos, vi este error:

Ventana emergente de la aplicación: Windows – Memoria virtual Mínimo muy bajo: su sistema tiene poca memoria virtual. Windows está aumentando el tamaño de su archivo de paginación de memoria virtual. Durante este proceso, las solicitudes de memoria para algunas aplicaciones pueden ser denegadas.

Y error anterior:

El disco C: está a capacidad o cerca de ella. Quizás tengas que borrar algunos archivos.

Versión de Framework: v4.0.30319 Descripción: El proceso finalizó debido a una excepción no controlada. Información de excepción: System.Reflection.TargetInvocationException

Me he enfrentado a este error, la aplicación funcionaba bien en algunas PC y en algunas PC con el error anterior. Desinstalé el Framework 4.5 y reinstalé esto resolvió mi problema.

Animar.

No estoy seguro de que pueda ayudar a todos, pero podría evitar esto al ejecutar

 devenv.exe /ResetSettings 

… en el camino {Visual_Studio_root}\Common7\Ide

Tenía los siguientes errores en el registro de eventos y VS simplemente se bloqueaba y se reiniciaba todo el tiempo:

 Faulting application name: devenv.exe, version: 14.0.25123.0, time stamp: 0x56f22f32 Faulting module name: clr.dll, version: 4.7.2115.0, time stamp: 0x59af88f2 Exception code: 0xc0000005 Fault offset: 0x0015f90e Faulting process id: 0x3a7c Faulting application start time: 0x01d353463eaf0c36 Faulting application path: C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.exe Faulting module path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll Report Id: a232f984-6e80-4f61-9003-e18a035c8f93 Faulting package full name: Faulting package-relative application ID: 

En mi caso, el problema era una biblioteca C ++ / CLI en la que había una llamada a NtQuerySystemInformation ; por algún tipo de razón a veces (y en circunstancias misteriosas ), cuando se llamaba el montón de CLR se corrompió y la aplicación se bloqueó.

Resolví el problema utilizando un “montón personalizado” creado con HeapCreate y asignando los búferes utilizados por esa función.

En mi caso, este error ocurrió al iniciar sesión en la aplicación SAP Business One 9.1. En eventos de Windows, también pude encontrar otro evento de error además del reportado por el OP:

 Nome dell'applicazione che ha generato l'errore: SAP Business One.exe, versione: 9.10.160.0, timestamp: 0x551ad316 Nome del modulo che ha generato l'errore: clr.dll, versione: 4.0.30319.34014, timestamp: 0x52e0b784 Codice eccezione: 0xc0000005 Offset errore 0x00029f55 ID processo che ha generato l'errore: 0x1d7c Ora di avvio dell'applicazione che ha generato l'errore: 0x01d0e6f4fa626e78 Percorso dell'applicazione che ha generato l'errore: C:\Program Files (x86)\SAP\SAP Business One\SAP Business One.exe Percorso del modulo che ha generato l'errore: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll ID segnalazione: 3fd8e0e7-52e8-11e5-827f-74d435a9d02c Nome completo pacchetto che ha generato l'errore: ID applicazione relativo al pacchetto che ha generato l'errore: 

La máquina ejecuta Windows 8.1, con .NET Framework 4.0 instalado y sin la versión 4.5. Como parecía desde Internet que también podría ser un error en .NET 4, intenté instalar .NET Framework 4.5.2 y resolví el problema.

Esto podría ser una excepción que ocurre en el finalizador. Si está haciendo el Patrón de ~ Class () {Dispose (false); } comprobar qué está desechando como un recurso no administrado. Solo ponga a prueba … la captura allí y usted debería estar bien.

Encontramos el problema ya que teníamos esta misteriosa falla sin registros. Hicimos el patrón recomendado habitual de utilizar un “vacío Dispose (bool disposing)”.

Al ver las respuestas a esta pregunta sobre el finalizador, encontramos un posible lugar donde la Eliminación de los recursos no administrados podría arrojar una excepción.

Resulta que en algún lugar no desechamos el objeto adecuadamente, por lo que el finalizador se hizo cargo de la eliminación de los recursos no administrados, por lo que se produjo una excepción.

En este caso estaba usando la API Kafka Rest para limpiar al cliente de Kafka. Parece que lanzó una excepción en algún momento, luego ocurrió este problema.

Cada 5-10 minutos mi grupo de aplicaciones se bloqueaba con este código de salida. No quiero arruinar tu confianza en el recolector de basura, pero la siguiente solución funcionó para mí.

GC.GetTotalMemory(true) un trabajo que llama a GC.GetTotalMemory(true) cada minuto.

Supongo que, por algún motivo, el GC no inspecciona automáticamente la memoria con la suficiente frecuencia para la gran cantidad de objetos desechables que uso.