Чорний екран смерті

1. теорія
2. Причина 1: пошкодження куща реєстру
3. Рішення 1: відновлення реєстру
4. Причина 2: відмова в запуску служб
5. Рішення 2: Відновлення запуску служб
6. Причина 3: стороння оболонка (провідник)
7. Рішення 3: відновлення оболонки
8. Загальний алгоритм Дій

Проблеми різних етапів завантаження операційної системи Windows досить широко поширені і виразно гідні власного розділу. Дане явище знайшло своє вираження у великій кількості різноманітних помилок, що виникають при виконанні коду з секторів MBR / PBR , модулів Bootmgr , Winload, Ntoskrnl, SMSS, Csrss, Winlogon, Userinit і деяких інших, одним словом, всіх тих компонентів, які беруть участь в процесі завантаження операційної системи. Не так давно в своїй практиці я черговий раз зіткнувся з однією з подібних проблем і вирішив написати собі невелику шпаргалку, оскільки завжди хотів якось систематизувати подібного роду помилки, і з чого то треба було визначено починати. З усього безлічі збоїв, що виникають на етапі завантаження Windows, хотілося б окремо відзначити помилки, звані користувачами Чорним екраном смерті.

Чорний екран смерті - група помилок різних етапів завантаження операційної системи, що характеризується зупинкою (підвисанням) процесу завантаження на стадіях, які не виконують виведення будь-якої (текстової / графічної) інформації на екран, що виражається у вигляді чорного екрану, на якому іноді можна спостерігати графічний ( миша) або апаратний (текстовий) курсор.

Вивчаючи матеріали в Мережі я зробив висновок, що проблема широко поширена, проте жорстко не закріплена за якимось одним етапом завантаження і включає в себе досить великий спектр різнорідних помилок, що виникають на різних стадіях. До чорного екрану смерті найчастіше відносять ще й проблеми, що виникають під час роботи операційної системи, джерелом яких є апаратні збої, проте ми їх розглядати не буде, оскільки вони мають нечисленність.

Тому, візьму на себе сміливість класифікувати кілька різновидів збою:

1. Чорний екран, що виникає на етапі завантаження / функціонування Master Boot Record (MBR) і Partition Boot Record (PBR). Курсор не відображається. При натисканні на клавіші пролунає відповідний сигнал.
2. Чорний екран, що виникає до відображення екрану вітання (логотип / рядок Запуск Windows) Windows (Bootscreen). Відображається апаратний курсор.
3. Чорний екран, що виникає після відображення екрану вітання (логотип / рядок Запуск Windows) Windows (Bootscreen). Відображається графічний курсор миші.

З описаного вище стає ясно, що вид у цього чорного екрану смерті може відрізнятися, ось приклад екрану з наведених на ньому працездатним курсором миші:

Після появи чорного екрану смерті завантаження зупиняється. Залежно від різновиду чорного екрану, або ми відразу не спостерігаємо більш ніякої активності, або якийсь час можна спостерігати активність жорсткого диска (світлодіод), однак на цьому все і закінчується. Найчастіше, операційна система втрачає здатність завантаження в якому б то ні було з доступних режимів: нормальному і безпечному, що іноді суттєво ускладнює пошук джерела проблеми. Свого часу в мені зріла ідея якимось чином систематизувати помилки, що виникають на різних етапах завантаження системи, результатом якої стала перша стаття серії про помилки Bootmgr , Однак на даний момент, починаючи з етапу Winload і далі стадії не описані, тому доводиться публікувати такі ось містечкові дослідження реальних збоїв. Причиною чорного екрану смерті є не досліджений поки що мною досконально програмний цикл, що виникає на різних стадіях за такими глобальним причин:

• Пошкодження коду / даних секторів MBR / PBR;
• Пошкодження системних кущів реєстру;
• Неможливість завантаження критичних драйверів етапу завантаження;
• Неможливість запуску критично необхідних сервісів / служб;

Чому подібні описаним вище помилки взагалі трапляються? Причиною є програмно-апаратні збої, помилки в коді системних компонентів, які працюють з критичними дисковими структурами, а так само алгоритмічні проблеми деяких модулів, що беруть участь в процесі завантаження ОС Windows.

