System.ExecutionEngineException Failure

Question

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

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

Я работаю в VS2003 над разработкой приложения, которое использует C ++. NET

Приложение использует в основном неуправляемый код и мало управляемый код (из-за сильного вмешательства сборщика мусора). Так что я бы оценил 95% неуправляемых, 5% управляемых

Я где-то читал, что нестабильный / глючный / неправильный неуправляемый код может испортить части памяти CLR, делая его поврежденным и выдавая эту ошибку.

Поскольку 95% приложений неуправляемые, я не уверен, с чего начать. Может быть, несколько классов, которые взаимодействуют между управляемым и неуправляемым? Как насчет сортировки данных от управляемых к неуправляемым? Может ли неправильный нулевой указатель вызвать этот сбой? Какие другие проблемы могут вызвать это? Индекс массива вне границ? А как насчет нулевого объекта?

Любая информация / статья / статья, которая может дать хороший список возможных причин сбоя System.ExecutionEngine, будет принята!

---

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

Список возможных причин / сценариев -

• Несоответствие аргумента между C ++ и C #
• При использовании отражения
• Служба WCF пытается вернуть IList или IEnumerable здесь здесь
• Использование инструментов профилирования
• с использованием инструкции std на ассемблере
• вызывая :: FreeLibrary () несколько раз
• .NET звонки из буфера обмена
• с использованием Unity Framework
• Использование неправильного маршалинга
• Использование INotifyPropertyChanged

Возможные обходные пути / решения -

• Отключить одновременную сборку мусора

Answer 1

К этому не стоит относиться слишком серьезно, но мне удалось получить это исключение, повеселившись с отражением:

typeof(IntPtr).GetField("Zero").SetValue(null, new IntPtr(666));

Answer 2

Была такая же проблема - моя ошибка оказалась несоответствием аргумента между моим C # кодом и моей C ++ native dll. Я добавил аргумент в функцию C ++ и не смог добавить его в сторону C #.

Answer 3

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

Answer 4

Существует известная ошибка, когда служба WCF пытается вернуть IList или IEnumerable.

http://connect.microsoft.com/wcf/feedback/details/433569/wcf-throws-an-executionengineexception-when-returning-an-array-as-ilist-t

Answer 5

Цитируется со справочной страницы MSDN для System.ExecutionEngineException:

Исключение, которое выдается при возникновении внутренней ошибки в механизме выполнения общеязыковой среды выполнения. Этот класс не может быть унаследован.

Не существует устаревшей альтернативы ExecutionEngineException. Если дальнейшее выполнение вашего приложения не может быть продолжено, используйте метод FailFast.

Подсказка

В некоторых случаях приложение, предназначенное для .NET Framework, может выдавать исключение ExecutionEngineException во время сбора мусора, когда приложение или система, в которой оно выполняется, находится под большой нагрузкой. В этом случае, чтобы обойти эту проблему, вы можете отключить одновременную сборку мусора, изменив файл конфигурации приложения. Для получения дополнительной информации см. Как отключить одновременную сборку мусора .

Answer 6

Хотя эта ветка к настоящему времени довольно старая, я упомяну свой собственный случай с этим исключением. Я сталкивался с этим при разработке расширения ArcGIS, написанного на VB.NET (Visual Studio 2005). ArcGIS сильно зависит от технологии COM, поэтому взаимодействие с .NET-COM необходимо. Я не нашел причину исключения до сих пор, но я предполагаю, что это может быть связано с созданием невыпущенных экземпляров COM-объектов, поскольку исключение возникает только после того, как программное обеспечение обрабатывает геометрию и числа для какое-то время.

Answer 7

Я недавно обнаружил, что использование инструкции std в ассемблере для установки флага направления без его очистки по завершении (cld) может вызвать эту ошибку. Я использую .Net 4.0.

Answer 8

Честно говоря, единственный раз, когда я видел это исключение, это когда я использовал инструменты Compuware DevPartner для выполнения профилирования и анализа кода. DevPartner подключается глубоко к ядру CLR, чтобы выполнить свою работу, но он полон ошибок, поэтому завинтите CLR. Мне пришлось перезагрузить компьютер (и не забывать никогда больше не нажимать кнопки панели инструментов DevPartner), чтобы вернуть все в нормальное состояние.

Если вы не используете devpartner, то, скорее всего, у вас есть неуправляемый код, который перегружает память, используемую CLR. Я бы посоветовал сначала сделать перезагрузку, а затем попытаться отследить любую ошибку, которая у вас есть, которая разрушает память. Ищите переполнения буфера, запись в неинициализированные указатели и все другие обычные подозреваемые.

Answer 9

Я получаю это ExecutionEngineException только при использовании стандартных вызовов .NET Clipboard. Мой код управляется на 100%. Похоже, что .NET Framework имеет проблемы.

PastedData = Clipboard.GetDataObject();
object imageObj = PastedData.GetData(dataType);

где тип данных "EnhancedMetafile", который был в списке форматов в буфере обмена.

Answer 10

обновите ваше приложение до .net 4.0 ИЛИ 4.5, потому что это исключение устарело. «Примечание: этот API устарел». см .: http://msdn.microsoft.com/en-us/library/system.executionengineexception(v=vs.100).aspx