L'application se bloque avec une «erreur interne dans le Runtime .NET»

Nous avons une application écrite contre .NET 4.0 qui s'est écrasée au cours du week-end, mettant le message suivant dans le journal des événements:

Application: PnrRetrieverService.exe Framework Version: v4.0.30319
Description: Le processus a été interrompu en raison d'une erreur interne dans .NET Runtime à IP 791F9AAA (79140000) avec le code de sortie 80131506.

Ceci est sur une boîte de Windows Server 2003 R2 Standard Edition. Googler cette erreur n'a rien révélé de pertinent. Par exemple, cela ne se produit pas dans VS Studio, mais plutôt sur une boîte de production; lorsque le service a finalement été redémarré, il n'a rencontré aucun autre problème.

Comment diagnostiquer un bogue dans le Runtime .NET?

avec code de sortie 80131506

C'est méchant, ExecutionEngineException. À partir de .NET 4.0, cette exception met immédiatement fin au programme. La cause générique est la corruption de l'état du tas de récupération de place. Ce qui à son tour est invariablement causé par du code non managé. L'emplacement exact dans le code auquel cette exception est déclenchée n'est pas utile, la corruption s'est généralement produite bien avant que le dommage ne soit détecté.

Trouver la cause exacte de cela va être difficile. Examinez tout code non géré que votre service peut utiliser. Suspectez des problèmes environnementaux s'il n'y a pas de candidat évident, les scanners de logiciels malveillants qui se comportent mal sont notoires. S'il se répète très mal, suspectez des problèmes matériels tels que des erreurs de RAM logicielles.

Un bogue dans l'implémentation simultanée du Garbage Collection sur x64 .Net 4 peut provoquer cela, comme indiqué dans l'entrée Microsoft KB suivante:

ExecutionEngineException se produit pendant le nettoyage de la mémoire

Vous devez d'abord effectuer une exploration approfondie du minidump pour vous assurer que le problème s'est produit lors d'un nettoyage de la mémoire.

L'emplacement du minidump se trouve généralement dans une entrée de rapport d'erreurs Windows dans le journal des événements après l'entrée de panne. Ensuite, amusez-vous avec WinDbg!

La dernière documentation sur l'utilisation de l' <gcConcurrent/>élément de configuration, pour désactiver le garbage collection simultané ou (dans .NET 4 et versions ultérieures) en arrière-plan, peut être trouvée ici .

J'ai rencontré des "erreurs internes" dans le runtime .NET qui se sont avérées être causées par des bogues dans mon code; ne pensez pas que simplement parce qu'il s'agissait d'une "erreur interne" dans le runtime .NET, il n'y a pas de bogue dans votre code comme cause principale. Toujours toujours blâmer votre propre code avant de blâmer quelqu'un d'autre.

J'espère que vous avez des informations de journalisation et de trace d'exception / pile pour vous indiquer où commencer la recherche, ou que vous pouvez répéter l'état du système avant le crash.

Pour ceux qui arrivent ici de google, j'ai finalement rencontré cette question SO , et cette réponse spécifique a résolu mon problème. J'ai contacté Microsoft pour le correctif via le chat en direct sur support.microsoft.com et ils m'ont envoyé un lien vers le correctif par e-mail.

Après des années de lutte avec ce problème dans un certain nombre d'applications, il semble que Microsoft l'ait finalement accepté comme un bogue dans .NET 4 CLR qui provoque ce problème. http://support.microsoft.com/kb/2640103 .

Je l'avais auparavant "corrigé" en forçant le ramasse-miettes à fonctionner en mode serveur (gcServer enabled = "true" dans app.config) comme décrit dans l'article Microsoft lié par Think Before Coding. Cela oblige essentiellement tous les threads de l'application à faire une pause pendant la collecte, supprimant la possibilité que d'autres threads accèdent à la mémoire étant manipulés par le GC. Je suis heureux de constater que mes années de recherche en vain d'un "bogue" dans mon code ou dans d'autres bibliothèques tierces non gérées n'ont été vaines que parce que le bogue résidait dans le code de Microsoft, pas dans le mien.

Il peut s'agir d'un bogue avec le GC simultané http://support.microsoft.com/kb/2679415

Eu la même erreur exacte sur la boîte WinXP avec la dernière version de mon code .NET 4. Vérifié les versions précédentes - maintenant elles plantent aussi! Ok, donc ce n'est pas moi :). Aucune suggestion ici / ci-dessus n'a aidé.

Rapport beaucoup plus récent (09/05/2018) du même problème: Crash d'application avec code de sortie 80131506 .

R : Nous recevions une erreur similaire, mais nous pensons que la nôtre a été causée par l'optimiseur de mémoire Citrix.
La résolution consistait à forcer une régénération des bibliothèques principales .Net sur les hôtes où le problème se produisait:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\ngen.exe update /force

