Черный экран смерти

Проблемы различных этапов загрузки операционной системы Windows довольно широко распространены и нашли своё отражение в большом количестве разнообразных ошибок, возникающих при выполнении кода из секторов MBR/PBR, модулей Bootmgr, Winload, Ntoskrnl, SMSS, Csrss, Winlogon, Userinit и драйверов/сервисов (стартующих на этапах запуска), одним словом, всех тех компонентов, которые участвуют в процессе загрузки операционной системы. Не так давно в своей практике я очередной раз столкнулся с одной из подобных проблем и решил написать себе небольшую шпаргалку, поскольку всегда хотел как-то систематизировать подобного рода ошибки, и с чего то надо было определенно начинать. Из всего множества сбоев, возникающих на этапе загрузки Windows, хотелось бы отдельно отметить ошибки, называемые пользователями Черным экраном смерти.

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

Поэтому, давайте для начала классифицируем сбои по времени возникновения:

1. Черный экран, "возникающий" после нажатия кнопки (включения) компьютера, фактически после старта на экране вообще не появляется изображения. Причинами возникновения являются аппаратные проблемы. В данном материале пока не рассматриваются.
2. Черный экран, возникающий [при классической схеме загрузки] на этапе загрузки/функционирования кода секторов Master Boot Record (MBR) и Partition Boot Record (PBR), появляется когда код BIOS не может загрузить сектор с диска и не выводит на экран никаких диагностических сообщений. Появляется после процедуры POST (заставки производителя материнской платы или тестовых сообщений об оборудовании). Курсор не отображается. При нажатии на клавиши слышен звуковой сигнал.
3. Черный экран, возникающий до отображения экрана приветствия (логотип/строка Запуск Windows) Windows (Bootscreen). Отображается аппаратный (текстовый) курсор.
4. Черный экран, возникающий после отображения экрана приветствия (логотип/строка Запуск Windows) Windows (Bootscreen). Отображается графический курсор мыши (поскольку режим работы видеоадаптера меняется на графический).
5. Черный экран, возникающий во время штатного функционирования операционной системы Windows. Выражается во внезапном пропадании сигнала от графического адаптера, соответственно на мониторе мы не видим ничего. Источником, обычно, являются сбои в работе аппаратной/программной частей видеоадаптера. В данном материале пока не рассматриваются.

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

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

Конечно же, в очередной раз не перестаю удивляться терпению разработчиков, уже на протяжении 20 с лишним лет упорно игнорирующих хорошо известные общественности проблемы. Черный экран смерти, наряду с зеркальной проблемой в безопасном режиме - зависанием на classpnp.sys, а так же штормом прерываний, является примером недоработок в архитектуре системы Windows 7, вероятно базирующихся на недостатках архитектуры x86. Имеются подозрения, что система обработки ошибок в различных модулях содержит недоработки, не предусматривающие информирование пользователя о проблеме на приемлемом уровне, вместо этого происходит "тихий" останов/зацикливание/ожидание, формируя отказ в загрузке модулей следующего этапа, результатом чего является черный экран смерти, который (в штатном режиме) должен являться всего-лишь переходом от окончания одной стадии к началу другой. Ну если, предположим, имеются проблемы с чтением информации с жесткого диска, то есть физическое повреждение поверхности/ячеек памяти, ну поставь ты таймаут с ожиданием событий, при достижении которого на экран будет выведена надпись о невозможности чтения с носителя. Нет, проще стоять стучать жестким диском и показывать пользователю черный экран, мол догадайся сам.

Теория

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

• (для классической схемы загрузки) Отказы на этапах загрузки/работы кода секторов MBR/PBR;
• Невозможность загрузки драйверов (этапов BOOT_START и SYSTEM_START);
• Повреждение данных реестра;
• Отказ в запуске критически-важных сервисов/служб;
• Отказ в доступе к объектам файловой системы (каталоги/файлы);
• Повреждение исполняемых образов (файлов) критически-важных драйверов/служб;
• Битая/подмененная пользовательская оболочка (проводник);
• Ошибки при загрузке пользовательской темы оформления;
• Некоторые аппаратные проблемы видеоадаптера;

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