• Апаратні помилки: ушкодження жорсткого диска;
• Програмні помилки: алгоритми (умови, цикли, функції), що не мають можливості вирішитися (разомкнуться, завершитися) через внутрішніх помилок / відсутності коду перевірки певного класу проблем на етапі завантаження кущів реєстру, драйверів / сервісів.

Звичайно ж, в черговий раз не перестаю дивуватися терпінню розробників, вже на протязі 20 з гаком років вперто ігнорують добре відомі громадськості проблеми. Є підозри, що система обробки помилок в різних модулях містить недоробки, які не передбачають інформування користувача про проблему на прийнятному рівні, натомість відбувається "тихий" останов і відмова в завантаженні модулів наступного етапу, результатом чого є чорний екран смерті, який (в штатному режимі ) повинен бути всього-лише переходом від закінчення однієї стадії до початку іншої. Ну якщо, припустимо, є проблеми з читанням інформації з жорсткого диска, тобто фізичне пошкодження поверхні / осередків пам'яті, ну постав ти таймаут з очікуванням об'єктів, при досягненні якого на екран буде виведена напис про неможливість читання з носія. Ні, простіше стояти стукати жорстким диском і показувати користувачеві чорних екран, мовляв здогадайся сам, милок.

Ми завжди спостерігаємо чорний екран при завантаженні операційної системи, але при нормальному перебігу процесу завантаження він короткочасний і ми просто не акцентуємо на ньому свою увагу.

теорія

Для того, що б проводити подальші дослідження, необхідно розуміти етапи завантаження операційної системи Windows. Так як стаття в альфа-версії, і я поки детально не розбирався з логікою роботи етапу та й самого коду ntoskrnl.exe, тому обмежуся лише припущеннями на підставі тих даних, які вдалося зібрати на поточний момент, а в наслідку, у міру отримання будь -або конкретної інформації, будемо видозмінювати матеріал. Все залежить від того, на якому етапі ми спостерігаємо чорний екран смерті. Якщо ми спостерігаємо чорний екран смерті з графічним курсором миші, то зазвичай ми бачимо його після екрану вітання (Windows Bootsplash, Bootscreen), що показує нам анімований логотип Windows (і рядок "Запуск Windows"). На підставі цього можу припустити, що ми знаходимося на етапі завантаження ntoskrnl.exe, в так званій фазі 1. Стан чорного екрану смерті настає на цьому етапі з наступних причин:

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

