Збій програми з "внутрішньою помилкою в .NET Runtime"

У нас є програма, написана проти .NET 4.0, яка протягом вихідних вийшла з ладу, помістивши в журнал подій таке повідомлення:

Додаток: PnrRetrieverService.exe Рамкова версія: v4.0.30319
Опис: Процес було припинено через внутрішню помилку в .NET Runtime за IP 791F9AAA (79140000) з кодом виходу 80131506.

Це у вікні Windows Server 2003 R2 Standard Edition. Помилка цієї помилки не виявила нічого актуального. Наприклад, це не відбувається в VS Studio, а натомість у виробничій коробці; коли з часом послуга була перезапущена, більше проблем не виникало.

Як можна діагностувати помилку під час виконання .NET?

з кодом виходу 80131506

Це жахливо, ExecutionEngineException. Починаючи з .NET 4.0, це виключення негайно припиняє програму. Загальною причиною є корупція стану сміття, що збирається. Що, в свою чергу, незмінно викликано некерованим кодом. Точне розташування в коді, за яким піднімається цей виняток, не корисне, корупція, як правило, виникала задовго до виявлення шкоди.

Знайти точну причину цього буде складно. Перегляньте будь-який некерований код, який може використовувати ваша послуга. Підозрюйте екологічні проблеми, якщо явного кандидата немає, сканери зловмисного програмного забезпечення невідомі. Якщо це повторюється дуже погано, тоді підозрюйте проблеми з апаратним забезпеченням, наприклад, м'які помилки RAM.

Помилка при одночасному виконанні збору сміття на x64 .Net 4 може спричинити це, як зазначено в наступній статті Microsoft Microsoft KB:

ExecutionEngineException відбувається під час збору сміття

Спершу слід провести глибоке розслідування, щоб переконатися, що проблема виникла під час збору сміття.

Місце мінімального скиду зазвичай можна знайти у записі Повідомлення про помилки Windows у журналі подій після запису аварії. Тоді, веселіться з WinDbg!

Останню документацію щодо використання <gcConcurrent/>елемента конфігурації для відключення одночасного або (у .NET 4 та пізніших версіях) збору сміття у фоновому режимі можна знайти тут .

Я відчував "внутрішні помилки" під час виконання .NET, які виявилися через помилки в моєму коді; не думайте, що лише тому, що це була "внутрішня помилка" в процесі виконання .NET, що у вашому коді немає помилки як першопричини. Завжди завжди звинувачуйте власний код перед тим, як звинувачувати чужий.

Сподіваємось, у вас є інформація про реєстрацію та відстеження / стеження, щоб вказати, з чого почати шукати, або ви зможете повторити стан системи перед збоєм.

Для тих, хто приїхав сюди з google, я врешті-решт натрапив на це питання ТА , і ця конкретна відповідь вирішила мою проблему. Я зв’язався з Microsoft за виправленням через чат наживо на support.microsoft.com, і вони надіслали мені посилання на виправлення електронною поштою.

Після багатьох років боротьби з цією проблемою в ряді застосувань виявляється, що Microsoft нарешті прийняла це як помилку в .NET 4 CLR, що спричиняє це. http://support.microsoft.com/kb/2640103 .

Раніше я "виправляв" це, змушуючи збирач сміття працювати в серверному режимі (gcServer увімкнено = "true" в app.config), як описано в статті Microsoft, пов'язаної з Think Before Coding. Це по суті змушує всі потоки в програмі робити паузу під час колекції, виключаючи можливість інших потоків отримати доступ до пам'яті, якою управляє GC. Я радий виявити, що мої роки марних пошуків «помилки» в моєму коді чи інших сторонніх некерованих бібліотеках були лише безрезультатними, оскільки помилка лежала в коді Microsoft, а не в моєму.

Може бути помилка з одночасною GC http://support.microsoft.com/kb/2679415

Була така ж точна помилка у вікні WinXP з останньою збіркою мого коду .NET 4. Перевірили попередні версії - тепер вони теж виходять з ладу! Гаразд, так це не я :). Жодні пропозиції тут / вище не допомогли.

Набагато новіший (2018-05-09) звіт про ту саму проблему: Збірка програми з кодом виходу 80131506 .

Відповідь : Ми отримували подібну помилку, але ми вважаємо, що наше було спричинено оптимізатором пам'яті Citrix.
Постанова повинна була примусити відновити основні бібліотеки .Net на хостах, де виникала проблема:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\ngen.exe update /force

Причинна причина ще невідома (машина не оновлюється і мало користі), але це зробило це для мене !

