Исключения, которые не могут быть захвачены блоком try-catch в коде приложения

Ответ 1

Да, есть и другие:

• Исключение ThreadAbortedException является особенным. Он всегда будет повторно поднят при попадании, если блок catch не вызовет ResetAbort(). Он полностью несовместим, когда CLR выполняет грубую отмену потока. Выполнено, когда AppDomain выгружается, например, обычно при выходе из программы.

• Любые нативные исключения, вызванные неуправляемым кодом в потоке, который начался с помощью собственного кода, несовместимы. Общий сценарий здесь - это COM-компоненты, которые запускают собственные потоки. CLR не имеет возможности ловить такие исключения, он не знает о потоке и не может внедрить блок catch. Если собственный код не обнаруживает исключения, то Windows завершает процесс.

• Любые исключения, отбрасываемые финализаторами, если они не являются критическими финализаторами. Они прервут поток финализатора, который завершает процесс.

• Начиная с .NET 4.0 исключение ExecutionEngineException невозможно. Он вызывается CLR, когда он обнаруживает, что его внутренние структуры данных скомпрометированы. Как правило, с помощью исключения AccessViolationException, которое возникает, когда сборщик мусора занят. Продолжение выполнения управляемого кода при компрометации GC-кучи является рискованным предложением и пригодным для использования,.NET 4 полностью вытащил плагин.

• Начиная с версии CLR.NET 4.0, но, возможно, также присутствуя в неуправляемом коде, с которым вы взаимодействуете в более ранних версиях, Microsoft Secure CRT может немедленно завершить работу программы при обнаружении проблемы безопасности. На самом деле это не исключение из-под капота, процесс мгновенно прекращается, поскольку код считает процесс скомпрометированным и не способен безопасно обрабатывать исключения. Общим случаем является то, что кадр стека нативной функции разбит, общая проблема в собственном коде и используется вирусным кодом для возиться с обратным адресом для запуска произвольного кода. Сценарий атаки, называемый "переполнение буфера стека". В коде CLR было несколько ложных тревог, в начале после выпуска .NET 4.0, но я не видел их довольно долго. Вы можете вызвать такое прерывание самостоятельно, написав за пределами стекаalloc.

• Довольно печально, исключения, обработанные обработчиками сообщений Windows при запуске кода в 32-битном режиме на уровне эмуляции WOW64 в 64-разрядной операционной системе, и у вас есть отладчик. Лучше всего известно о трудном событии Load в Winforms, но также присутствует для других сообщений и в других средах исполнения. Уродливые детали находятся в этом ответе.

• Начиная с .NET 4.5, исключения, которые Microsoft классифицирует как поврежденные исключения состояний (CSE). Их можно поймать, но это должно выполняться только обработчиком исключений верхнего уровня, который ничего не делает, кроме генерации диагностики для пользы пользователя и безоговорочно прекращает приложение. Backgrounder доступен в этой статье в журнале.

• Любое исключение, вызванное дрожанием до того, как ваш код может начать работать, не может быть обнаружен или зарегистрирован. Невозможность скомпилировать ваш метод Main() - это обычный случай, обычно это исключение FileNotFoundException.