• экран заполняется голубым фоном, в преддверии вывода запроса на авторизацию в системе (для входа в систему нажмите клавиши Ctrl+Alt+Del). Я так понимаю, мы находимся в этом случае где-то в контексте logonui.exe, призванного отрисовывать экран перед вводом учетных данных, либо winlogon.exe, выполняющего авторизацию пользователя в системе. Возможно, спустя еще некоторое количество времени мы бы увидели сам запрос, тем не менее нарушены все временные рамки запуска.
• операционная система уходила в перезагрузку. То есть после черного экрана смерти выпадает в синий экран смерти, соответственно при настройках по умолчанию (автоматическая перезагрузка) мы синего экрана как такового увидеть не успеваем. В этом случае, при должных настройках аварийного дампа, мы получаем (полный/сокращенный) дамп ядра для последующего анализа.

Этап загрузки/работы секторов mbr/pbr

На данном этапе черный экран смерти вызван невозможностью загрузки кодом BIOS/UEFI сектора MBR при классической (legacy) схеме загрузки. Встречается как в старых реализациях BIOS (где загрузка происходит по схеме MBR -> PBR -> Bootmgr -> ...), так и в новых UEFI (в которых напрямую грузится bootmgr.efi). Возникает в реализациях микрокода, которые не информируют пользователя о каких-либо сбоях в процессе чтения/загрузки кода сектора MBR или файла bootmgr.efi. Так же может появляться в процессе выполнения кода MBR, когда управление передается на ROM/BASIC (int 18h), не реализованного в прошивке или некоторых проблем загрузки кода сектора PBR. Общая методика восстановления состоит [последовательном] запуске серии команд:

bootrec /scanos
bootrec /rebuildbcd
bootrec /fixmbr
bootrec /fixboot

Этап инициализации ядра ntoskrnl.exe

Если мы наблюдаем черный экран смерти с графическим курсором мыши, то обычно мы видим его после экрана приветствия (Windows Bootsplash, Bootscreen), показывающего нам анимированный логотип Windows (и строку "Запуск Windows"). На основании этого могу предположить, что мы находимся на этапе загрузки ntoskrnl.exe, в так называемой фазе 1. Состояние черного экрана смерти наступает на этом этапе по следующим причинам:

• Невозможность загрузки критических системных драйверов (флаг SYSTEM_START);
• Проблема с драйвером одной из системных шин. К примеру, довольно часто случаются проблемы с драйверами контроллеров IDE/SATA. По ряду причин драйвер не может загрузиться: отключен, испорчен либо вовсе отсутствует.
• Повреждение куста реестра (DEFAULT, SAM, SECURITY, SOFTWARE, одним словом любого куста кроме SYSTEM, поскольку последний отрабатывается ранее, на этапе работы модуля Winload).
• Невозможность запуска системообразующих сервисов/служб;

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

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

Причина 1: повреждение куста реестра

Разработчики из Microsoft предоставляют техническим специалистам превосходное средство под названием DaRT (Diagnostics and Recovery Toolset), которое является наследником легендарного ERD Commander. У Microsoft есть продукт под названием Microsoft Desktop Optimization Pack (MDOP), представляющий собой набор инструментов для решения разнообразных административных задач, который распространяется по программе Software Assurance. Одним из компонентов MDOP является Microsoft Diagnostic and Recovery Toolset (DaRT). Не берусь утверждать что это лучшее средство восстановление из имеющихся в природе, для подобных выводов у меня слишком мало информации, однако мне оно определенно понравилось, поскольку имеет возможность (при загрузке с внешнего носителя) подцеплять различные функциональные части системы с основного системного носителя (HDD/SSD) и работать с ними как с нативными, сохраняя иллюзию работы в диагностируемой операционной системе как в "активной".
Поскольку самостоятельно система не загружается ни в одном из режимов, мы вынуждены воспользоваться MS DaRT на внешнем носителе и загрузиться с него. После окончания загрузки и прохождения первичных этапов настройки, мы попадаем в окно Параметры восстановления системы, выбираем пункт Microsoft Diagnostics and Recovery Toolset. В открывшемся окне запускаем оснастку Управление компьютером, после запуска которой, в левом фрейме, выбираем пункт дерева Просмотр событий и далее выделяем пункт Журналы Windows, а затем щелкаем по System. Как Вы уже могли заметить, это стандартная, знакомая практически всем, оснастка, при помощи которой мы традиционной подключаемся к системным логам.

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

