Сбой приложения с "внутренней ошибкой в среде выполнения.NET"
У нас есть приложение, написанное против.NET 4.0, которое в выходные дни рухнуло, поместив следующее сообщение в журнал событий:
Приложение: PnrRetrieverService.exe Framework Версия: v4.0.30319
Описание: процесс был прерван из-за внутренней ошибки.NET Runtime по IP 791F9AAA (79140000) с кодом выхода 80131506.
Это на Windows Server 2003 R2 Standard Edition. Поиск этой ошибки не нашел ничего подходящего. Например, это не происходит в VS Studio, но вместо этого на производственной коробке; когда служба была перезапущена, проблем не возникало.
Как можно диагностировать ошибку в.NET Runtime?
18 ответов
с кодом выхода 80131506
Это неприятный, ExecutionEngineException. Начиная с.NET 4.0, это исключение немедленно завершает работу программы. Общей причиной является искажение состояния кучи мусора. Что, в свою очередь, неизменно вызывается неуправляемым кодом. Точное местоположение в коде, в котором вызывается это исключение, не помогает, повреждение обычно происходит задолго до обнаружения повреждения.
Найти точную причину этого будет сложно. Просмотрите любой неуправляемый код, который может использовать ваша служба. Подозревать проблемы с окружающей средой, если нет очевидного кандидата, плохо себя ведут сканеры вредоносных программ. Если он повторяется очень плохо, то заподозрите аппаратные проблемы, такие как ошибки оперативной памяти.
Ошибка в параллельной реализации сборки мусора в x64 .Net 4 может вызвать это, как указано в следующей записи Microsoft KB:
ExecutionEngineException происходит во время сборки мусора
Сначала вы должны глубоко исследовать мини-дамп, чтобы убедиться, что проблема возникла во время сборки мусора.
Расположение минидампа обычно можно найти в записи об ошибках Windows в журнале событий после записи о сбое. Тогда веселитесь с WinDbg!
Последняя документация по использованию <gcConcurrent/> Элемент конфигурации, чтобы отключить одновременную или (в.NET 4 и более поздних) фоновую сборку мусора, можно найти здесь.
Я испытал "внутренние ошибки" во время выполнения.NET, которые, как оказалось, были вызваны ошибками в моем коде; не думайте, что это просто "внутренняя ошибка" во время выполнения.NET, что в коде нет ошибки как основной причины. Всегда всегда вините свой собственный код, прежде чем винить чужой.
Надеюсь, у вас есть информация о журналах и трассировке исключений / стека, чтобы указать вам, с чего начать поиск, или о том, что вы можете повторить состояние системы перед сбоем.
Для тех, кто приезжает сюда из Google, я в конечном итоге столкнулся с таким вопросом, и этот конкретный ответ решил мою проблему. Я связался с Microsoft по поводу исправления через чат в чате на http://support.microsoft.com/, и они отправили мне ссылку на исправление по электронной почте.
Точно такая же ошибка на коробке WinXP с последней сборкой моего кода.NET 4. Проверял предыдущие сборки - теперь они тоже рушатся! Хорошо, так что это не я:). Никакие предложения здесь / выше не помогли.
Гораздо более свежий (2018-05-09) отчет об этой же проблеме: сбой приложения с кодом выхода 80131506.
A: Мы получили похожую ошибку, но мы считаем, что наша была вызвана оптимизатором памяти Citrix.
Решение состояло в том, чтобы принудительно восстановить основные библиотеки.Net на хостах, где возникла проблема:C:\Windows\Microsoft.NET\Framework64\v4.0.30319\ngen.exe update /force
Основная причина до сих пор неизвестна (машина не обновляется и мало используется), но это сделало это для меня!
После многих лет борьбы с этой проблемой в ряде приложений, похоже, что Microsoft наконец приняла это как ошибку в.NET 4 CLR, которая вызывает это. http://support.microsoft.com/kb/2640103.
Ранее я "исправлял" его, заставляя сборщик мусора работать в режиме сервера (gcServer enabled="true" в app.config), как описано в статье Microsoft, на которую ссылается Think Before Coding. По сути, это заставляет все потоки в приложении делать паузу во время сбора, исключая возможность доступа других потоков к памяти, управляемой GC. Я счастлив, что мои годы тщетного поиска "ошибки" в моем коде или других неуправляемых библиотеках третьих сторон оказались бесплодными, потому что ошибка лежала в коде Microsoft, а не в моем.
Может быть ошибка с одновременным GC http://support.microsoft.com/kb/2679415
Каждые 5-10 минут мой пул приложений продолжал падать с этим кодом выхода. Я не хочу разрушать ваше доверие к сборщику мусора, но следующее решение сработало для меня.
Я добавил работу, которая звонит GC.GetTotalMemory(true) каждую минуту.
Я полагаю, что по какой-то причине ГХ не выполняет автоматическую проверку памяти достаточно часто на предмет большого количества одноразовых предметов, которые я использую.
В моем случае это исключение произошло, когда дисковое пространство закончилось, и.NET не может выделить память в виртуальной памяти Windows.
В журнале событий я увидел эту ошибку:
Всплывающее окно приложения: Windows - минимальная виртуальная память слишком мала: в вашей системе недостаточно виртуальной памяти. Windows увеличивает размер вашего файла подкачки виртуальной памяти. Во время этого процесса запросы памяти для некоторых приложений могут быть отклонены.
И предыдущая ошибка:
Диск C: находится на или почти заполнен. Возможно, вам придется удалить некоторые файлы.
Я не уверен, что это может помочь всем, но я мог бы обойти это, запустив
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:
В моем случае проблема была связана с "Ссылкой на стандартную библиотеку.NET в классических проектах asp.net" и этими двумя проблемами.
https://github.com/dotnet/standard/issues/873
https://github.com/App-vNext/Polly/issues/628
и понижения до Полли v6 было достаточно, чтобы обойти это
В моем случае проблема была в библиотеке C++/CLI, в которой был вызов NtQuerySystemInformation; иногда по какой-то причине (и при загадочных обстоятельствах), когда он назывался, куча CLR была повреждена, и приложение упало.
Я решил проблему с помощью "пользовательской кучи", созданной с помощью HeapCreate, и выделил там буферы, используемые этой функцией.
В моем случае проблема была из-за дублирующих перенаправлений привязки в моем 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>
Удаление всех дубликатов решило проблему.
Это может быть исключение, возникающее в финализаторе. Если вы делаете Pattern of ~Class(){ Dispose(false); } проверьте, что вы используете как неуправляемый ресурс. Просто сделайте попытку.. поймайте там и все будет хорошо.
Мы нашли проблему, так как у нас был этот загадочный сбой без логов. Мы выполнили обычный рекомендуемый способ использования "void Dispose(bool dispose)".
Глядя на ответы на этот вопрос о финализаторе, мы нашли возможное место, где удаление неуправляемых ресурсов может вызвать исключение.
Оказывается, где-то мы не распорядились объектом должным образом, поэтому финализатор принял дипозал неуправляемых ресурсов, и вот, произошло исключение.
В этом случае использовался API Kafka Rest для очистки клиента от Kafka. Кажется, что в какой-то момент возникло исключение, после чего возникла эта проблема.
Версия Framework: v4.0.30319 Описание: процесс был прерван из-за необработанного исключения. Информация об исключении: System.Reflection.TargetInvocationException
Я столкнулся с этой ошибкой, приложение работало нормально на некоторых компьютерах и на некоторых компьютерах, выдавая вышеуказанную ошибку. Я удаляю Framework 4.5 и переустанавливаю это решило мою проблему.
Не унывайте.
У меня была такая же проблема в Windows 2016 при установке SQL Server 2017. Ошибка была
«ScenarionEngine.exe аварийно завершает работу из-за «внутренней ошибки в среде выполнения .NET»
Сначала проверьте версию Microsoft .NET Framework, если это 4.5, а затем выполните обновление до последней версии. В настоящее время это Microsoft .NET Framework 4.8. Если это не работает для вас, попробуйте следующий шаг.
Следующий шаг: удалите KB4486129, а затем загрузите Microsoft .NET Framework 4.8. Та же ошибка была решена для меня.
Я так и не понял, почему это со мной происходит. Он постоянно воспроизводился для одного из моих приложений, но исчез после простой перезагрузки.
Я использую Windows 2004 Build 19582.1001 (Insider Preview) с.net-4.8, и я также не удивлюсь, если бы это было связано с чем-то вроде аппаратной ошибки памяти. Кроме того, мое приложение загружает неуправляемый код и инициализирует его, поэтому я не могу доказать, что сбой произошел не из-за этого.
В моем случае эта ошибка произошла при входе в приложение 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 и решил эту проблему.