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

Еще один случай, когда выдается System.ExecutionEngineException, - это когда необработанное исключение выдается в делегате, предоставленном функции ThreadPool.QueueUserWorkItem().

Answer 2

Я только что столкнулся с этим исключением, работая над приложением WPF. VS показал, что это произошло при уведомлении об изменении свойства через NotifyPropertyChanged call (INotifyPropertyChanged).

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

Answer 3

Я получаю эту ошибку в обычном запросе LINQ, где я возвращаю FirstOrDefault с использованием VS2010

Answer 4

Мне кажется, что эта проблема возникает в чисто управляемом приложении WPF в довольно невинной ситуации. У меня есть элемент управления в сетке, который я хочу отобразить или скрыть, поэтому я устанавливаю его видимость Visibility.Collapsed или Visibility.Visible. Это начало рухнуло. Я нажимаю кнопку, и она становится видимой и выглядит просто отлично. Я нажимаю другую кнопку и устанавливаю, что она свернулась и гремит - большая ужасная ошибка. Ничего особенного или необычного. Это использует 4.5. Очень странно. Когда я смотрю на данные об ошибке, это говорит System.Collections.EmptyReadOnlyDictionaryInternal.

Answer 5

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

Answer 6

Мне удалось получить это исключение при отладке веб-приложения C # 4.0, в котором используется сборка, использующая служебную шину Azure. В этой сборке есть ошибка, из-за которой она будет пытаться зацикливаться навсегда, чтобы получить сообщение от закрытой шины обслуживания, но обработчик исключений перехватывает это исключение. Однако при отладке кода он фактически убил Visual Studio 2012 за этим исключением! Да, VS2012 был тем, кто бросил исключение.

Answer 7

Просто, чтобы добавить в список возможных причин, у меня была эта ошибка при попытке сериализации IEnumerable <>, содержащего сложный тип.

Изменение с IEnumerable<> на List<> решило проблему.

Answer 8

Я получил один из них, когда мой модуль C # (вызванный приложением C ++ / MFC, созданным с / CLR) по неосторожности отменил нулевой указатель. Таким образом, исключение может произойти из-за ошибки в «коде пользователя».

Кевин

Answer 9

Использование неправильного маршалинга вызывает у меня это исключение. У меня был чистый C * .dll для использования; Я пишу обертку вокруг этого в C #, используя DllImport; затем я использовал маршалинг для выдачи строковых параметров для заполнения StringBuilder, например:

    [DllImport("old.dll", CallingConvention = CallingConvention.Winapi, CharSet = CharSet.Ansi)]
    public static extern UInt32 GetMessage([MarshalAs(UnmanagedType.LPStr)] out StringBuilder message);

Использование UnmanagedType.LPStr вызывает у меня это исключение; использование UnmanagedType.BStr, верного маршала в этом случае, решило проблему. Просто мои 2 цента. : -)

Answer 10

Используя VS2015 ASP.NET Framework 4.5, мне просто пришлось пересобрать и запустить снова.