То есть пользователь принудительно выключил станцию, не дождавшись завершения работы в штатном режиме. Почему? Нам предстоит выяснить далее. Затем удалось обнаружить последствия действий нашего "предприимчивого" пользователя, событие с кодом 5, источником Kernel-General, "куст реестра (файл) \SystemRoot\System32\Config\SOFTWARE был поврежден и восстановлен.":

Далее было обнаружено событие с кодом 7023, источником Service Control Manager и описанием "Не удается найти описание для идентификатора события 7023 из источника Service Control Manager. Вызывающий данное событие компонент не установлен на этом локальном компьютере или поврежден. Установите или восстановите компонент на локальном компьютере. Если событие возникло на другом компьютере, возможно, потребуется сохранить отображаемые сведения вместе с событием. К событию были добавлены следующие сведения: Установщик модулей Windows %%16405. Отсутствует специальный ресурс языкового стандарта для нужного сообщения":

А вот и ответ на вопрос "Почему?", видите в тексте описания фразу "Установщик модулей Windows %%16405"? Сдается мне, что в процессе завершения работы начали устанавливаться обновления, что значительно этот самый процесс и замедлило. Как выяснилось позже, пользователь очень спешил, поэтому с его стороны и было принято столь необдуманное решение по принудительному отключению питания. Я обычно не злобствую, но к слову сказать, "лечатся" такие товарищи достаточно легко: начиная от уведомления департамента безопасности и заканчивая констатацией потери всей/части информации, находящейся в профиле пользователя.
Далее по списку событий у нас располагаются множественные ошибки, указывающие на невозможность запуска различных служб и драйверов. Вот один из примеров:

в нем описывается событие с кодом 7026, источник Service Control Manager: "Сбой при загрузке драйвера(ов) перезагрузки или запуска системы: CProCtrl, ctxusbm, discache, eeCtrl, MpFilter, spldr, Wanarpv6".
На первый взгляд событие как событие, говорящее о невозможности загрузки нескольких критически-важных драйверов, но во мне оно родило некоторое количество вопросов. Давайте, для начала, посмотрим на то, что это за драйвера:

Меня озадачил драйвер spldr, поскольку он должен загружаться функцией OslLoadImage еще на стадии работы модуля Winload.exe, так как некоторые критические драйвера (в том числе и spldr) загружаются именно на данном этапе. Почему же тогда событие об ошибках загрузки этого драйвера попадает в логи от источника Service Control Manager (Диспетчер управления службами, SCM), ведь SCM стартует значительно позже, на этапе работы модуля Wininit? Могу предположить, что код функции OslLoadImage, который начинает загружать драйвера раннего этапа, в последствии становится либо частью SCM, либо просто все события по загрузке всех драйверов системы (не важно кем и на каком этапе) имеют в логах источник SCM. Но это, пока что, всего-лишь мое предположение.

Решение 1: восстановление реестра

