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

112

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?

ALEXintlsos
fuente
1
Si esta es la primera vez que se produce este error, buscaría cualquier cambio en los últimos días a una semana.
Tony Abrams

Respuestas:

121

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.

Hans Passant
fuente
3
Tuve problemas con SQL CE 3.5 corrompiendo el montón, causando excepciones en los errores de tiempo de ejecución de ntdll.dll y .NET.
Phil
4
Se enumeran en el archivo de encabezado del SDK CorError.h
Hans Passant
2
¿Cómo supo que estaban incluidos en CorError.h?
Yeonho
6
Utilice esta herramienta Err.exe microsoft.com/en-au/download/details.aspx?id=985 para averiguar qué significan los códigos de error hexadecimales como 80131506 y qué archivo de encabezado los contiene.
Jeremy Thompson
2
@HansPassant Creo que la pregunta que se pretendía era 'de todos los archivos que existen en el mundo, ¿cómo sabías que CorError.h era un archivo que valía la pena mirar'?
bacar
41

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í .

pensar antes de codificar
fuente
gracias por este comentario - ¡esta fue la solución para un problema que he tenido durante mucho tiempo!
lenniep
1
Eres un salvavidas, este era el problema para nosotros. Aparte, también puede abrir el archivo de minivolcado en Visual Studio, configurar las rutas de los símbolos si es necesario y luego depurar. Esto nos dijo que el error ocurre en clr.dll! WKS :: gc_heap :: mark_object_simple (). Estoy seguro de que WinDbg es muy poderoso, pero el uso de VS puede decirle lo suficiente si solo está verificando la fuente del error.
Tim
La aplicación se bloqueó pero no encontré ningún mini volcado en la carpeta C: \ Temp \ CrashDump. Hay otros vertederos de accidentes allí, y podemos encontrar los vertederos de los accidentes de hace días. ¿Sabes por qué no hay vertederos de emergencia? El mensaje de error y el código de salida son exactamente iguales.
Jeffrey Zhao
Esto es exactamente lo que estaba buscando ... el evento de caída de la aplicación contenía un puntero de instrucción, que era inútil para mí sin un volcado. Nunca pensé en buscar eventos posteriores. ¡Gracias!
laindir
1
Para otros en la misma situación, puede ser útil configurar el Informe de errores de Windows para hacer un volcado de pila completo en caso de bloqueo: msdn.microsoft.com/en-us/library/windows/desktop/…
laindir
9

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.

jason
fuente
5

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.

parque896
fuente
1
¿Cuál es el número de versión de los archivos HotFix que recibió? El número de versión que aparece en KB es 4.0.30319.526 pero ya tengo 4.0.30319.18052. ¿Sigue siendo necesario el HotFix o se ha incorporado a una actualización de Windows?
Automatizar el
1
Cuando ejecuto el archivo HotFix exe aparece "KB2640103 no se aplica o está bloqueado por otra condición en su computadora".
Automatizar el
3

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í !

Astrogador
fuente
2

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.

Arthur Smirnov
fuente
1

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.

SiMoStro
fuente
1

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: 
Ritesh Varyani
fuente
Esto funcionó para mí también. Contexto: había convertido una solución de tamaño mediano (~ 25 proyectos) al SDK de .NET Core, con un proyecto de aplicación web casi vacío que reemplazó al antiguo WAP antes de la conversión. Aparentemente, algunas configuraciones persistentes chocaban con las expectativas de IISExpress en el nuevo proyecto.
Tomas Aschan
1

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.

Mark Gibbons
fuente
0

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.

azulado
fuente
0

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.

usuario4815065
fuente
0

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.

Nelson J Pérez
fuente
0

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.

binki
fuente
-1

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.

Éric Bergeron
fuente