глобальный обработчик исключений на уровне приложения не получил

Question

Мое приложение .net имеет глобальный обработчик исключений, подписавшись на событие AppDomain.Current.Domain UnhandledException. В нескольких случаях я видел, что мое приложение падает, но этот глобальный обработчик исключений никогда не срабатывает. Не уверен, что это поможет, но приложение выполняет COM-взаимодействие.

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

Answer 1

Является ли это причиной вашей проблемы?

AppDomain.CurrentDomain.UnhandledException не срабатывает без отладки

Answer 2

Поскольку вы выполняете COM-взаимодействие, я сильно подозреваю, что какой-то неуправляемый код выполнялся в другом потоке, что вызвало необработанное исключение. Это приведет к выходу приложения без вызова вашего обработчика необработанных исключений. Кроме того, в .NET 4.0 политика стала сильнее, когда приложение было закрыто без предварительного уведомления. При следующих условиях ваше приложение будет закрыто без предварительного уведомления (Environmnt.FailFast).

Pre .NET 4:

• StackOverflowException

.NET 4:

• StackOverflowException 1016 *
• AccessViolationException

Вы можете переопределить поведение в .NET 4, украсив метод с помощью HandleProcessCorruptedStateExceptionsAttribute или добавив тег legacyCorruptedStateExceptionsPolicy в свой файл App.config.

Если ваша проблема - это не отловленное исключение в неуправляемом коде, вы можете запустить приложение в отладчике или позволить ему аварийно завершить работу и собрать дамп памяти для посмертной отладки. Отладка аварийных дампов обычно выполняется с помощью WindDbg . После того, как вы загрузили Windbg, у вас есть adplus (скрипт vbs, расположенный в папке Programm Files \ Debugging Tools for Windows), который вы можете подключить к запущенному процессу, чтобы вызвать аварийный дамп, когда процесс завершается из-за исключения.

adplus -crash -p yourprocessid

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

Генерация аварийных дампов

Жесткие программисты будут настаивать на создании собственного инструмента генерации дампов, который в основном использует ключ реестра AEDebug . Когда этот ключ имеет значение, которое указывает на существующий исполняемый файл, он будет вызываться при сбое приложения, которое может, например, покажите диалог выбора отладчика Visual Studio или он может запустить генерацию дампа для вашего процесса.

Приостановить темы

Часто упускается из виду случай, когда вы создаете аварийный дамп с помощью внешнего инструмента (лучше полагаться на внешние инструменты, так как вы не знаете, насколько плох ваш процесс поврежден, и если его не хватает памяти, вы уже в плохом состоянии ситуация), что вы должны приостановить все потоки из сбойного процесса, прежде чем вы получите дамп. Когда вы делаете большой полный дамп памяти, это может занять несколько минут в зависимости от выделенной памяти сбойного процесса. В течение этого времени потоки приложения могут продолжать наносить ущерб состоянию вашего приложения, оставляя вас с дампом, который содержит несогласованное состояние процесса, которое изменилось во время создания дампа.

Answer 3

CLR не является мощным средством для обнаружения всех исключений, которые может вызвать неуправляемый код. Как правило, AccessViolationException между прочим. Он может поймать их только тогда, когда неуправляемый код вызывается из управляемого кода. Сценарий, который не поддерживается, заключается в том, что неуправляемый код раскручивает свой собственный поток, и этот поток вызывает сбой. Не исключено, что вы работаете с компонентом COM.

Начиная с .NET 4.0, исключение Fatal Execution Engine больше не вызывает событие UnhandledException. Исключение было сочтено слишком неприятным, чтобы разрешить выполнение любого управляемого кода. Это. И традиционно StackOverflowException вызывает немедленную отмену.

Вы можете диагностировать это несколько из ExitCode процесса. Он содержит код исключения, который завершил процесс. 0x8013yyyy - исключение, вызванное управляемым кодом. 0xc0000005 является нарушением прав доступа. Etcetera. Вы можете использовать adplus, доступный в разделе «Инструменты отладки для Windows», чтобы записать мини-дамп процесса. Поскольку это может быть вызвано COM-компонентом, вероятно, важно решить проблему с поставщиком, чтобы решить эту проблему.

Answer 4

Это произойдет, если ваш обработчик сгенерирует исключение.

Это также произойдет, если вы вызовете Environment.FailFast или если вы Abort поток пользовательского интерфейса.