L'applicazione si arresta in modo anomalo con "Errore interno nel runtime .NET"

Abbiamo un'applicazione scritta su .NET 4.0 che durante il fine settimana si è bloccata, inserendo il seguente messaggio nel registro eventi:

Applicazione: PnrRetrieverService.exe Framework Versione: v4.0.30319
Descrizione: il processo è stato terminato a causa di un errore interno nel .NET Runtime su IP 791F9AAA (79140000) con codice di uscita 80131506.

Questo è su una scatola di Windows Server 2003 R2 Standard Edition. Cercando su Google questo errore non è risultato nulla di pertinente. Ad esempio, questo non si verifica in VS Studio, ma in una scatola di produzione; quando il servizio è stato finalmente riavviato, non si sono verificati ulteriori problemi.

Come si fa a diagnosticare un bug in .NET Runtime?

con codice di uscita 80131506

Quello è brutto, ExecutionEngineException. A partire da .NET 4.0, questa eccezione termina immediatamente il programma. La causa generica è il danneggiamento dello stato dell'heap di Garbage Collection. Che a sua volta è invariabilmente causato da codice non gestito. La posizione esatta nel codice in cui viene generata questa eccezione non è utile, in genere il danneggiamento si è verificato molto prima che il danno venga rilevato.

Trovare la causa esatta di ciò sarà difficile. Rivedi qualsiasi codice non gestito che il tuo servizio potrebbe utilizzare. Sospetti problemi ambientali se non esiste un candidato ovvio, gli scanner di malware che si comportano male sono noti. Se si ripete molto male, allora sospetti problemi hardware come errori di soft RAM.

Un bug nell'implementazione simultanea di Garbage Collection su x64 .Net 4 può causare ciò come indicato nella seguente voce della KB di Microsoft:

ExecutionEngineException si verifica durante la Garbage Collection

Dovresti prima fare una profonda esplorazione di minidump per assicurarti che il problema si sia verificato durante una Garbage Collection.

La posizione del minidump si trova in genere in una voce di Segnalazione errori di Windows nel registro eventi dopo la voce di arresto anomalo. Allora divertiti con WinDbg!

La documentazione più recente sull'uso <gcConcurrent/>dell'elemento di configurazione, per disabilitare la garbage collection simultanea o (in .NET 4 e successive) in background, può essere trovata qui .

Ho riscontrato "errori interni" nel runtime .NET che si sono rivelati essere causati da bug nel mio codice; non pensare che solo perché si è trattato di un "errore interno" nel runtime .NET che non ci sia un bug nel codice come causa principale. Incolpa sempre sempre il tuo codice prima di incolpare quello di qualcun altro.

Si spera che tu abbia la registrazione e le informazioni sulla traccia delle eccezioni / stack per indicarti dove iniziare a cercare, o che tu possa ripetere lo stato del sistema prima del crash.

Per coloro che arrivano qui da Google, alla fine mi sono imbattuto in questa domanda SO e questa risposta specifica ha risolto il mio problema. Ho contattato Microsoft per l'hotfix tramite la live chat su support.microsoft.com e mi hanno inviato un collegamento all'hotfix tramite posta elettronica.

Dopo anni di lotta con questo problema in numerose applicazioni, sembra che Microsoft lo abbia finalmente accettato come un bug in .NET 4 CLR che causa ciò. http://support.microsoft.com/kb/2640103 .

In precedenza l'avevo "aggiustato" costringendo il garbage collector a funzionare in modalità server (gcServer enabled = "true" in app.config) come descritto nell'articolo Microsoft collegato da Think Before Coding. Questo in sostanza forza tutti i thread dell'applicazione a sospendere durante la raccolta, eliminando la possibilità che altri thread accedano alla memoria manipolata dal GC. Sono felice di scoprire che i miei anni di inutile ricerca di un "bug" nel mio codice o in altre librerie non gestite di terze parti sono stati inutili solo perché il bug risiedeva nel codice di Microsoft, non nel mio.

Potrebbe essere un bug con GC simultaneo http://support.microsoft.com/kb/2679415

Ho avuto lo stesso errore esatto sulla scatola WinXP con l'ultima build del mio codice .NET 4. Abbiamo controllato le build precedenti - ora si bloccano anche loro! Ok, quindi non sono io :). Nessun suggerimento qui / sopra ha aiutato.

Rapporto molto più recente (2018-05-09) dello stesso problema: crash dell'applicazione con codice di uscita 80131506 .

A : Abbiamo ricevuto un errore simile, ma riteniamo che il nostro sia stato causato dall'ottimizzatore di memoria Citrix.
La risoluzione era quella di forzare una rigenerazione delle librerie core .Net sugli host in cui si verificava il problema:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\ngen.exe update /force

