Приложение вылетает из-за «внутренней ошибки в среде выполнения .NET»

У нас есть приложение, написанное для .NET 4.0, которое на выходных вылетело из строя, и в журнал событий было занесено следующее сообщение:

Приложение: PnrRetrieverService.exe Версия Framework: v4.0.30319
Описание: Процесс был прерван из-за внутренней ошибки в среде выполнения .NET по IP 791F9AAA (79140000) с кодом выхода 80131506.

Это в коробке Windows Server 2003 R2 Standard Edition. Поиск в Google этой ошибки не дал ничего подходящего. Например, это происходит не в VS Studio, а в производственной коробке; когда служба была в конечном итоге перезапущена, проблем больше не возникло.

Как можно диагностировать ошибку в среде выполнения .NET?

с кодом выхода 80131506

Это неприятное исключение ExecutionEngineException. Начиная с .NET 4.0 это исключение немедленно завершает работу программы. Общая причина - повреждение состояния кучи со сборкой мусора. Что, в свою очередь, неизменно вызвано неуправляемым кодом. Точное место в коде, в котором возникает это исключение, бесполезно, повреждение обычно происходило задолго до обнаружения повреждения.

Найти точную причину этого будет сложно. Просмотрите любой неуправляемый код, который может использовать ваша служба. Если нет очевидного кандидата, подозревают проблемы с окружающей средой, плохо себя ведут сканеры вредоносных программ. Если он повторяется очень плохо, тогда подозревайте проблемы с оборудованием, такие как программные ошибки RAM.

Ошибка в параллельной реализации сборки мусора в x64 .Net 4 может вызвать это, как указано в следующей записи базы знаний Майкрософт:

ExecutionEngineException возникает во время сборки мусора

Сначала вы должны глубоко изучить минидамп, чтобы убедиться, что проблема возникла во время сборки мусора.

Расположение минидампа обычно можно найти в записи отчета об ошибках Windows в журнале событий после записи о сбое. Тогда веселитесь с WinDbg!

Последнюю документацию по использованию <gcConcurrent/>элемента конфигурации для отключения параллельной или (в .NET 4 и новее) фоновой сборки мусора можно найти здесь .

Я столкнулся с «внутренними ошибками» в среде выполнения .NET, которые, как оказалось, были вызваны ошибками в моем коде; не думайте, что в вашем коде нет ошибки как основной причины только потому, что это была "внутренняя ошибка" в среде выполнения .NET. Всегда всегда всегда обвиняйте свой собственный код, прежде чем обвинять кого-то другого.

Надеюсь, у вас есть информация о журналах и трассировке исключений / стека, которая укажет вам, с чего начать поиск, или что вы можете повторить состояние системы до сбоя.

Для тех, кто прибыл сюда из Google, я в конце концов столкнулся с этим вопросом SO , и этот конкретный ответ решил мою проблему. Я связался с Microsoft по поводу исправления через чат на support.microsoft.com, и они прислали мне ссылку на исправление по электронной почте.

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

Раньше я «исправлял» это, заставляя сборщик мусора работать в серверном режиме (gcServer enabled = «true» в app.config), как описано в статье Microsoft, на которую ссылается Think Before Coding. Это, по сути, заставляет все потоки в приложении приостанавливаться во время сбора, устраняя возможность доступа других потоков к памяти, управляемой сборщиком мусора. Я счастлив обнаружить, что мои годы тщетных поисков «ошибки» в моем коде или других сторонних неуправляемых библиотеках оказались бесплодными только потому, что ошибка заключалась в коде 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 я мог найти еще одно событие ошибки в дополнение к тому, о котором сообщил 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: 

Машина работает под управлением Windows 8.1 с установленной .NET Framework 4.0 и без версии 4.5. Поскольку в Интернете показалось, что это также может быть ошибка в .NET 4, я попытался установить .NET Framework 4.5.2 и решил проблему.

Версия Framework: v4.0.30319 Описание: Процесс был прерван из-за необработанного исключения. Информация об исключении: System.Reflection.TargetInvocationException

Я столкнулся с этой ошибкой, приложение работало нормально на некоторых компьютерах и на некоторых компьютерах, давая указанную выше ошибку. Я удалил Framework 4.5 и переустановил, это решило мою проблему.

Не унывайте.

Это может быть исключение, происходящее в финализаторе. Если вы выполняете шаблон ~ Class () {Dispose (false); } проверьте, что вы выбрасываете как неуправляемый ресурс. Просто попробуйте ... поймать там, и все будет в порядке.

Мы обнаружили проблему, так как у нас была таинственная ошибка без журналов. Мы использовали обычный рекомендуемый шаблон использования «void Dispose (bool dispose)».

Просматривая ответы на этот вопрос о финализаторе, мы нашли возможное место, где удаление неуправляемых ресурсов может вызвать исключение.

Оказывается, где-то мы не удалили объект должным образом, поэтому финализатор взял на себя распределение неуправляемых ресурсов, таким образом, произошло исключение.

В этом случае использовался API Kafka Rest для очистки клиента от Kafka. Похоже, что в какой-то момент это вызвало исключение, когда возникла эта проблема.

В моем случае проблема была связана с « Ссылка на стандартную библиотеку .NET в классических проектах asp.net », и эти две проблемы

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

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

и перехода на Polly v6 было достаточно, чтобы обойти это

Я так и не понял, почему это со мной происходит. Он постоянно воспроизводился для одного из моих приложений, но исчез после простой перезагрузки.

Я использую Windows 2004 Build 19582.1001 (Insider Preview) с .net-4.8, и я также не удивлюсь, если бы это было связано с чем-то вроде аппаратной ошибки памяти. Кроме того, мое приложение загружает неуправляемый код и инициализирует его, поэтому я не могу доказать, что сбой произошел не из-за этого.

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

Я добавил задание, которое звонит GC.GetTotalMemory(true)каждую минуту.

Я полагаю, что по какой-то причине GC автоматически не проверяет память достаточно часто для большого количества одноразовых объектов, которые я использую.