Как Вы помните, одно из событий у нас указывает на повреждение куста реестра SOFTWARE. Однако, в описании к событию сказано, что код загрузки системы попытался самостоятельно восстановить куст, о чем нас и уведомляет следующая формулировка: "куст реестра (файл) \SystemRoot\System32\Config\SOFTWARE был поврежден и восстановлен". Возникает резонный вопрос: что значит восстановлен? Что, вот так вот прямо взят файл SOFTWARE, размещающийся в каталоге бэкапа \Windows\System32\config\regback\ и переписан в \Windows\System32\config\? Да, как выяснилось в ходе анализа, подобный алгоритм реализован в коде модулей средств восстановления. Тем не менее, хорошим выбором будет самостоятельное восстановление в ручном режиме. Для этого можно использовать как встроенную консоль восстановления, так и загрузочный носитель со средствами DaRT. Можно выполнить полное восстановление всех кустов реестра, благо сама процедура описана в статье о восстановлении реестра из консоли восстановления. После окончания процесса копирования файла закрываем консоль. Для этого можно нажать на значок закрытия окна, либо в командной строке набрать команду exit и вернуться в меню выбора параметров восстановления. Потом нажимаем кнопку Перезагрузка для инициирования процесса перезагрузки станции. После перезагрузки станции я увидел долгожданный графический экран приветствия, система благополучно загрузилась.

Причина 2: отказ в запуске служб

На протяжении существования операционных систем линейки Windows, время от времени встречаются отказы запуска, обусловленные невозможностью старта некоторых служб, (в основном) из-за ошибок установки пакетов обновлений безопасности и вирусной активностью.

Еще начиная с Windows XP общественностью были зафиксированы зависания на черных экранах смерти, связанные с отказом (или существенной задержкой) запуска некоторых ключевых системы служб. Подобных служб (к счастью) не так уж и много:

• Журнал событий Windows (eventlog);
• Модуль запуска процессов DCOM-сервера (DcomLaunch);
• Рабочая станция (LanmanWorkstation);
• Сервер (LanmanServer);
• Сопоставитель конечных точек RPC (RpcEptMapper);
• Удаленный вызов процедур (RPC) (RpcSs);
• Центр обновления Windows (wuauserv);
• Клиент групповой политики (gpsvc);
• Служба профилей пользователей (ProfSvc);

Поэтому хорошая практика заключается в том, чтобы проверить, стоят ли указанные службы в режиме запуска Автоматически (Start = 2) и содержат ли эти службы требуемые разрешения безопасности в реестре (для аккаунтов LocalService, NetworkService).
Тем не менее это лишь достаточно общий подход, помимо него существует и более детализированный рабочий алгоритм вычисления сбоящих служб (сервисов). Последний похожий инцидент у меня был связан со случаем, когда неквалифицированный пользователь (хотя по факту он являлся специалистом) произвел восстановление системы до последней контрольной точки прямо в сеансе, в котором агентом SCCM были установлены (и ждали применения при перезагрузке) обновления. После завершения восстановления станция ушла в перезагрузку, которая ожидаемо завершилась черным экраном смерти.

Решение 2: восстановление запуска служб

Для выполнения действий, описанный в данном разделе, следует загрузиться с внешнего носителя LiveCD (например MsDaRT). Затем запустить оснастку Управление компьютером и перво-наперво проанализировать Просмотр событий - Журналы Windows - Система. По характерным событиям ошибок в которых, стало очевидно, что имеются проблемы со следующими службами:

• Узел агента SMS
• Удаленное управление Configuration Manager
• Агент последовательности задач Configuration Manager
• Центр обновления Windows

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

Причина 3: сторонняя оболочка (проводник)

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

• На одной из последних стадий загрузки операционной системы модуль Winlogon.exe запускает модуль под названием Userinit.exe, который, в свою очередь, запускает скрипты стадии загрузки, а затем вызывает оболочку пользовательского интерфейса explorer.exe, более известную нам под именем Проводник. Как загрузчик скриптов, так и саму оболочку можно подменить через предусмотренный в системе механизм конфигурирования альтернативной оболочки и загрузчика (посредством специализированных ключей реестра).
• В системе имеется еще один механизм под названием параметры загрузки образов, позволяющий управлять различными аспектами загрузки любых исполняемых образов (исполняемых файлов), к коим, фактически, можно отнести все без исключения программы. Одной из особенностей данного механизма является возможность (при помощи специальных параметров) производить отладку любого исполняемого образа (программы), тем самым предваряя его запуск загрузкой стороннего приложения.

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

