BSOD. "Синие окна смерти" без мистики.

  • Автор:

BSOD-000.jpg

"Синие окна смерти" (BSOD) до сих пор являются для многих явлением весьма загадочным и даже мистическим. К сожалению, действия администраторов при появлении "синего окна" зачастую напоминают шаманские пляски с бубном, нежели осмысленную диагностику и устранение проблемы. Чем мы сегодня и займемся.

Онлайн-курс по устройству компьютерных сетей
На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.

Как обычно, начнем с теории. Чтобы успешно установить и устранить причину появления BSOD, нужно обладать определенным минимумом знаний, проливающих свет на природу этого явления. А для этого нам придется обратиться к внутреннему устройству операционной системы. 

Собственно BSOD есть ни что иное, как сообщение системы о критической ошибке, когда продолжение нормальной работы невозможно, произошедшей на уровне ядра ОС. Теперь самое время вспомнить, что архитектура NT, которая лежит в основе всех современных ОС семейства Windows, имеет модульную структуру и имеет два основных уровня: компоненты работающие в пользовательском режиме и компоненты работающие в режиме ядра.

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

В режиме ядра исполняются ключевые системные службы: собственно ядро ОС, менеджеры ввода-вывода, процессов, памяти и т.д., а также драйвера устройств. Любой процесс работающий в режиме ядра имеет неограниченный доступ к ресурсам и оборудованию и некорректная работа любого из них способна привести к краху всей системы.

Запомните: единственный доступный пользователю способ добавить новый код, работающий в режиме ядра, это установка драйвера. Также это реальный способ убить систему. Недаром разработчики уделили этому вопросу самое пристальное внимание и система выводит грозные предупреждения при попытке установить сомнительный драйвер (а то и вовсе блокирует его установку). 

Выделим основные причины критических сбоев:

  • Отказ оборудования. Одна из самых часто встречающихся причин, к ее разновидностям стоит отнести работу оборудования в нештатных режимах: разгон, перегрев и т.п. В ряде случаев к этому приводят неправильные настройки BIOS или ошибки в нем.
  • Ошибки в драйвере.  Занимают почетное второе место, особенно при использовании драйверов не имеющих WHQL подписи. Также сюда можно отнести ошибки вызванные приложениями устанавливающими в систему собственные драйвера: антивирусы, дисковые утилиты, программы для записи дисков и т.п. Чаще всего ошибки вызывают несовместимые версии данных приложений.
  • Изменение кода, работающего в режиме ядра. Это может быть как несанкционированное изменение, например заражение вирусами, так и вполне легальное: установка непроверенных обновлений и драйверов. 

Конечно, это очень упрощенная модель, но вполне достаточная для понимания причин сбоев и осмысленного подхода к их устранению. 

Перейдем от теории к практике. Увидеть классическое синее окно сегодня можно редко, только если сбой произошел при установке или на ранней стадии загрузки, в остальных случаях система самопроизвольно перезагружается.

Это происходит потому, что по умолчанию в современных ОС установлена опция "Выполнять автоматическую перезагрузку при отказе системы". В целях диагностики эту опцию рекомендуется снять. Для доступа к этим настройкам откройте Панель управления - Система - Дополнительные параметры системы - Загрузка и восстановление

BSOD-001.jpg

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

Итак, в один не очень прекрасный день ваш ПК встретил вас синим экраном. Что делать? Ни в коем случае не паниковать и не предпринимать необдуманных решений, даже если нужно в кратчайшие сроки восстановить работу системы.

Собственно синий экран уже содержит начальную техническую информацию о причинах сбоя, что позволяет тут-же приступить к диагностике и, в ряде случаев, успешно решить проблему не прибегая к другим методам анализа. 

Мы в нашей тестовой лаборатории воспроизвели ситуацию, приводящую к появлению BSOD на завершающем этапе загрузки и теперь попробуем провести диагностику проблемы. Рассмотрим "синий экран смерти" подробнее:

BSOD-002.jpg

Он довольно информативен и даже содержит общие сведения по устранению проблемы, однако нас должна интересовать секция технической информации, а именно: код ошибки и драйвер вызвавший ее. Код ошибки присутствует в обязательном порядке и указан после слова STOP, информация о драйвере в данном случае отсутствует. Далее ищем информацию об ошибке с данным кодом на TechNet, в нашем случае выясняем, что сбой происходит в драйвере ntfs.sys по причине того, что некое приложение пытается получить доступ к служебным записям NTFS. 

Если система автоматически перезагрузилась и вы не видели синего экрана, то следует изучить журнал Система, который обязательно будет содержать запись о данном событии и код ошибки.

BSOD-003.jpg

Сделаем небольшое отступление. В случаях, когда диагностика указывает на системный драйвер, то чаще всего он не является причиной сбоя, а истинным виновником может являться взаимодействующее с ним приложение или аппаратный сбой. Также если машина каждый раз падает в "синюю смерть" с различными кодами ошибок (систему установить не удается) причина отказа скорее всего аппаратная: разгон, перегрев, неисправность памяти.

Следующим шагом нужно установить, что является причиной отказа: системный драйвер или сторонний. Если система нормально грузится в обычном режиме, то причиной сбоев в большинстве случаев является сторонний драйвер или аппаратный отказ. Если загрузить систему не удается, делаем попытку загрузиться в безопасном режиме, если нам это удалось, то причина также лежит в сторонних драйверах, иначе - в системных. 

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

Наша система благополучно загрузилась в безопасный режим, следовательно причину следует искать в стороннем драйвере. Как это сделать? Проанализировать мини-дамп, который содержит информацию о всех загруженных в момент сбоя драйверах. Для анализа дампа мы советуем использовать утилиту BlueScreenView, которая весьма проста в использовании и достаточно информативна. Утилиту можно установить как на сбоящую систему, так и на любой другой ПК. В последнем случае потребуется скопировать дампы с нужного ПК и указать путь к ним.

Работа с утилитой очень проста. При запуске она автоматически ищет дампы в папке C:\Windows\Minidump, после чего в списке найденных дампов достаточно выбрать интересующий:

BSOD-004.jpg

Верхняя часть окна программы содержит список дампов с указанием кода и текста ошибки, а также драйвера причины. В нашем случае ничего нового, все тот-же ntfs.sys. А вот нижнее окно гораздо более интересно, особенно список драйверов выделенный розовым, это драйвера найденные в креш-стеке, т.е. любой из них может являться потенциальным виновником ошибки.

Подробное изучение данного списка позволило выявить предполагаемый драйвер-причину: klif.sys - единственный сторонний драйвер, относящийся к продукту Антивирус Касперского. Действительно, после его удаления, система смогла нормально загрузиться и в дальнейшем работала стабильно.

Справедливости ради отметим, что качество продуктов Лаборатории Касперского здесь не причем, мы сознательно использовали несовместимые версии: Антивирус Касперского для Windows File Servers 6.0.3.837 и Windows Server 2008 SP1.

Данная ситуация несколько раз встречалась в нашей практике: антивирус без проблем устанавливается на сервер, а синее окно смерти вызывает при следующей загрузке после обновления баз, учитывая что сервера перезагружают довольно редко (после установки антивируса перезагрузка не требуется) сопоставить факт установки антивируса с фактом сбоя бывает иногда проблематично.

 К сожалению, объем данной статьи не позволяет подробно разобрать все случай появления "синих окон смерти" и методов борьбы с ними, однако мы надеемся, что данный материал окажет практическую помощь и позволит осмысленно подойти к анализу и устранению причин сбоя. 

Онлайн-курс по устройству компьютерных сетей
На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.


Loading Comments