La causa principale è ancora sconosciuta (la macchina non viene aggiornata e ha poco uso), ma per me è stato così !

Nel mio caso questa eccezione si è verificata quando lo spazio su disco era esaurito e .NET non può allocare memoria nella memoria virtuale di Windows.

Nel registro eventi ho visto questo errore:

Popup applicazione: Windows - Memoria virtuale minima troppo bassa: il sistema ha poca memoria virtuale. Windows sta aumentando la dimensione del file di paging della memoria virtuale. Durante questo processo, le richieste di memoria per alcune applicazioni potrebbero essere negate.

E errore precedente:

Il disco C: è alla capacità o quasi. Potrebbe essere necessario eliminare alcuni file.

Nel mio caso il problema era una libreria C ++ / CLI in cui c'era una chiamata a NtQuerySystemInformation ; per qualche motivo a volte (e in circostanze misteriose ), quando veniva chiamato l'heap CLR veniva danneggiato e l'applicazione si bloccava.

Ho risolto il problema utilizzando un "heap personalizzato" creato con HeapCreate e allocando lì i buffer utilizzati da quella funzione.

Non sono sicuro che possa aiutare tutti, ma potrei aggirare questo problema correndo

devenv.exe /ResetSettings 

... nel percorso {Visual_Studio_root}\Common7\Ide

Ho avuto i seguenti errori nel registro eventi e VS si bloccava e si riavviava sempre:

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: 

Nel mio caso il problema era dovuto a reindirizzamenti di binding duplicati nel mio web.config. Maggiori info qui .

Presumo che fosse a causa di NuGet che modifica i reindirizzamenti di associazione, ma ad esempio aveva questo aspetto:

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

La rimozione di tutti i duplicati ha risolto il problema.

Nel mio caso questo errore si è verificato durante l'accesso all'applicazione SAP Business One 9.1. Negli eventi di Windows potrei trovare anche un altro evento di errore oltre a quello segnalato dall'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 macchina esegue Windows 8.1, con .NET Framework 4.0 installato e senza la versione 4.5. Poiché sembrava da Internet che potesse trattarsi anche di un bug in .NET 4, ho provato a installare .NET Framework 4.5.2 e ho risolto il problema.

Versione framework: v4.0.30319 Descrizione: il processo è stato terminato a causa di un'eccezione non gestita. Informazioni sull'eccezione: System.Reflection.TargetInvocationException

Ho riscontrato questo errore, l'applicazione funzionava correttamente su alcuni PC e su alcuni PC che davano l'errore precedente. Ho disinstallato il Framework 4.5 e reinstallato questo ha risolto il mio problema.

Cheer.

Questa potrebbe essere un'eccezione che si verifica nel finalizzatore. Se stai eseguendo il Pattern di ~ Class () {Dispose (false); } controlla cosa stai eliminando come risorsa non gestita. Metti una prova..catch lì e dovresti stare bene.

Abbiamo riscontrato il problema perché si è verificato questo misterioso errore senza log. Abbiamo seguito il consueto schema consigliato di utilizzare un "void Dispose (bool disposing)".

Guardando le risposte a questa domanda sul finalizzatore, abbiamo trovato un possibile luogo in cui lo smaltimento delle risorse non gestite potrebbe generare un'eccezione.

Si scopre che da qualche parte non abbiamo smaltito correttamente l'oggetto, quindi il finalizzatore ha rilevato la distribuzione di risorse non gestite, quindi si è verificata un'eccezione.

In questo caso si utilizzava l'API Kafka Rest per ripulire il client da Kafka. Sembra che a un certo punto abbia generato un'eccezione, quindi si è verificato questo problema.

Nel mio caso il problema era relativo a " Riferimento alla libreria standard .NET nei progetti asp.net classici " e questi due problemi

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

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

e il downgrade a Polly v6 è stato sufficiente per risolverlo

Non ho mai capito perché questo stesse accadendo per me. Era costantemente riproducibile per una delle mie applicazioni, ma è andato via dopo il semplice riavvio.

Sto eseguendo Windows 2004 Build 19582.1001 (Insider Preview) con .net-4.8 e non sarei sorpreso se ciò fosse dovuto a qualcosa come un errore di memoria hardware. Inoltre, la mia applicazione carica del codice non gestito e lo inizializza, quindi non posso provare che il crash non sia derivato da quello.

Ogni 5-10 minuti il ​​mio pool di applicazioni continuava a bloccarsi con questo codice di uscita. Non voglio rovinare la tua fiducia nel Garbage Collector, ma la seguente soluzione ha funzionato per me.

Ho aggiunto un lavoro che chiama GC.GetTotalMemory(true)ogni minuto.

Suppongo che, per qualche motivo, il GC non controlli automaticamente la memoria abbastanza spesso per l'elevato numero di oggetti usa e getta che uso.