Синий экран появляется всякий раз,
Синий экран появляется всякий раз, когда ядро возбуждает необрабатываемое исключение (скажем, обращение по нулевому указателю) или отлавливает заведомо "левую" операцию (повторное освобождение уже освобожденной памяти, например). А что делает Жирный Хомяк (он же Системный Администратор), когда видит BSOD? Быстро шепчет заклинание: "Память-видюха-драйвер, на фиг идите от компа, уроды, буду разбираться!".
Во всех этих случаях управление передается функции KeBugCheckEx, описание которой можно найти в NT DDK, и которая завершает работу системы в аварийном режиме, при необходимости сбрасывая дамп памяти, поковырявшись в котором, можно определить причину сбоя.
Функция KeBugCheckEx принимает четыре аргумента, важнейшим из которых является BugCheckCode, определяющий причину сбоя. Всего существует свыше сотни кодов ошибок, документированных в DDK (ищите их в руководстве по отладчику "Using Microsoft Debugger"), однако, в действительности их намного больше. Дизассемблирование ядра W2K SP2 показывает, что KeBugCheckEx вызывается из 387 мест! И, преимущественно, с различными параметрами.
Разумеется, не все ошибки одинаковы по своей фатальности. В многоядерных осях это вообще не проблема. Падение одного ядра, не затрагивает других. Все ядра работают в раздельных адресных пространствах и частично или полностью изолированы друг от друга. Разрушать такую систему очень трудно, многоядерная архитектура чрезвычайно устойчива к сбоям, но… как же при этом она тормозит! Межъядерный обмен съедает уйму процессорного времени, а если запихать все компоненты в одно ядро, мы получим… монолитное ядро по типу LINUX'а (что, кстати говоря, явилось причиной яростной критики последнего со стороны многих теоретиков). В LINUX, как впрочем, и в BSD все компоненты ядра (там они называются модулями) исполняются в едином адресном пространстве и некорректно написанный модуль может непреднамеренно или умышленно надругаться над чужой собственностью (превратить данные в винегрет, например).
Это факт! Однако, при возникновении необрабатываемого исключения в ядре (например, обращения по нулевому указателю), LINUX "грохает" только тот модуль, который это исключение и породил, не трогая все остальные. Аварийный останов системы происходит только по серьезному поводу, когда рушится что-то очень фундаментальное, делающее дальнейшую работу ядра действительно невозможной. Конечно, если "полетел" драйвер жесткого диска — это кранты, но вот, например, без драйвера звуковой карты можно какое-то время и обойтись, сохранив все не сохраненные данные и только потом перезагрузившись.
Операционные системы семейства NT используют гибридную архитектуру, сочетающую сильные стороны монолитных и микро-ядер (так же называемую "архитектурой модифицированного микроядра"), что теоретически, должно обеспечить превосходство над монолитным LINUX'ом (кстати говоря, экспериментальное ядро GNU/HURD построено как раз по микроядерной архитектуре). Легендарно устойчивую NT/XP, которую по слухам можно "уронить" только вместе с сервером, на самом деле очень легко вогнать в голубой экран. Достаточно любому, я повторяю любому, драйверу сделать что-то недозволенное, как система автоматически катапультирует пользователя, заботясь о нем. Хорошо, что Microsoft не строит авиалайнеры!