У моєму випадку цей виняток стався, коли місце на диску закінчилось і .NET не може виділити пам'ять у віртуальній пам'яті Windows.

У журналі подій я побачив цю помилку:

Спливаюче вікно програми: Windows - Мінімальна занадто низька кількість віртуальної пам'яті: у вашій системі мало віртуальної пам'яті. Windows збільшує розмір файлу підкачки віртуальної пам’яті. У ході цього процесу запити на пам'ять деяких програм можуть бути відхилені.

І попередня помилка:

C: диск знаходиться на або майже ємною. Можливо, вам доведеться видалити деякі файли.

У моєму випадку проблема полягала в бібліотеці C ++ / CLI, в якій був виклик до NtQuerySystemInformation ; з якихось причин іноді (і за загадкових обставин ), коли він називався, група CLR пошкоджувалася, а програма виходила з ладу.

Я вирішив проблему, використовуючи "власну купу", створену з HeapCreate, і розподіляючи там буфери, які використовуються для цієї функції.

Я не впевнений, що може допомогти всім, але я міг би обійти це, бігаючи

devenv.exe /ResetSettings 

... в стежку {Visual_Studio_root}\Common7\Ide

У журналі подій у мене були такі помилки, і VS весь час виходив з ладу та перезавантажувався:

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: 

У моєму випадку проблема сталася через повторювані переадресації прив’язки у моїй web.config. Більше інформації тут .

Я припускаю, що це було через те, що NuGet змінює переадресації прив’язки, але, наприклад, це виглядало так:

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

Видалення всіх дублікатів вирішило проблему.

У моєму випадку ця помилка сталася під час входу в додаток SAP Business One 9.1. У подіях Windows я міг знайти ще одну подію помилки на додаток до тієї, про яку повідомляє ОП:

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: 

Машина працює під управлінням Windows 8.1, встановлена ​​.NET Framework 4.0 та без версії 4.5. Оскільки в Інтернеті здавалося, що це також може бути помилка в .NET 4, я спробував встановити .NET Framework 4.5.2, і я вирішив проблему.

Версія рамки: v4.0.30319 Опис: Процес було припинено через необроблений виняток. Інформація про виняток: System.Reflection.TargetInvocationException

Я зіткнувся з цією помилкою, додаток добре працював на деяких комп'ютерах і на деяких комп'ютерах, даючи помилку вище. Я видаляю Framework 4.5 і повторно встановлюю цю проблему, вирішивши свою проблему.

Ура.

Це може бути виняток, що виникає у фіналізаторі. Якщо ви робите шаблон шаблону ~ Class () {Dispose (false); } перевірте, що ви розміщуєте як некерований ресурс. Просто поставте спробу. Ловіть там, і вам слід добре.

Ми виявили проблему, оскільки у нас виник цей загадковий збій без журналів. Ми зробили звичайний рекомендований зразок використання "void Dispose (bool disposition)".

Дивлячись на відповіді на це запитання про фіналізатор, ми знайшли можливе місце, де знешкодження некерованих ресурсів може кинути виняток.

Виявляється, десь ми не розмістили об'єкт належним чином, тому фіналізатор взяв на себе розпорядження некерованими ресурсами, таким чином, ось виняток стався.

У цьому випадку використовували API відпочинку Kafka для очищення клієнта від Kafka. Здається, що вона кинула виняток у якийсь момент, тоді ця проблема виникла.

У моєму випадку проблема була пов'язана з " Посиланням на стандартну бібліотеку .NET у класичних проектах asp.net " та цими двома проблемами

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

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

і пониження рівня до Полі v6 було достатньо, щоб її обійти

Я ніколи не зрозумів, чому це відбувається для мене. Це було незмінно відтворене для однієї з моїх програм, але пішло після простого перезавантаження.

У мене працює Windows 2004 Build 19582.1001 (Insider Preview) з .net-4.8, і я також не був би здивований, якби це було пов’язано з чимось на зразок помилки в апаратній пам'яті. Крім того, моя програма завантажує деякий некерований код і ініціалізує його, тому я не можу довести, що збій не стався з цього приводу.

Кожні 5-10 хвилин мій пул додатків постійно виходив із цього коду виходу. Я не хочу зруйнувати вашу довіру до збирача сміття, але наступне рішення працювало для мене.

Я додав роботу, яка телефонує GC.GetTotalMemory(true)щохвилини.

Я припускаю, що чомусь GC автоматично не перевіряє пам'ять досить часто на велику кількість одноразових об'єктів, якими я користуюся.