Але, адже поява чорного екрана смерті зовсім не означає, що саме на етапі функціонування ntoskrnl.exe код входить в нескінченний цикл. Як говорилося вище, активність диска видно візуально станом світлодіода, тому, ймовірно ntoskrnl.exe продовжує виконувати свої фази, і, можливо, передає управління наступного етапу, чого ми просто вже візуально не спостерігаємо. Бути може навіть ми доходимо до етапу Winlogon.exe, який з якихось причин (описані вище причини) не ініціює модуль logonui.exe, покликаний виводити екран із запрошенням до авторизації (для входу в систему натисніть клавіші Ctrl + Alt + Del). Після етапу ntoskrnl.exe і до Winlogon.exe є ще етапи SMSS / Csrss / Wininit, і цикл може виникнути на будь-якому з них, але для більш детальної інформації вже необхідно налагоджувати етапи завантаження.
Тому, перше, що необхідно робити у випадку з чорним екраном смерті, це по можливості спробувати отримати якомога більше інформації про деталі збою. У цьому нам допоможе системний Журнал подій (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. Як Ви вже могли помітити, це стандартна, знайома практично всім, оснащення, за допомогою якої ми традиційної підключаємося до системних логам.

Якщо раптом з якихось причин Ви займаєтеся відновленням за допомогою будь-якого іншого інструментарію (НЕ MS DaRT) і не можете працювати з оснащенням Управління комп'ютером, то просто відкривайте системний диск, на якому розташовується пошкоджена система, переходите по шляху C: \ Windows \ System32 \ winevt \ Logs і шукайте файл з ім'ям system.evtx. Його Ви зможете переписати на зовнішній носій (флешка) і відкрити в будь-якій робочій системі подвійним клацанням, або примусово через засіб EventVwr, для подальшого вивчення.

Тепер перед нашими очима списки подій, відкручуємо їх на дату збою, і починаємо переглядати, послідовно рухаючись по списку подій від більш ранніх до більш пізніх (вгору). Зараз побачимо, що ж цікавого мені вдалося знайти стосовно конкретно до мого випадку:
Перша подія, яке мене зацікавило, було першопричиною всієї тієї витіюватій ланцюжка подій, яка і привела до чорного екрану смерті. Причина полягала в дії користувача, про що красномовно говорило подія з кодом 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".
На перший погляд подія як подія, що говорить про неможливість завантаження декількох критично-важливих драйверів, але в мені воно родило кілька питань. Давайте, для початку, подивимося на те, що це за драйвера:

Найменування Опис

CProCtrl

Драйвер контролю завантаження CSP / HSM. Драйвер з комплекту Кріпто-Про.

ctxusbm

Citrix ICA Client USB Monitor Driver. Драйвер з комплекту Citrix Receiver.

discache

System Indexer / Cache Driver (Драйвер системного індексатора / кеша). Виконується в системі як драйвер режиму ядра з ім'ям "System Attribute Cache". Системний драйвер.

eeCtrl

Symantec Eraser Control Driver. Драйвер з комплекту Symantec Endpoint Agent.

MpFilter

Microsoft Malware Protection Driver. Драйвер з комплекту Microsoft Security Essentials.

spldr

Security Processor Loader Driver. Системний драйвер.

Wanarpv6

Remote Access IPv6 ARP Driver. Системний драйвер.

Мене спантеличив драйвер 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. Можна виконати повне відновлення всіх кущів реєстру, благо сама процедура описана в статті про відновлення реєстру з консолі відновлення. У даному рішенні я зробив виняток, і щоб зробити експеримент максимально чистим, я не став копіювати всі файли, а скопіював тільки файл SOFTWARE:

xcopy d: \ windows \ system32 \ config \ regback \ SOFTWARE d: \ windows \ system32 \ config / h / r / y

..де d: - диск, на якому у нас встановлена ​​пошкоджена система.
Після закінчення процесу копіювання файлу закриваємо консоль. Для цього можна натиснути на значок закриття вікна, або в командному рядку набрати команду exit і повернутися в меню вибору параметрів відновлення. Потім натискаємо кнопку Перезавантаження для ініціювання процесу перезавантаження станції. Після перезавантаження станції я побачив довгоочікуваний графічний екран вітання, система благополучно завантажилася.

Причина 2: відмова в запуску служб

Розділ знаходиться на стадії доопрацювання. Оформлення не завершено!

На момент створення розділу у мене "на руках" не було деталей подібного роду збоїв, тому розділ буде перероблений у міру виникнення схожого випадку. Зазвичай причиною є або повна відмова, або затримка запуску однієї з служб. Останній схожий інцидент у мене був пов'язаний з випадком, коли некваліфікований користувач (хоча по факту це був фахівець) справив відновлення системи до останньої контрольної точки прямо в сеансі, в якому агентом SCCM були встановлені (і чекали застосування при перезавантаженні) поновлення. Після завершення відновлення станція пішла в перезавантаження, яка очікувано завершилася чорним екраном смерті.

Рішення 2: Відновлення запуску служб

Все так же вікорістовувалося засіб Відновлення на зовнішньому носії. Самперед Було проаналізовано логи, за Якими, Наскільки я пам'ятаю, стало очевидно, что є проблеми з Наступний службами: Вузол агента SMS, Віддалене управління Configuration Manager, Агент послідовності завдання Configuration Manager и Windows Update. Для кожної з цих служб були вивчені відповідні помилки в журналі подій і по кожній помилці було вжито заходів щодо усунення причин зупинки та відновлення нормального запуску служби, після чого станція "ожила". На жаль, більш детальну інформацію в пам'яті зберегти не вдалося, тому розділ буде відкоректований під час вступу схожого інциденту.

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

Іноді зустрічаються ситуації, коли до чорного екрану смерті призводить некоректна робота зареєстрованої (зазвичай вірусом) сторонньої користувальницької оболонки, яка може містити помилки в коді. На одній з останніх стадій завантаження операційної системи модуль Winlogon.exe запускає модуль під назвою Userinit.exe, який, в свою чергу, запускає скрипти стадії завантаження, а потім викликає оболонку призначеного для користувача інтерфейсу explorer.exe, більш відому нам під ім'ям Провідник. Як завантажувач скриптів, так і саму оболонку можна підмінити, оскільки в системі передбачений механізм конфігурації альтернативної оболонки і завантажувача за допомогою спеціалізованих ключів реєстру. Ясна річ, що час від часу цією можливістю щосили користуються вирусописатели. У разі підміни стороння оболонка, отримуючи управління, або не виконує своїх функцій через помилки в коді, або зовсім з самого початку не спроектована для підтримки функціональних можливостей, властивих стандартному провіднику, результатом чого може бути поява чорного екрана смерті.

Рішення 3: відновлення оболонки

Оскільки в штатному режимі завантаження у нас закінчується чорним екраном смерті, для вирішення подібного кола завдань можна скористатися такими способами:

• Після появи чорного екрану смерті спробувати кілька разів натиснути комбінацію клавіш Ctrl + Alt + Del. Якщо натискання минуло й висвітився список, то запустити Диспетчер завдань. У вікні вибираємо вкладку Додатки, в нижній частині вікна тиснемо кнопку Нове завдання. У відкритому невеликому віконці, в рядку введення набираємо explorer і натискаємо Ok. Таким чином ми власноруч запустимо провідник;
• Якщо попередній метод на спрацював, то буде потрібно завантажитися з зовнішнього носія, що містить засоби відновлення (DaRT або будь-який інший);

Оскільки настройка оболонки зберігається в системному реєстрі, нам буде потрібно запустити редактор реєстру Regedit.exe, за допомогою якого ми і будемо виробляти необхідні зміни. У реєстрі за настройку користувальницької оболонки відповідає наступний ключ:
HKLM \ SOFTWARE \ Microsoft \ Windows NT \ CurrentVersion \ Winlogon
перевіряємо параметр Shell (сама оболонка), який повинен містити значення explorer.exe.
перевіряємо параметр Userinit (програми, що завантажуються процесом Winlogon на етапі входу користувача в систему), який повинен містити значення C: \ Windows \ system32 \ userinit.exe ,. (!) Не забувайте додавати символ "кома" в кінці шляху.
Як Ви вже зрозуміли, відновлення працездатності, в даному випадку, зводиться до перевірки наявності сторонніх записів в наведених вище ключах реєстру і (в разі необхідності) відновленні зазначених значень за замовчуванням. Після внесення змін до ключі реєстру, потрібно виконати перезавантаження операційної системи.

Загальний алгоритм Дій

При виникненні чорного екрану смерті потрібно:

1. Візуально / аудиально переконатися у відсутності апаратних несправностей завантажувального носія (жорсткого / твердотільного диска): характерні повторювані через рівні проміжки часу звуки, постійно включений світлодіод, моргаючий через рівні інтервали.
2. Завантажитися з зручного для вас кошти відновлення;
3. Перевірити "програмно" завантажувальний носій на наявність поганих блоків / пошкодженої структури файлової системи (утиліта chkdsk);
4. Перевірити, чи не замінені чи оболонка / завантажувач. При необхідності відновити, інакше переходимо до наступного пункту;
5. Вивчити логи розділу Система на предмет подій з рівнем помилка, потім проаналізувати їх. На підставі зібраної інформації (пріоритет зменшується за списком):

• У разі знаходження подій, які повідомляють про пошкодження кущів реєстру: вручну відновити необхідні (або все) кущі реєстру;
• У разі знаходження подій, які повідомляють про збої запуску критично важливих сервісів / служб: за допомогою оснастки Служби (services.msc) перевірити факт запуску служб, при необхідності відновити параметри запуску (наприклад, на Автозапуск). У разі проблем з залежностями проблемної служби, перевірити служби, від яких залежить дана. У разі зовсім вже серйозних проблем виконувати відновлення параметрів безпосередньо через реєстр;
• У разі знаходження подій, які повідомляють про збої запуску критично важливих драйверів: перевірити опції запуску драйверів в реєстрі, перевірити наявність і доступність відповідних файлів драйверів на системному носії і при виявленні пошкоджень спробувати відновити оригінали з робочою системи ідентичною версії;

Тобто, в разі необхідності, пріоритетно відновлюємо реєстр. Якщо з реєстром все в порядку, а є проблеми зі службами (сервісами), то намагаємося відновити їх запуск. Якщо є проблеми з драйверами, то намагаємося з'ясувати, чому вони не запускаються і виправити ситуацію.