BSOD, или «Синий Экран Смерти» — cколько несохраненных документов, неотправленных сообщений и почти пройденных игровых боссов кануло в небытие по его милости?
Современный облик BSOD (кстати, с лета 2025 года — без грустного смайлика и QR-кода) — лишь последняя итерация долгой эволюции. Почему он синий, в какой версии Windows появился, бывают ли экраны смерти другого цвета — об этом поговорим в сегодняшней статье.
Кто его создал и почему он синий
Долгое время автором BSOD называли то Стива Балмера, то Джона Верта, то Рэймонда Чена. Последний не так давно внес ясность в этот вопрос в своем блоге.
По словам Чена, есть три разных экрана синего цвета, и у каждого из них свой автор.
Во-первых, это так называемый «Синий Экран Несчастья» (blue screen of unhappiness). Автором текста на нем (именно появляющегося сообщения, не кода) действительно является Стив Балмер.
Еще один экран — ошибка ядра Windows 95, которую условно можно считать «синим экраном смерти». Поскольку Windows 95 позволяет пользователю проигнорировать эту ошибку — как минимум, в теории — считать настоящей смертью это нельзя. Именно Чен был тем, кто довел эту версию сообщения об ошибке синего экрана ядра Windows 95 до ее окончательного вида.
И, наконец, настоящий BSOD — ошибка ядра Windows NT. Ее автором Чен называет Джона Верта.
Хорошо, с авторством мы, вроде бы, разобрались. Теперь давайте ответим на следующий животрепещущий вопрос — почему BSOD все-таки синий? Всегда ли он таким был?
Ответ, как это часто бывает, до смешного прагматичен. Романтичные байки о волшебном успокаивающем эффекте синего цвета или якобы строгом следовании брендбуку Microsoft разбиваются о суровую реальность разработки софта того времени.
На этот вопрос нам ответит Дэйв Пламмер, бывший инженер Microsoft. Как он объяснил в одном из роликов на своем YouTube-канале, Джон Верт, тот самый отец BSOD, выбрал комбинацию белого текста на синем фоне по одной простой причине — ему просто так было удобно.
В то время Джон использовал машину на базе MIPS RISC, где использовалась именно такая цветовая палитра — белый текст на синем фоне. Более того, его любимый редактор кода, SlickEdit, тоже по умолчанию отображал все белым на синем. Получилась идеальная, хоть и непреднамеренная, унификация. Можно было загружаться, писать код и наблюдать падение ОС в одной и той же привычной глазу цветовой гамме. Кстати, в том ролике Пламмер поделился и чуть более важной технической информацией — в чем же основная причина появления этих экранов? Ответ вы наверняка и без нас знаете: подавляющее большинство BSOD вызываются ошибками, связанными с драйверами.
Эволюция краха
Многие ошибочно полагают, что «Синий Экран Смерти» появился вместе с самой Windows. Но это не так. Да и синим он был не всегда.
Пользователи самой первой версии Windows могли увидеть синий экран с ошибкой, но это было совсем не то явление, к которому мы привыкли. Вместо внятного сообщения был лишь лишь хаотичный набор символов, появлявшихся, предположительно, из ОЗУ, после чего все зависало и помогала лишь перезагрузка.
С выходом Windows 3.0 ситуация немного изменилась. Появились сообщения об ошибках на синем фоне, но, как вы уже знаете, это могли быть и не фатальные ошибки — скорее уведомления, после которого можно было продолжить работу. А вот по-настоящему серьезный сбой приводил к появлению «Черного Экрана Смерти» (Black Screen of Death) с текстом вроде: «Не удается продолжить работу Windows из-за…».
Точно сказать, кто первый произнёс фразу «Blue Screen of Death», уже сложно. Согласно архивам, термин «Black Screen of Death» впервые можно увидеть в журнале Computerworld за 1993 год, а первое задокументированное упоминание «Blue Screen of Death» — в книге «PC Roadkill» 1995-го. Тем не менее, к концу 90-х это выражение уже прочно вошло в лексикон всех, кто имел дело с ПК.
NT против «девяток»
Здесь важно провести грань между двумя параллельно развивавшимися ветками Windows — профессиональной NT и домашней 9x (95, 98).
Настоящий BSOD родился в 1993 году в Windows NT 3.1, и его создателем, как мы уже знаем, был Джон Верт. Этот экран был именно что «смертью» — он останавливал систему полностью, чтобы защитить целостность ядра и данных.
А вот в «синий экран» в Windows 95/98 сам Чен называет «Синим экраном хромоты» (blue screen of lameness). Если в «домашней» Windows падал драйвер, система показывала синий экран с ошибкой, но... позволяла нажать Ctrl+Alt+Delete и либо завершить сбойную задачу, либо перезагрузиться. Система не умирала, она именно что хромала, но могла кое-как идти дальше. Хотя бы в теории. Как вспоминает Чен, изначально на экране красовалась обнадеживающая надпись: «Возможно, получится продолжить работу в нормальном режиме». Однако впоследствии от этого пункта решили отказаться, сочтя его чересчур оптимистичным.
«Девятки» славились своей нестабильностью, но настоящим чемпионом по количеству падений стала, пожалуй, Windows ME, где BSOD порой становился настолько навязчивым, что единственным лекарством оказывалась лишь чистая переустановка с неизбежной потерей всех данных.
А вот вам забавная история об этой нестабильности. Итак, 20 апреля 1998 года. В этот день на выставке COMDEX сам Билл Гейтс демонстрировал публике технологию Plug and Play в новенькой Windows 98. В самый ключевой момент, когда его помощник подключил к компьютеру сканер, система незамедлительно ответила — тем самым фатальным синим экраном. Гейтс разрядил ситуацию шуткой: «Должно быть, именно поэтому мы пока и не продаем Windows 98».
А вот у линейки NT BSOD был не только более впечатляющим, но и более информативным. На экране можно было увидеть подробное описание ошибки.
Эпоха стабильности и грустные смайлики
Пройдя через хаос 90-х с его двумя разными «смертями», история BSOD, наконец, вышла на прямую и предсказуемую дорогу. С выходом Windows 2000 Microsoft объединила профессиональную и домашнюю линии. Исчезла не только путаница с брендингом NT, но и «двойственная природа» синих экранов.
Следующее десятилетие стало для BSOD эрой затишья. С Windows 2000 вплоть до Windows 7 его облик почти не менялся.
Это был тот самый классический, аскетичный экран с белым моноширинным шрифтом на ультрамариновом фоне, заставший расцвет домашних ПК.
Новый этап эволюции начался с приходом Windows 8. В погоне за современным дружелюбным дизайном Microsoft решила смягчить и свой образ «цифрового жнеца». Голубой фон стал светлее — ближе к лазурному, а устрашающая стена технического текста уступила место грустному смайлику и лаконичной надписи: «Ваш ПК столкнулся с проблемой, которую невозможно решить, теперь его нужно перезагрузить».
В Windows 10 Microsoft добавила на экран QR-код.
Логика Microsoft была ясна — для рядового пользователя QR-код, ведущий на страницу поддержки, был куда полезнее, чем загадочный код STOP: 0x0000007B.
Современный BSOD, каким мы его знаем в Windows 10 и 11, продолжает эволюционировать. В Windows 11 его сначала перекрасили в черный, затем вернули привычный лазурный, а летом этого года BSOD еще раз поменял цвет, но потерял грустный смайлик и QR-код.
Разнообразная палитра BSOD
Синий — не единственный «траурный» цвет в палитре Windows. Еще на заре эпохи Windows 98 система могла сигнализировать о критических проблемах ACPI куда более грозным «Красным Экраном Смерти». Эта традиция не была забыта и в будущем — в бета-версиях Windows Vista (тогда носившей кодовое имя Longhorn) загрузчик также выводил сообщения о фатальных ошибках на пугающем красном фоне.
А смельчаки, тестирующие инсайдер-сборки, наверняка знакомы с его зеленым братом-близнецом — Green Screen of Death, сигнализирующем о сбое в непроверенной версии ОС.
И если вам вдруг захочется почувствовать себя повелителем хаоса, вы можете вполне легально можете вызвать BSOD с помощью утилиты NotMyFault от Microsoft. Главное — помните, с какой великой историей вы имеете дело, нажимая на кнопку.
Комментарии (23)
Sfinx88
07.10.2025 21:30Мне кажется, идеальным экраном смерти был именно тот самый от XP, информация выводимая им, действительно была полезна. С другой стороны, QR, ведущий на сайт с более подробной статьей о причинах ошибки был бы отличным дополнением. К сожалению, такой редакции так и не появилось...
john1
07.10.2025 21:30В какой-то из старых версий Windows (в районе до 95-го включительно) на синем экране показывали имя библиотеки и имя процедуры, где возник BSOD, а потом это убрали, заставив пользователя самому как-то доставать эти дампы и скармливать их анализаторам.
Vsevo10d
07.10.2025 21:30Объясните мне, непродвинутому пользователю ПК, каким образом помогала информация на самом БСОДе, сколько себя помню, с нулевых, на ПК и тем более ноутах после отрисовки БСОДа комп уходил в ребут в течение 0,5 - 3-х секунд, за которые даже код ошибки невозможно было успеть прочитать, а тут пишут про "более информативный" экран у NT.
Voldemaar
07.10.2025 21:30Создать файл 1.reg с содержимым (ниже), двойной клик по нему.
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl] "AutoReboot"=dword:00000000
xpadd93
07.10.2025 21:301) Панель управления\Все элементы панели управления\Система
2) Вкладка "Дополнительно" из окно "Свойства системы"
3) Нажать кнопку "Параметры..." из "Загрузка и восстановление
4) Убрать галочку "Выполнить автоматическую перезагрузку".
У меня Windows 7.
hssergey
07.10.2025 21:30В русифицированной XP надписи по задумке должны были выводиться на русском. Но дальше видимо что-то пошло не так, русский шрифт не добавили и на синем экране выводились "кракозябры", где читаемым был только код ошибки. Для непосвященного это выглядело еще более устрашающе...
xpadd93
07.10.2025 21:30Начиная с Windows 8 другой синий экран смерти - это вообще мне не понравится, зачем глупостью ставить огромный ":(", куда делся проблема строка STOP: и файл.
Аналогично Windows 10 синий экран смерти- зачем добавить "Япошкин код QR-код", нет смысл тратить время пользовать смартфоне. Лучше бы подробнее информации из сайт в синий экране смерти.
Тоже самое Windows 11 цвет фон - вредить глаза из-за черный фон с белый текст.
Поэтому Windows XP и 7 - все ясно и подробная техническая проблема, удобно интерфейс, чем залезь в просмотр событий.
zatim
Черный экран смерти - это, по сути, не экран смерти, а просто выход в дос.
ermouth
Не знаю как сейчас, но раньше бсод обратно в реальный режим процессор не переводил. Это, вообще говоря, нетривиальная задача.
zatim
pfemidi
Не знаю как сейчас, но раньше перевести процессор из защищённого режима обратно в реальный была задача более чем тривиальная.
medstrax
В общем случае это нетривиально. Предположим, вы можете выполнить произвольный код в 64-битном режиме в ринг-0. И вы ничего не знаете про ОС. Без знания мапинга линейных адресов на физические вернуться в реалмод не получится. А получить его без использования сервисов ОС мягко говоря проблематично.
sappience
Каждый раз завершая Doom (который выполнялся под экстендером DOS4GW Pro) вы выходили из Protected Mode в Real Mode (или в Virtual Mode если у вас в CONFIG.SYS грузился QEMM386). Значит и виндоуз бы справился.
ermouth
Всё верно, но сравнение имхо некорректное. Если проводить аналогии, надо было бы писáть «каждый раз когда крашится сам DOS4GW Pro, вы выходили в риал мод».
DOS4GW Pro в этом случае брал на себя функции ОС, а мы как раз рассматриваем случай, когда крякнула именно сама ОС, а не приложение, которое ей управляется.
pfemidi
Ну да, это не совсем тривиально, но вполне возможно. Конечно обычный "программист на C#", а тем более "программист 1C" или того хуже "программист на JavaScript" или "программист на Python" это не сделает, но тот кто хотя бы умеет писать драйвера [для Windows или модули для Linux] вполне это осилит. Это раз уж мы говорим про процессоры x86/x64 и про т.н. "IBM PC Compatible" компьютеры. OS тут вообще никаким боком. Находясь на кольце #0 можно без проблем прочитать все необходимые page registers, все GDT, IDT и прочую кухню. Исходя из этого определить маппинг линейных адресов на физические становится очень даже возможным. Далее запрещаем прерывания, перезагружаем GDT и IDT, перезагружаем всё что относится к табличной адресации, заодно выключая её нафиг, загружаем в сегментные регистры корректные дескрипторы для real mode, сбрасываем младший бит в регистре CR0 для выключение protected mode и включения real mode, делаем длинный jmp для сброса кеша инструкций, разрешаем прерывания и вуаля, мы в обычно реальном режиме как после сброса.
Во времена 286 сбрасывать бит PE было невозможно -- регистра CR0 не существовало, а через lmsw/smsw это бит можно было только взвести для перехода из реального в защищённый, но сбросить никак. Поэтому приходилось делать аппаратный сброс процессора записью 0xFE в порт 0x64, предварительно записав в BDA (BIOS Data Area) по адресу 0x40:0x67 адрес куда процессор должен перейти после сброса вместо обычного для него цикла POST. А начиная с 386 у CPU появился CR0 в котором запросто можно было сбросить бит PE.
Как тут уже заметили DOS4GW это делал. И Phar Lap DOS Extender это делал. Даже досовский драйвер HIMEM.SYS это прекрасно умел делать.
Я со всем этим столкнулся впервые ещё на 286 (real mode/protected mode) в конце 80-х прошлого века, после уже на 386 и 486 (real mode/protected mode/v86 mode). Вот начиная с пентиумов у меня появилась другая работа и другие интересы и необходимость в подобном отпала. Поэтому с режимом SMM не сталкивался и знаю про него только понаслышке.
medstrax
В реальном режиме страничное преобразование отключено, следовательно перед возвратом в реальный режим надо настроить тождественное преобразование линейных адресов в физические. А это без помощи ОС (почти) невозможно. Мы не можем изменить существующие таблицы страниц, т.к. в CR3 физический адрес и неизвестно какие линейные адреса ему соответствуют (и есть ли такие вообще). Не можем узнать диапазоны адресов с тождественным преобразованием, т.к. не можем прочитать таблицы страниц. И мы не можем создать новые таблицы страниц ровно по той же причине - надо писать по физическим адресам, а мы можем только по линейным.
pfemidi
Да почему же не можем прочитать? Мы же на нулевом кольце, поэтому что хотим то и читаем. Это раз. А два это то, что мы ведь всё ещё говорим про BSOD, да? А это, сюрприз, дело рук не какой-нибудь малвари, которая "ничего не знает про OS", а дело рук самой OS. Так что этим переходом из защищённого режима в реальный будет заниматься не mycoolprog.exe от абстрактного хакера j0hN $MiTh, а абстрактная функция NtOsLeaveProtectedMode где-то в недрах ядра OS, которая по дизайну будет иметь доступ ко всем internal таблицам и функциям этой самой OS. И обладая всей этой информацией эта функция прекрасно воссоздаст все необходимые вещи, включая пресловутый маппинг линейных адресов на физические.
Другое дело что эта функция не написана разработчиками ядра (хотя и могла быть написана). А вот почему она не написана -- "Впрочем, это уже совсем другая история" (C) Каневский.
medstrax
Пример. Мы хотим после переключения в реальный режим продолжить выполнение с адреса 0х10000. Ок, для простоты - mov ebx,10000h xor eax,eax mov cr0,eax jmp ebx (дескрипторы сегментов останутся старые, ну и ладно). Для этого нам надо по физическому адресу 0х10000 поместить какой-то свой код реального режима. Как это сделать в нулевом кольце в общем случае из защищенного режима при CR0.PG = 1? Никак. Для этого нужно знать линейный адрес, который отображается на физический 0х10000 (если такое отображение существует). Для этого надо прочитать таблицы страниц. Для этого надо узнать какой линейный адрес соответствует физическому адресу в CR3. Для этого надо прочитать таблицы страниц... Ну вы поняли. Без помощи ОС или хитрых трюков не обойтись.
pfemidi
Помощь OS как раз в виде [несуществующей в реале, но вполне возможной] функции NtOsLeaveProtectedMode.
И хитрые трюки тоже вполне возможны. Другое дело что это никому не надо -- какой смысл выходить в том же Windows в реальный режим? В чём сермяжная правда от этого? В чём цимес? Лично я не могу придумать никакой реальной пользы от этого.
medstrax
Один из известных трюков для работы с физической памятью, не используя сервисы ОС - отключить на время страничное преобразование (предположим, что мы в самом простом 32-битном режиме с 4-Кб страницами).
Для этого надо узнать физический адрес текущей страницы кода. Потом
mov ebx, <физический адрес нужной команды в текущей странице>
mov eax, cr0
and eax,07FFFFFFFh
mov cr0,eax
jmp ebx
(сама команда jmp ebx выбирается с еще включенным страничным преобразованием, хотя и после его отключения mov cr0,eax - это не баг, а фича).
А физический адрес можно узнать, меняя базовый адрес Local APIC с шагом 4 Кб, не путать с К&Б) и читая после модификации текущую страницу.
Как только какие-то известные значения в текущей странице перестают быть таковыми - значит мы записали в Local APIC физический адрес текущей страницы.
Правда, надо еще кэш отключать, т.к. выполнение кода из кэшируемой памяти, на которую отображен Local APIC может привести к #MC.
medstrax
Да, при модификации базового адреса Local APIC еще надо учитывать, что с некоторых пор Intel запретил перекрытие адресов Local APIC и SMRAM, если SMRR регистры включены - при попытке записать адрес из диапазона в SMRR в IA32_APIC_BASE будет #GP
ermouth
Если page fault in non paged area произошёл на этапе «что хотим то и читаем», каковы дальнейшие действия ОС должна предпринять по-вашему? Вместо bsod что должно произойти?