La cause première est encore inconnue (la machine n'est pas mise à jour et a peu d'utilité), mais cela l'a fait pour moi !

Dans mon cas, cette exception s'est produite lorsque l'espace disque était écoulé et .NET ne peut pas allouer de mémoire dans la mémoire virtuelle Windows.

Dans le journal des événements, j'ai vu cette erreur:

Fenêtre contextuelle de l'application: Windows - Mémoire virtuelle minimale trop faible: votre système manque de mémoire virtuelle. Windows augmente la taille de votre fichier d'échange de mémoire virtuelle. Au cours de ce processus, les demandes de mémoire pour certaines applications peuvent être refusées.

Et erreur précédente:

Le disque C: est à pleine capacité ou presque. Vous devrez peut-être supprimer certains fichiers.

Dans mon cas, le problème était une bibliothèque C ++ / CLI dans laquelle il y avait un appel au NtQuerySystemInformation ; pour une raison quelconque parfois (et dans des circonstances mystérieuses ), quand il était appelé, le tas CLR était corrompu et l'application plantait.

J'ai résolu le problème en utilisant un "tas personnalisé" créé avec HeapCreate et en y allouant les tampons utilisés par cette fonction.

Je ne suis pas sûr que cela puisse aider tout le monde, mais je pourrais contourner ce problème en exécutant

devenv.exe /ResetSettings 

...Sur le chemin {Visual_Studio_root}\Common7\Ide

J'ai eu les erreurs suivantes dans le journal des événements et VS ne faisait que planter et redémarrer tout le temps:

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: 

Dans mon cas, le problème était dû à des redirections de liaison en double dans mon web.config. Plus d'infos ici .

Je suppose que c'était à cause de NuGet modifiant les redirections de liaison, mais par exemple, cela ressemblait à ceci:

  <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 suppression de tous les doublons a résolu le problème.

Dans mon cas, cette erreur s'est produite lors de la connexion à l'application SAP Business One 9.1. Dans les événements Windows, j'ai pu trouver également un autre événement d'erreur en plus de celui signalé par l'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 machine exécute Windows 8.1, avec .NET Framework 4.0 installé et sans la version 4.5. Comme il semblait sur Internet que cela pouvait également être un bogue dans .NET 4, j'ai essayé d' installer .NET Framework 4.5.2 et j'ai résolu le problème.

Version du framework: v4.0.30319 Description: le processus a été arrêté en raison d'une exception non gérée. Informations d'exception: System.Reflection.TargetInvocationException

J'ai rencontré cette erreur, l'application fonctionnait bien sur certains PC et sur certains PC donnant l'erreur ci-dessus. Je désinstalle le Framework 4.5 et réinstalle cela a résolu mon problème.

Acclamation.

Cela peut être une exception se produisant dans le finaliseur. Si vous faites le modèle de ~ Class () {Dispose (false); } vérifiez ce que vous supprimez en tant que ressource non gérée. Juste essayer ... attraper là et tout devrait être bien.

Nous avons trouvé le problème car nous avons eu cet échec mystérieux sans journaux. Nous avons fait le modèle habituel recommandé d'utiliser un "void Dispose (bool disposing)".

En regardant les réponses à cette question sur le finaliseur, nous avons trouvé un endroit possible où l'élimination des ressources non gérées pourrait lever une exception.

Il s'avère que quelque part nous n'avons pas disposé l'objet correctement ainsi le finaliseur a pris en charge le diposal des ressources non gérées donc voici qu'une exception s'est produite.

Dans ce cas, nous utilisions l'API Kafka Rest pour nettoyer le client de Kafka. Il semble qu'il ait jeté une exception à un moment donné, puis ce problème s'est produit.

Dans mon cas, le problème était lié au « référencement de la bibliothèque standard .NET dans les projets asp.net classiques » et à ces deux problèmes

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

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

et la rétrogradation vers Polly v6 était suffisante pour contourner le problème

Je n'ai jamais compris pourquoi cela m'arrivait. Il était toujours reproductible pour l'une de mes applications, mais a disparu après un simple redémarrage.

J'utilise Windows 2004 Build 19582.1001 (Insider Preview) avec .net-4.8 et je ne serais pas non plus surpris si cela était dû à quelque chose comme une erreur de mémoire matérielle. De plus, mon application charge du code non géré et l'initialise, donc je ne peux pas prouver que le crash n'est pas venu de cela.

Toutes les 5 à 10 minutes, mon pool d'applications a continué à planter avec ce code de sortie. Je ne veux pas ruiner votre confiance envers le garbage collector, mais la solution suivante a fonctionné pour moi.

J'ai ajouté un job qui appelle GC.GetTotalMemory(true) chaque minute.

Je suppose que, pour une raison quelconque, le GC n'inspecte pas automatiquement la mémoire assez souvent pour le nombre élevé d'objets jetables que j'utilise.