Ошибка приложения с "внутренней ошибкой в ​​.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 Runtime?

Ответ 1

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

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

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

Ответ 2

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

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

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

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

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

Ответ 3

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

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

Ответ 4

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

Ответ 6

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

Я ранее "исправлял" его, заставляя сборщик мусора работать в режиме сервера (gcServer enabled = "true" в app.config), как описано в статье Microsoft, связанной с Think Before Coding. Это по существу заставляет все потоки приложения приостанавливать во время сбора, что устраняет возможность доступа других потоков к памяти, обрабатываемой GC. Я с удовольствием обнаружил, что мои годы поиска тщетно для "ошибки" в моем коде или других сторонних неуправляемых библиотеках были безрезультатными, потому что ошибка лежала в коде Microsoft, а не на моем.

Ответ 7

В моем случае это исключение возникло, когда пространство на диске закончилось, и .NET не может выделить память в виртуальной памяти Windows.

В журнале событий я увидел эту ошибку:

Всплывающее окно приложения: Windows - виртуальная память с минимальным снизем: ваша система на виртуальной памяти низкая. Windows увеличивает размер файла подкачки виртуальной памяти. Во время этого процесса запросы памяти для некоторых приложений могут быть отклонены.

И предыдущая ошибка:

Диск C: находится на уровне или около него. Возможно, вам придется удалить некоторые файлы.

Ответ 8

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

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

Cheer.

Ответ 9

В моем случае проблема была в библиотеке С++/CLI, в которой был вызов NtQuerySystemInformation; по какой-то причине иногда (и при таинственных обстоятельствах), когда она называлась кучей CLR, была повреждена, и приложение потерпело крах.

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

Ответ 10

В моем случае эта ошибка возникла при входе в приложение 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, и я решил проблему.

Ответ 11

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

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

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

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

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

Ответ 12

Я не уверен, что это может помочь всем, но я мог обойти это, запустив

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: