La aplicación se bloquea con un "Error interno en el tiempo de ejecución de .NET"

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

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

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

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

con código de salida 80131506

Esa es desagradable, ExecutionEngineException. A partir de .NET 4.0, esta excepción finaliza inmediatamente el programa. La causa genérica es la corrupción del estado del montón de basura recolectada. Lo que a su vez es causado invariablemente por código no administrado. La ubicación exacta en el código en la que se genera esta excepción no es útil, la corrupción generalmente ocurre mucho antes de que se detecte el daño.

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

Un error en la implementación simultánea de Garbage Collection en x64 .Net 4 puede causar esto, como se indica en la siguiente entrada de Microsoft KB:

ExecutionEngineException ocurre durante la recolección de basura

Primero debe hacer una exploración profunda del 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 de bloqueo. Entonces, ¡diviértete con WinDbg!

La documentación más reciente sobre el uso del <gcConcurrent/>elemento de configuración, para deshabilitar la recolección de basura simultánea o (en .NET 4 y posterior) en segundo plano, 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 crea que solo porque fue un "error interno" en el tiempo de ejecución de .NET no hay un error en su código como la causa raíz. Siempre siempre siempre culpa a tu propio código antes de culpar al de otra persona.

Es de esperar que tenga información de registro y de seguimiento de excepciones / pilas para indicarle dónde empezar a buscar, o que pueda repetir el estado del sistema antes del bloqueo.

Para aquellos que llegan aquí desde Google, finalmente me encontré con esta pregunta SO , y esta respuesta específica resolvió mi problema. Me comuniqué 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.

Después de años de luchar con este problema en varias 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 .

Previamente lo había estado "arreglando" forzando al recolector de basura a ejecutarse en modo servidor (gcServer enabled = "true" en app.config) como se describe en el artículo de Microsoft vinculado por Think Before Coding. En esencia, esto obliga a todos los subprocesos de la aplicación a hacer una pausa durante la recopilación, lo que elimina la posibilidad de que otros subprocesos accedan a la memoria y sean manipulados por el GC. Me alegra descubrir que mis años de búsqueda en vano de un "error" en mi código u otras bibliotecas no administradas de terceros fueron infructuosos porque el error se encontraba en el código de Microsoft, no en el mío.

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

Tenía exactamente el mismo error en el cuadro de WinXP con la última compilación de mi código .NET 4. Verificamos compilaciones anteriores, ¡ahora también fallan! Ok, entonces no soy yo :). Ninguna sugerencia aquí / arriba ayudó.

Informe mucho más reciente (2018-05-09) del mismo problema: Application Crash con código de salida 80131506 .

R : Recibimos un error similar, pero creemos que el nuestro fue causado por el optimizador de memoria Citrix.
La resolución fue forzar una regeneración de las bibliotecas centrales de .Net en los hosts donde se estaba produciendo el problema:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\ngen.exe update /force

La causa raíz aún se desconoce (la máquina no se está actualizando y tiene poco uso), ¡pero eso fue suficiente para mí !

En mi caso, esta excepción se produjo cuando se acabó el espacio en disco 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 - Mínimo de memoria virtual demasiado 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, es posible que se denieguen las solicitudes de memoria para algunas aplicaciones.

Y error anterior:

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

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

Resolví el problema usando un "montón personalizado" creado con HeapCreate y asignando allí los búferes usados ​​por esa función.

No estoy seguro de que pueda ayudar a todos, pero podría solucionar esto ejecutando

devenv.exe /ResetSettings 

...en el camino {Visual_Studio_root}\Common7\Ide

Tuve los siguientes errores en el registro de eventos y VS simplemente fallaba y 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 se debió a redireccionamientos de enlace duplicados en mi web.config. Más info aquí .

Supongo que fue debido a que NuGet modificó las redirecciones de enlace, pero, por ejemplo, se veía así:

  <dependentAssembly>
    <assemblyIdentity name="Lucene.Net" publicKeyToken="85089178b9ac3181"/>
    <bindingRedirect oldVersion="0.0.0.0-2.9.4.0" newVersion="3.0.3.0"/>
  </dependentAssembly>
  <dependentAssembly>
    <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed"/>
    <bindingRedirect oldVersion="0.0.0.0-11.0.0.0" newVersion="11.0.0.0"/>
  </dependentAssembly>
  <dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.0.0.0"/>
  </dependentAssembly>
  <dependentAssembly>
    <assemblyIdentity name="Lucene.Net" publicKeyToken="85089178b9ac3181"/>
    <bindingRedirect oldVersion="0.0.0.0-2.9.4.0" newVersion="3.0.3.0"/>
  </dependentAssembly>
  <dependentAssembly>
    <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed"/>
    <bindingRedirect oldVersion="0.0.0.0-11.0.0.0" newVersion="11.0.0.0"/>
  </dependentAssembly>
  <dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.0.0.0"/>
  </dependentAssembly>

Eliminar todos los duplicados resolvió el problema.

En mi caso, este error se produjo al iniciar sesión en la aplicación SAP Business One 9.1. En los eventos de Windows también pude encontrar otro evento de error además del informado 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 en Internet que también podría ser un error en .NET 4, intenté instalar .NET Framework 4.5.2 y resolví el problema.

Versión del marco: 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, dando el error anterior. Desinstalo Framework 4.5 y reinstalo esto resolvió mi problema.

Animar.

Esta podría ser una excepción que ocurre en el finalizador. Si está haciendo el patrón de ~ Class () {Dispose (false); } comprobar qué está eliminando como recurso no gestionado. Solo prueba ... captura allí y estarás bien.

Encontramos el problema porque teníamos esta misteriosa falla sin registros. Hicimos el patrón habitual recomendado de usar un "Dispose vacío (bool disposing)".

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

Resulta que en algún lugar no eliminamos el objeto correctamente, 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 de Kafka Rest para limpiar el cliente de Kafka. Parece que arrojó una excepción en algún momento y luego ocurrió este problema.

En mi caso, el problema estaba relacionado con " Hacer referencia a la biblioteca estándar .NET en proyectos clásicos de asp.net " y estos dos problemas

https://github.com/dotnet/standard/issues/873

https://github.com/App-vNext/Polly/issues/628

y rebajar a Polly v6 fue suficiente para solucionarlo

Nunca supe por qué me estaba pasando esto. Fue reproducible de manera consistente para una de mis aplicaciones, pero desapareció simplemente después de reiniciar.

Estoy ejecutando Windows 2004 Build 19582.1001 (Insider Preview) con .net-4.8 y tampoco me sorprendería que esto se deba a algo así como un error de memoria de hardware. Además, mi aplicación carga un código no administrado y lo inicializa, por lo que no puedo probar que el bloqueo no provenga de eso.

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

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

Supongo que, por alguna razón, el GC no inspecciona automáticamente la memoria con la suficiente frecuencia para detectar la gran cantidad de objetos desechables que utilizo.