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


112

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?


1
Se è la prima volta che si verifica questo errore, esaminerei tutto ciò che è cambiato negli ultimi giorni fino a una settimana.
Tony Abrams

Risposte:


121

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.


3
Ho avuto problemi con SQL CE 3.5 che danneggiava l'heap, causando eccezioni in ntdll.dll ed errori di runtime .NET.
Phil

4
Sono elencati nel file di intestazione SDK CorError.h
Hans Passant

2
Come facevi a sapere che erano elencati in CorError.h ??
Yeonho

6
Usa questo strumento Err.exe microsoft.com/en-au/download/details.aspx?id=985 per capire cosa significano i codici di errore esadecimali come 80131506 e quale file di intestazione li contiene.
Jeremy Thompson

2
@ HansPassant Penso che la domanda fosse "tra tutti i file che esistono nel mondo, come facevi a sapere che CorError.h era un file utile da guardare"?
bacar

41

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 .


grazie per questo commento - questa è stata la soluzione per un problema che ho avuto per molto tempo!
Lenniep

1
Sei un salvavita, questo era il problema per noi. Per inciso, puoi anche aprire il file minidump in Visual Studio, impostare i percorsi dei simboli se necessario e quindi eseguire il debug. Questo ci ha detto che l'errore si verifica in clr.dll! WKS :: gc_heap :: mark_object_simple (). Sono sicuro che WinDbg è molto potente, ma l'uso di VS può dirti abbastanza se stai solo verificando la fonte dell'errore.
Tim

L'applicazione si è bloccata ma non ho trovato alcun mini dump nella cartella C: \ Temp \ CrashDump. Ci sono altri dump di crash lì e possiamo trovare i dump dei crash di giorni fa. Sai perché non ci sono discariche di arresto anomalo? Il messaggio di errore e il codice di uscita sono esattamente gli stessi.
Jeffrey Zhao

Questo è esattamente quello che stavo cercando ... l'evento crash dell'app conteneva un puntatore di istruzioni, che era inutile per me senza un dump. Non ho mai pensato di cercare eventi successivi. Grazie!
laindir

1
Per gli altri nella stessa situazione, può essere utile per configurare Segnalazione errori di Windows per fare un dump completo heap on incidente: msdn.microsoft.com/en-us/library/windows/desktop/...
laindir

9

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.



5

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.


1
Qual è il numero di versione dei file HotFix ricevuti? Il numero di versione elencato nella KB è 4.0.30319.526 ma ho già 4.0.30319.18052. L'hotfix è ancora necessario o è stato inserito in un aggiornamento di Windows?
Automatizza il

1
Quando eseguo l'exe HotFix, viene visualizzato il messaggio "KB2640103 non applicabile o bloccato da un'altra condizione sul computer".
Automatizza il


3

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


2

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.


1

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.


1

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: 

Questo ha funzionato anche per me. Contesto: avevo convertito una soluzione di medie dimensioni (~ 25 progetti) in .NET Core SDK, con un progetto di applicazione Web quasi vuoto che ha sostituito il vecchio WAP prima della conversione. Apparentemente alcune impostazioni persistenti si sono scontrate con le aspettative di IISExpress nel nuovo progetto.
Tomas Aschan

1

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.


0

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.


0

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.


0

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.



0

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.


-1

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.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.