Диагностика загрузки Windows: лог ntbtlog.

Диагностика загрузки Windows: процесс загрузки драйверов для системы в текстовом формате.

Привет всем, продолжаем знакомиться с Windows более внимательно, и сейчас мы рассмотрим возможность изучить порядок загрузки драйверов поэтапно. Система позволяет это сделать, предлагая пользователю создавать одновременно с загрузкой лог-файл, в который она внесёт список загружаемых и выгружаемых драйверов. По умолчанию он именуется, дополняется (не обновляется) и хранится в виде C:\Windows\ntbtlog.txt. Относительно опытные пользователи наверняка знакомы с такой функцией, которая в нормально работающей системе доступна прямо из графического интерфейса. Она видна в одной из вкладок утилиты Конфигурации системы msconfig. Быстрый способ на неё выйти это набрать в строке Выполнить или через поиск (клавиша WIN) команду вызова

msconfig -2

и выставить галку у чек-бокса Журнал загрузки:

Диагностика загрузки Windows из консоли cmd.

Следующий способ позволит создать журнал загрузки из консоли, что даёт возможность делать это (в том числе) и для Windows, которая уже или не загружается или даёт при загрузке очевидный сбой. Смысл способа в коррекции содержания директив загрузчика, который может находится где угодно. Т.е. возможно и на «побитом» носителе. После чего, изучив в указанном месте указанный файл, ошибка может проявиться в логе отчётливо. Рассмотрим пару вариантов, когда диагностика загрузки Windows активируется в функционирующей системе и когда включить ведение лога через msconfig уже нельзя.

Windows работает.

Запускаем консоль от имени администратора с последующей командой

bcdedit

и завершаем ввод клавишей Ёптр, дождавшись вывода информации из загрузчика. Ориентируемся на сектор Загрузка Windows в части идентификатор. Описание {current} означает, что это и есть текущая Windows. Короче, если система на компьютере одна — вообще не парьтесь. Смотрите вниз: последней строчкой загрузчик скажет, ведётся ли журнал. В части bootlog по умолчанию всегда No (ведение журнала отключено).

Активируем его тут же:

bcdedit /set {current} bootlog Yes

Проверяем сделанное повторной командой (если консоль вы не покидали, просто щёлкните пару раз по стрелочке вверх — это поиск и выбор ранее набранных команд)

bcdedit

Пока не забыли: обратная команда примет вид

bcdedit /set {current} bootlog No

Windows не работает или «опрокидывается».

Смысл тот же, просто стоит учесть, откуда запускаемая в консоли команда bcdedit будет инициирована. Не важно, на каком этапе загрузка системы стопорится (даже в случае BSOD), регистрацию лога можно начать в любом случае. Вариантов тут два: из ремонтной консоли (через восстановление системы) или с внешнего диска (флешки или через дисковод). Если нет загрузочной флешки, путь к созданию и прочтению лога будет таким. Пару раз прерываем загрузку системы кнопкой Reset с корпуса компьютера, вызывая процесс автоматического восстановления:

После перезапуска в корне диска С сформируется файл по адресу C:\Windows\ntbtlog.txt. В любом случае, можно задействовать (в обоих вариантах) и консоль команд. Команда из консоли cmd может принять такой вид:

bcdedit /set {идентификатор} bootlog Yes

Просто вместо идентификатор подсуньте тот, что соответствует незагружаемой Windows. Если загружаетесь из среды восстановления, с флешки или с оптического дисковода, для такой Windows это будет default. При этом при первоначальном запросе командой bcdedit информация о ведении журнала не выводится:

Ознакомиться с содержимым документа можно будет прямо из консоли командой

notepad.exe %WinDir%\ntbtlog.txt

Вот видео для ознакомления с маленькой хитростью, позволяющей «вытаскивать» информацию с незагружаемой Windows и, в том числе, читать текстовые документы прямо из консоли:

Диагностика загрузки Windows: анализ документа.

Наиболее частое применение фиксирования загрузки в логах — сравнение журналов для нормального и Безопасного режимов загрузки. Или, реже и как уже указывалось, в случае, если система не загружается или загружается с ошибками в работе с подозрением на какой-то из драйверов. Содержимое файла можно использовать и в тех случаях, если система стала очень уж долго загружаться. Очень давно я лично проводил собственные изыскания по поводу, какие настройки можно легко отключить именно при помощи документа %WinDir%\Ntbtlog.txt. Структура файла, помимо краткой информации по системе и даты создания, содержит список загружаемых драйверов по типу:

Loaded \SystemRoot\System32\DRIVERS\драйвер — т.е. драйвер загрузился

Not loaded \SystemRoot\System32\DRIVERS\драйвер — драйвер не загрузился

Как вы поняли, именно запись Did Not Load свидетельствует о том, что запуск этого драйвера Windows пропустила. Что, впрочем, далеко не всегда означает, что этот драйвер проблемный. По той простой причине, что многим драйверам загружаться одновременно с системой не обязательно. А вот при поиске побитого драйвера могут помочь простые правила.

• Если Windows в Безопасном режиме (в отличие от обычного) загрузилась без проблем. Сравнивайте два журнала, созданные в обычном и Безопасном режимах: проблема лежит в списке тех драйверов, которые в обычном режиме получили статус Loaded, а в Безопасном — Did not loaded. Оставаясь в Безопасном режиме вы легко можете удалить любой из незагруженных драйверов, начиная с недавно установленных или обновлённых по одному-два за раз. При этом пробуя загрузиться в обычном режиме, пока Windows не выкажет признаки стабильности.
• Если Windows не загрузилась даже в Безопасном режиме. Читаем лог из консоли командой

notepad %WinDir%\ntbtlog.txt

Сравниваем логи для обоих режимов (даже если ни в одном система уже не загружается). Бывает так, что лога для какого-то режима уже нет. В таком случае вам придётся воспользоваться журналом с другого компьютера со схожей конфигурацией Windows (хотя бы в части версии и сборки). И вот почему. Драйвер, мешающий загрузке вашей Windows даже в Безопасном режиме, не отображается в журнале вообще. Но именно он появится в журнале с пометкой Loaded Driver, когда система в Безопасном режиме работает нормально. Такая процедура часто прокатывает и для служб, загружающихся только в нормальном режиме. Они — службы — начинают подгружаться только после успешной загрузки нужных драйверов. Именно в этот момент вы начинаете видеть окна приветствия Windows. Кстати, и запуск служб также можно контролировать. А сейчас вам остаётся удалить побитый (или предположительно побитый) драйвер из консоли и загрузиться в нормальном режиме.

Насколько метода точна?

Диагностика загрузки Windows с помощью ntbtlog — не панацея. В Windows «в базовой комплектации» никогда для нас с вами «точного» не было и не будет. Одной из альтернатив могло бы стать применение Windows Assessment Toolkit с каким-нибудь Windows Performance Analyzer внутри. Вы же вполне можете столкнуться с ситуацией, когда список «успешно и не очень» подгруженных драйверов от сеанса к сеансу пусть немного, но будет отличаться. Не редки случаи, когда успешно загруженный в логе драйвер в следующей же строчке того же лога отваливается. Не уверены, должен загружаться драйвер или нет? Копайте вручную: узнавайте, принадлежит ли он системе или другому ПО, каков должен быть в размерах, есть шанс скачать его из официальных источников или вытащить с установочного образа. Но помним, что если он туда полез, не загрузился тот не просто так. Но в тех случаях, когда логи содержат отказы по слишком уж большому количеству драйверов, следует предпринять действия уже по проверки целостности диска и корректной работы RAM. Так что не бойтесь предыдущие логи удалять (или переименовывать) для получения более свежих данных о процессе загрузки Windows. Так или иначе, параллельные варианты диагностики у вас есть:

Windows не загружается: виноват драйвер?

Далее. Есть смысл присмотреться к драйверам, которые пытаются безуспешно подключиться множественное количество раз — это прямой путь к разгадке, почему Windows загружается очень долго на фоне предпринятых действий по оптимизации (очистке, дефрагментации, коррекции содержимого Автозагрузки и т.п.). Быть может, это какой-нибудь dxgkrnl.sys дискретной видеокарты, которому мешает встроенный видеоадаптер Microsoft Basic Display и есть смысл тот отключить в Диспетчере устройств? Вполне вероятно, что причиной долгой загрузки служит злополучный системный NDPROXY.SYS, «тормозящий» добрую половину компьютеров планеты, находящихся под управлением Windows. Им так любят крутить DNS-управлялки… Вобщем, ремонтные утилиты Windows и антивирус при анализе обнаруженных вам в помощь.

Успехов нам всем.