Всем доброго времени суток. Просто стало интересно. У каждого потока в системе есть свой дефолтный обработчик исключений (если, конечно, мы не сменили его на свой), который находится в конце списка EXCEPTION_REGISTRATION. Дефолтный обработчик, в отличии от наших, всегда обрабатывает исключения. Поэтому самое страшное, что мы можем узреть на мониторе - это БСОД . Теперь вопрос - а что произойдет, если система не найдет в списке EXCEPTION_REGISTRATION обработчик, который обработает исключение?..
очевидно, убьет процесс, если при этом процесс не освободил важные ресурсы, то и до голубого экрана недалеко.
Бред. Windows NT при завершении процесса всегда освобождает за ним все ресурсы, независимо от того, сделал ли он это сам или нет.
Теоретически - согласен, на практике мне удавалось, балуясь с SEH, из ринг3 систему в голубой экран ронять, за давностью не вспомню деталей, но такое было, возможно также, что прямой связи и не было...
masquer Вспомнишь как это делал, кинь мне код на мыло (не выкладывай на форуме). Возможно из этого можно извлечь пользу.
Последний из обработчиков (который ставит система) прибивает процесс. Если не один обработчик вобще не будет найден, то снова возникнет исключениие, и опять будет поиск обработчика... Процесс войдет в бесконечный цикл и будет 100% грузить процессор.
А откуда, собственно, уверенность, что KMODE_EXCEPTION_NOT_HANDLED генерируется нижним обработчиком, а не самой бегалкой по списку? Напомню, что в статье Пиетрека было только про юзермодные исключения.
Twister AFAIK, беготню по списку инициирует системный обработчик исключений, который сидит глубоко в ядре. Если список юзермодных обработчик окажется пустым (кстати, у меня сомнения, что такое вообще возможно, но допустим), то системный обработчик сам обработает исключение.
Twister Если под дефолтным обработчиком понимается unhandled exception filter, то он по-моему не хранится в списке обычных обработчиков. Кроме того он общий для всех потоков процесса.
Я тоже ронял систему из ring3 в синий экран, но это было когда я запускал прогу (кстати там SEH криво ставился) под отладчиком Delphi... А так прога вылетала просто на ура ))
Хотя нет. Это не все. Не знаю почему tyomitch сам не написал, но вот его опровержение словам ms-rema (usermode): Код (Text): xor eax,eax mov dword ptr fs:[eax], -1 mov byte ptr [eax], 0 Помирает тихо и беззвучно. Никакой 100% загрузки нет.
Twister Система проверяет чтобы адрес хендлера находился на стеке. Иначе кадр просто игнорируется. -1 не является валидным адресом, но прежде всего он не попадает в сегмент ss. Поэтому система делает вид будто обработчика нет вообще. Выполняется системный обработчик и прибивает процесс.
Twister Не вижу противоречий между словами Ms-Rem и примером с неправильным адресом обработчика. Возможно, Вы забываете, что обработчики есть в обоих кольцах. В Ring3 находится цепочка поточных обработчиков (адрес в [fs:0]) и финальный обработчик UnhandledExceptionFilter. Но есть ещё системные обработчики в ядре. Если присутствует отладчик, то он тоже участвует в процессе обработки исключений. Вы внимательно читали Win32™ SEH изнутри?
