Поиск и устранение неисправностей.NET “фатальная ошибка механизма выполнения”
Сводка:
Я периодически получаю.NET Фатальная Ошибка Механизма выполнения на приложении, которое я, может казаться, не отлаживаю. Диалоговое окно, которое подходит только предложения закрыть программу или отправить информацию об ошибке в Microsoft. Я попытался смотреть на более подробную информацию, но я не знаю, как использовать ее.
Ошибка:
Ошибка видима в Event Viewer в соответствии с Приложениями и следующим образом:
Версия среды выполнения 2.0.50727.3607.NET - Фатальная Ошибка Механизма выполнения (7A09795E) (80131506)
Компьютером, выполняющим его, являются Windows XP Professional SP 3. (Intel Core2Quad Q6600 2.4GHz w/2,0 ГБ RAM), Другие основанные на.NET проекты, которые испытывают недостаток в многопоточной загрузке (см. ниже), кажется, работают очень хорошо.
Приложение:
Приложение записано в C#/.NET 3.5 с помощью VS2008 и установлено с помощью проекта установки.
Приложение является многопоточным и загружает данные из нескольких использования веб-серверов System.Net.HttpWebRequest и его методы. Я решил, что ошибка.NET имеет некоторое отношение или к поточной обработке или к HttpWebRequest, но я не смог добраться немного ближе, поскольку эта конкретная ошибка кажется невозможной отладить.
Я попробовал ошибки из-за неправильного обращения на многих уровнях, включая следующее в Program.cs:
// handle UI thread exceptions
Application.ThreadException += Application_ThreadException;
// handle non-UI thread exceptions
AppDomain.CurrentDomain.UnhandledException += CurrentDomain_UnhandledException;
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
// force all windows forms errors to go through our handler
Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException);
Больше примечаний и что я попробовал...
- Установленный 2008 Visual Studio на целевой машине и попробованном выполнении в режиме отладки, но ошибке все еще происходит без подсказки как, туда, где в исходном коде это произошло.
- При запущении программы от ее установленной версии (Выпуск) ошибка происходит более часто, обычно в течение минут после запуска приложения. При запущении программы в режиме отладки в VS2008, это может работать в течение многих часов или дней прежде, чем генерировать ошибку.
- Переустановленная.NET 3.5 и удостоверилась, что все обновления применяются.
- Повредил случайные объекты кабины в разочаровании.
- Переписанные части кода, которые имеют дело с поточной обработкой и загрузкой в попытках поймать и зарегистрировать исключения, хотя вход, казалось, ухудшил проблему (и никогда не обеспечивал данных).
Вопрос:
Какие шаги я могу сделать, чтобы диагностировать или отладить этот вид ошибки? Дампы памяти и т.п., кажется, следующий шаг, но я не испытан при интерпретации их. Возможно, существует что-то больше, что я могу сделать в коде, чтобы попытаться зафиксировать ошибки... Было бы хорошо, если бы "Фатальная Ошибка Механизма выполнения" была более информативной, но поиски в Интернете только сказали мне, что это - распространенная ошибка для большого количества связанных с.NET объектов.
2 ответа
Что ж, у вас большая проблема. Это исключение вызывается средой CLR, когда она обнаруживает, что целостность кучи при сборке мусора нарушена. Повреждение кучи, проклятие любого программиста, который когда-либо писал код на неуправляемом языке, таком как C или C ++.
Эти языки позволяют очень легко повредить кучу, все, что нужно, - это записать за конец массива, выделенного в куче. Или использовать память после того, как она была освобождена. Или неверное значение указателя. Типа ошибок, для решения которых был изобретен управляемый код.
Но, судя по вашему вопросу, вы используете управляемый код. Ну, в основном ваш код управляется. Но вы выполняете лотов неуправляемого кода. Весь низкоуровневый код, который фактически заставляет HttpWebRequest работать, неуправляем. Как и среда CLR, она была написана на C ++, поэтому технически с такой же вероятностью может повредить кучу.Но после более чем четырех тысяч ревизий и миллионов программ, использующих его, шансы, что он все еще будет страдать от кучи, очень очень мал.
То же самое не относится ко всему другому неуправляемому коду, которому нужен фрагмент HttpWebRequest. Код, о котором вы не знаете, потому что вы его не писали, и не документирован Microsoft. Ваш брандмауэр. Ваш антивирусный сканер. Монитор использования Интернета вашей компанией. Бог знает чей "ускоритель загрузки".
Изолируйте проблему, предположив, что ее не вызывает ни ваш код, ни код Microsoft. Предположите, что это в первую очередь экология, и избавьтесь от ненужного ПО.
Чтобы узнать об эпической истории FEEE, посвященной окружающей среде, прочтите эту ветку .
Презентация, которая может быть хорошим руководством о том, с чего начать с такого рода проблемами, следующая: Хардкорная производственная отладка в .NET, Инго Раммер .
Я немного занимаюсь кодированием C ++ / CLI, и повреждение кучи обычно не приводит к этой ошибке; обычно повреждение кучи либо вызывает повреждение данных и последующее нормальное исключение, либо ошибку защиты памяти, что, вероятно, ничего не значит.
В дополнение к попытке .net 4.0 (которая по-разному загружает неуправляемый код) вам следует сравнить версии CLR x86 и x64 - если возможно, версия x64 имеет большее адресное пространство и, следовательно, совершенно другое поведение malloc (+ фрагментация) и так что вам может повезти, и у вас будет другая (более отлаживаемая) ошибка (если она вообще возникнет).
Кроме того, включали ли вы отладку неуправляемого кода в отладчике (опция проекта) при работе с включенной Visual Studio? А у вас есть помощники по управляемой отладке?