[450x360]
Нам не страшен синий BSOD: новые способы борьбы с голубым экраном смерти

15 июля 2008 | автор: Babs | Статьи | Просмотров: 672
Голубой экран смерти – это последний вздох системы, после которого душа отделяется от тела. В смысле, дамп памяти падает на диск, и компьютер уходит в перезагрузку, унося с собой все несохраненные данные. Вытащить систему из мира мертвых и взять ситуацию под свой контроль поможет термоядерный отладчик Syser. Пора брать этот инструмент на вооружение!

Голубой экран смерти – это последний вздох системы, после которого душа
отделяется от тела. В смысле, дамп памяти падает на диск, и компьютер уходит в
перезагрузку, унося с собой все несохраненные данные. Вытащить систему из мира
мертвых и взять ситуацию под свой контроль поможет термоядерный отладчик Syser.
Пора брать этот инструмент на вооружение!

Windows намного надежнее, чем это принято считать в народе. Моя основная
машина (на базе W2K) перезагружается не чаще двух раз в месяц, а файловый сервер
(и по совместительству – рабочая станция для цифрового монтажа, также
вращающаяся под W2K) бесперебойно проработал полгода и упал лишь из-за броска по
питанию, с которым не смог справиться UPS.

Голубые экраны смерти, вспыхивающие время от времени, отлавливаются SoftICE,
который мыщъх держит постоянно загруженным. В большинстве случаев он возвращает
систему к жизни. Это вопрос чести и хакерской этики. Перезагрузки – тривиальный,
но порочный путь. Каждый сбой компьютера, каждый глюк системы мыщъх воспринимает
чуть ли не как физическую боль и борется за здоровье машины, как за свое
собственное! И пускай меня сочтут ненормальным… главное – методики реанимации
системы, разработанные и обкатанные мной, могут принести пользу не только мне.
Итак, что нам понадобится?


* Windows Driver Kit (WDK) для всех систем по Vista включительно (www.microsoft.com/whdc/DevTools/)

* Windows Server 2003 SP1 DDK (www.microsoft.com/whdc/devtools/ddk/default.mspx)

* IA-32 Architecture Software Developer's Manual Vol. 3: System
Programming Guide (www.intel.com/products/processor/manuals/)

* Syser 1.95.19000.0894 (download.php)


По ту сторону BSOD'ов

Голубые экраны вспыхивают всякий раз, когда ядро сталкивается с ситуацией,
которую не может разрулить самостоятельно. Если не остановить некорректно
работающий код, завершив работу всех механизмов оси в аварийном режиме, ситуация
способна пустить систему в разнос. Это, кстати, кардинально отличает NT-подобные
системы от мира UNIX, впадающего в BSOD (kernel panic – в их терминологии)
только в хардкорных обстоятельствах (все остальное время они просто выгружают
порочный драйвер примерно так же, как NT завершает работу некорректно
работающего приложения).

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

Прежде, чем бросаться в бой, нужно отделить программные ошибки от аппаратных
отказов железа (как разогнанного, так и нет). Если голубые экраны вспыхивают в
случайное время, каждый раз отображая разные данные (да кто эти данные читает?),
то с большой вероятностью мы имеем дело с глюками железа. Пытаться реанимировать
компьютер при этом чрезвычайно опасно. Если содержимое оперативной памяти
разрушено из-за разгона или некачественного блока питания, то после выхода из BSOD'а операционная система попытается скинуть дисковые буфера. А там у нас что?
Правильно, – мусор. И дисковый том отправится к праотцам, что намного хуже, чем
потеря оперативных данных.

Впрочем, дефекты программного обеспечения тоже могут приводить к генерации «рандомных»
экранов голубой смерти. Следовательно, без полного анализа ситуации здесь не
обойтись. Однако не будем падать духом! Рано или поздно мы «объездим» ядро и
разберемся во всех тонкостях его организации, а пока ограничимся лишь общей
схемой.

Как устроен BSOD

Роль палача в NT-системах играет функция KeBugCheckEx, экспортируемая ядром и
вызываемая из сотен (если не тысяч!) мест с теми или иными параметрами. Что это
за параметры? Обратившись к NTDDK, мы узнаем, что функция KeBugCheckEx принимает
пять аргументов, первый из которых (BugCheckCode) содержит код ошибки, а четыре
следующих параметра – места/время/обстоятельства ее возникновения.

Перечень BugCheck-кодов можно найти в том же NTDDK. Там же содержится
описание четырех аргументов, специфичных для каждого BugCheck-кода, количество
которых чуть меньше сотни. Чтобы не держать в голове кучу ненужной информации,
рекомендуется распечатать документацию и всегда хранить ее под рукой.

BugCheck-коды можно разделить на две большие категории. Первая содержит адрес
инструкции, вызвавшей исключение (например, 1Eh: KMODE_EXCEPTION_NOT_HANDLED,
0Ah: IRQL_NOT_LESS_OR_EQUAL, 24h: NTFS_FILE_SYSTEM). Это позволяет «заглянуть»
отладчиком непосредственно на место аварии, исправить пробоину и, выйдя из
отладчика, продолжить плавание (естественно, для этого нужно не только знать
ассемблер, но и разбираться в тонкостях драйверостроения, но это – в идеале).

Другая категория BugCheck-кодов не содержит адреса дефективной инструкции,
поскольку ядро диагностирует аварийную ситуацию на поздней стадии. Найти
виновника в этих случаях затруднительно. Взять хотя бы такой BugCheck-код, как
C2h: BAD_POOL_CALLER. Он вызывается из функции распределения памяти,
обнаружившей, что память на конкретной измене, но кто ее разрушил и когда –
этого система сказать не может.

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