Решение 3: восстановление оболочки

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

• После появления черного экрана смерти попробовать несколько раз нажать комбинацию клавиш Ctrl + Alt + Del. Если нажатие прошло и высветился список, то запустить Диспетчер задач. В открывшемся окне выбираем вкладку Приложения, в нижней части окна жмем кнопку Новая задача. В открывшемся небольшом окошке, в строке ввода набираем explorer и нажимаем Ok. Таким образом мы собственноручно запустим проводник;
• Если предыдущий метод на сработал, то потребуется загрузиться с внешнего носителя, содержащего средства восстановления (MsDaRT или любой другой);

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

• HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

проверяем параметр Shell (сама оболочка), который должен содержать значение explorer.exe.
проверяем параметр Userinit (программы, загружаемые процессом Winlogon на этапе входа пользователя в систему), который должен содержать значение C:\Windows\system32\userinit.exe,. (!) Не забывайте добавлять символ "запятая" в конце пути.
Как Вы уже поняли, восстановление работоспособности, в данном случае, сводится к проверке наличия сторонних записей в приведенных выше ключах реестра и (в случае необходимости) восстановлении указанных значений по умолчанию. После внесения изменений в ключи реестра, потребуется выполнить перезагрузку операционной системы.

Решение 3: Очистка параметров загрузки образов

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

• HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options;
• HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Image File Execution Options;

Указанные разделы содержат подключи, содержащие имена загружаемых образов, которые, в свою очередь, содержат параметры, описывающие разнообразные опции для запуска той или иной программы. Таким образом, при злонамеренной эксплуатации данного механизма по отношению к проводнику, возможна первичная загрузка левого кода, которая может привести к последующей некорректной работе или вовсе отказу проводника. Проще говоря, если присутствует ключ с именем explorer.exe, и в нем созданы какие либо параметры (например Debugger типа REG_SZ и значением, указывающим на запускной файл), то каждый раз при попытке запуска проводника будет запускаться и указанное стороннее приложение. Если вы обнаружили в описанных выше ветках реестра ключ explorer.exe - удаляйте его.

Метод 4: анализ дампов

Однажды я на довольно продолжительное время оставил включенной станцию, страдающую черным экраном смерти. Все идеи по восстановлению к тому моменту уже давно кончились и машина просто использовалась в качестве экспериментального стенда, монитор на котором был постоянно включен. Через пару часов "подвисания" станция вдруг самопроизвольно перезагрузилась. Неожиданно!! Поскольку по умолчанию в системе Windows 7 стоит перезагрузка при возникновении синего экрана смерти, можно было предположить что именно это со станцией и произошло. После загрузки с LiveCD предположение подтвердилось, в системе присутствовал свежий дамп-файл (MEMORY.DMP), который был незамедлительно скопирован и проанализирован. Как оказалось, произошла ошибка STOP 0x0000009F (DRIVER_POWER_STATE_FAILURE), причиной которой был один из драйверов, устройство которого находилось в некорректном состоянии питания. Этот случай натолкнул меня на мысль, что можно использовать файлы дампов для диагностики черного экрана смерти. Поэтому здесь мы опишем несколько подходов к использованию дампов.

поиск существующих дампов

• загружаемся с LiveCD;
• определяем диск/раздел (букву, литеру), на котором размещается сбойная операционная система;
• на найденном разделе производим поиск по шаблону *.*dmp. под данный шаблон попадают все без исключения дампы: полные/неполные дампы ядра/системы, дампы процессов служб и пользовательских приложений и прочие;
• наше внимание сосредоточено на дампах, дата создания которых после возникновения черного экрана смерти. расчет здесь довольно простой: если система находится на стадии загрузки, когда уже работает система WER, то мы получаем дампы падения системных приложений (служб/сервисов), по которым мы имеем возможность определить не только что именно падает, но и почему.
• найденные таким образом дампы (файлы с расширениями .dmp, .hdmp, .mdmp) анализируем посредством отладчика WinDbg;

получение нового дампа

• настраиваем поломанную систему на полный дамп памяти. Сделать это можно через LiveCD и правку реестра;
• после перезагрузки и появления черного экрана, дожидаемся перезагрузки (если произойдет);
• если произошла передзагрузка (то есть система выпала из черного экрана в синий), опять загружаемся с LiveCD и получаем дамп по следующим местоположениям:
  • %SystemRoot%\Minidump\ или проще C:\Windows\Minidump;
  • %SystemRoot% или проще C:\Windows;
• переписываем дамп (файл с расширением .dmp) на флешку с целью переноса на рабочую машину;
• анализируем его при помощи отладчика WinDbg, утилиты Kdfe, утилиты Bluescreenview или любым иным способом.
• если повезло, то получаем наименование драйвера-виновника и далее определяем кто же виноват - драйвер или подчиненное устройство;

Метод 5: восстановление разрешений

Среди прочих причин возникновения черного экрана смерти иногда встречается отказ в доступе кода модулей, участвующих в загрузке, к критически-важным объектам файловой системы. Зачастую подобное происходит после установки в систему некоторых категорий обновлений (все беды от обновлений, да? :), после чего последняя перестает загружаться. Часто установка обновлений идет не по типовому (прогнозируемому) сценарию, и всяческие проблемы, возникающие в процессе установки, приводят к сбоям. В итоге некоторые ключевые каталоги операционной системы оказываются в некоем "промежуточном состоянии" обслуживания с некорректно-выставленными разрешениями безопасности. Общий алгоритм действий по восстановлению работоспособности в этом случае таков:

• Загружаемся с любого вменяемого LiveCD, умеющего работать с реестром сбойной системы (я предпочитаю MsDaRT);
• Запускаем командную строку;
• Определяем имя диска (литеру, букву), на котором у нас в LiveCD располагается сбойная система;
• Устанавливаем разрешения для группы Все (по-русски, в русскоязычной ОС) на основные системные папки. Для этого последовательно выполняем серию (несколько) команд:

  icacls D:\Windows /T /C /grant Все:(OI)F
  icacls "D:\Program Files" /T /C /grant Все:(OI)F
  icacls "D:\Program Files(x86)" /T /C /grant Все:(OI)F
  icacls D:\Users /T /C /grant Все:(OI)F
  

  * где D: - раздел, на котором у вас подмапилась/размещается сбойная система (в вашем случае может быть другим).

• Запускаем графическое (regedit.exe) либо пакетное (subinacl.exe) средство работы с реестром и выставляем на указанные ниже разделы (и на все вложенные объекты) следующие разрешения:
  • раздел HKEY_CURRENT_USER :: для группы Администраторы - полный доступ, для группы Система - полный доступ, для группы ОГРАНИЧЕННЫЕ - Чтение, для группы <имя_собственной_учетной_записи> - Чтение.
  • раздел HKEY_LOCAL_MACHINE :: для группы Администраторы - полный доступ, для группы Система - полный доступ, для группы Пользователи - Чтение, для группы ОГРАНИЧЕННЫЕ - Чтение, для группы Все - чтение.
  • раздел HKEY_CLASSES_ROOT :: для группы Администраторы - полный доступ, для группы Система - полный доступ, для группы Пользователи - Чтение.
• Перезагружаемся.

Метод 6: восстановление темы оформления

Некоторые пользователи любят оформлять свои системы разнообразными нестандартными темами оформления и всячески экспериментировать с визуальными эффектами, зачастую применяя для этого разнообразное стороннее программное обеспечение. В некоторых случаях нестандартная (сторонняя) тема оформления может послужить причиной черного экрана смерти. Происходит это по причине как проблем в работе Диспетчера (менеджера) тем оформления (служба Темы, Themes), так и ошибок в данных самой темы оформления, во всяком случае никаких технических деталей у меня на руках в данный момент нет.
В реестре за тему оформления отвечает ключ с именем:

• HKEY_USERS\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\ThemeManager

параметр DllName (тип REG_EXPAND_SZ) в "чистой" системе должен иметь значение %SystemRoot%\resources\Themes\Aero\Aero.msstyles

Метод 7: проверка целостности системных файлов

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

• до начала загрузки ОС, по клавише F8 в режим Устранение неполадок компьютера;
• загрузиться с установочного диска ОС в режим Восстановление системы;
• загрузиться с LiveCD (MsDaRT);

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

Затем, непосредственно при запуске утилиты, нам требуется задать ряд дополнительных параметров [командной строки], конкретизирующих пути системной директории установки Windows и раздела "загрузочного" диска:

sfc /scannow /offbootdir=d:\ /offwindir=d:\windows

После запуска стартует процесс проверки, который может продолжаться довольно длительное время

по окончании работы утилиты, нам будет предложено проверить результаты проверки в указанном нами ранее выходном файле cbs.log. Открываем данный файл при помощи блокнота (доступного для запуска в среде восстановления через имя notepad.exe) и ищем в нем строки, содержащие ключевое слово corrupted:

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

• идентифицировать все файлы, которые средство проверки (по каким-то причинам) не смогло восстановить. в примере выше это rpchttp.dll;
• выяснить к какому пакету обновления относится битый файл. в примере выше это KB4520003;

Не важно, произвела утилита sfc фактическое восстановление поврежденных файлов или нет, мы получаем в свое распоряжение весь перечень проблемных файлов, далее, в крайнем случае, мы имеем возможность восстановить их (самостоятельно) с любой аналогичной рабочей системы.

Общий алгоритм действий

При возникновении черного экрана смерти нужно:

1. Визуально/аудиально убедиться в отсутствии аппаратных неисправностей загрузочного носителя (жесткого/твердотельного диска): характерные повторяющиеся через равные промежутки времени звуки, постоянно включенный (или моргающий через равные интервалы) светодиод;
2. Загрузиться с удобного для вас средства восстановления (Установочный диск Windows/DaRT);
3. Проверить "программно" загрузочный носитель на наличие плохих блоков/поврежденной структуры файловой системы (команда chkdsk /f/r);
4. Проверить, не заменены ли оболочка/параметры загрузки образов. При необходимости восстановить;
5. Изучить логи раздела Система на предмет событий с уровнем ошибка, затем проанализировать их. На основании собранной информации (приоритет уменьшается по списку):
• В случае нахождения событий, сообщающих о повреждении кустов реестра: вручную восстановить необходимые (либо все) кусты реестра;
• В случае нахождения событий, сообщающих о сбоях запуска критически важных сервисов/служб: при помощи оснастки Службы (services.msc) проверить факт запуска служб, при необходимости восстановить параметры запуска (например, на Автозапуск). В случае проблем с зависимостями проблемной службы, проверить службы, от которых зависит данная. В случае совсем уж серьезных проблем выполнять восстановление параметров напрямую через реестр;
• В случае нахождения событий, сообщающих о сбоях запуска критически важных драйверов: проверить опции запуска драйверов в реестре, проверить наличие и доступность соответствующих файлов драйверов на системном носителе и при выявлении повреждений попытаться восстановить оригиналы с рабочей системы идентичной версии;
6. Проверить наличие аварийных дампов (совпадающих по времени с моментом возникновения черного экрана). В случае обнаружения проанализировать дампы при помощи WinDbg (либо иных утилит);
7. Произвести восстановление разрешений на каталоги/реестр;
8. Проверить подмену темы оформления. При необходимости восстановить умолчание;
9. Произвести оффлайновую (через LiveCD) проверку целостности системных файлов;

То есть, в случае необходимости, приоритетно восстанавливаем реестр. Если с реестром все в порядке, а есть проблемы со службами (сервисами), то пытаемся восстановить их запуск. Если имеются проблемы с драйверами, то пытаемся выяснить, почему они не запускаются и исправить ситуацию.