Спасение Windows 11 от циклической перезагрузки

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

Как системный инженер и энтузиаст, любящий докопаться до сути («поковыряться в системных логах»), я решил не прибегать к банальной переустановке системы сразу, а пройти весь путь восстановления через консоль WinRE (Windows Recovery Environment).

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

Проблема

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

При очередном рестарте на экране возникает стандартная и довольно неприятная ошибка автоматического восстановления Windows (известная как «петля восстановления»). Система указывает конкретный лог-файл, в котором должна быть записана причина сбоя:
E:\WINDOWS\System32\Logfiles\Srt\SrtTrail.txt

Шаг 1: Поиск истинной буквы системного диска

Когда загружается среда WinRE, буквы дисков почти всегда перемешиваются. Тот диск, который в работающей системе называется C:, в консоли восстановления запросто может стать D:, E: или т.д. Также нужно заранее узнать букву загрузочной флешки, с которой я буду брать чистые файлы для восстановления.

Запускаю утилиту работы с дисками:

diskpart
list volume

Ориентируюсь по размеру томов. На моем целевом ПК системный диск с Windows определился под буквой E: (установочная флешка с Windows — под буквой F:).

После того как определил буквы, выхожу из утилиты:

exit

Шаг 2: Читаю лог-файл SrtTrail.txt

Для этого нужно попасть в командную строку. В окне ошибки выбрать Устранение неполадок -> Дополнительные параметры -> Командная строка.

В консоли ввожу команду, чтобы просмотреть лог прямо на месте:

more E:\WINDOWS\System32\Logfiles\Srt\SrtTrail.txt

Прокручиваю файл в самый низ. Ищу строки вроде «Критический шаблон загрузки» (Boot critical file) или сообщения о поврежденных файлах (часто это системные драйверы, файлы реестра или bootcat.cache).

Что произошло в моём случае: Ничего вменяемого оттуда вытащить не удалось, конкретики ноль. Было много событий о том, что системе не удалось связаться с серверами Microsoft для автоматического восстановления. Оно и понятно: сетевой драйвер или служба автонастройки сети просто не успевали инициализироваться за эти 15 секунд стабильности, как и сам лаунчер Wargaming, который падал из-за внезапного обрыва сетевых сокетов и повреждения системных библиотек.

Шаг 3: Автономная проверка системных файлов (SFC)

Далее логично пробую сделать базовую проверку системного диска. Обычная команда sfc /scannow в среде восстановления часто выдает ошибку, так как пытается проверить виртуальный RAM-диск самой среды WinRE, а не сломанную Windows. Нужен автономный режим с явным указанием путей, которые я выяснил на предыдущем шаге:

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

Эта команда сканирует защищенные системные файлы на реальном жестком диске и пытается восстановить поврежденные компоненты (например, битые .dll библиотеки).

Результат: Проверка отрапортовала, что «ошибок целостности не обнаружено». Но увы, проблема с отключением через 15 секунд никуда не делась. Придется задействовать тяжелую артиллерию — восстановление образа системы.

Шаг 4: Подготовка к автономному DISM (Решаю проблему ScratchDir)

Если SFC не справляется, значит, повреждено само локальное хранилище системных компонентов Windows (папка Component Store). Восстановить его можно утилитой DISM.

Однако в среде WinRE стандартный запуск DISM часто спотыкается о две проблемы:

• Ошибка 0x800f0915 («Не удалось найти содержимое...») — у компьютера в этот момент нет доступа к интернету, и DISM не может скачать чистые файлы из Центра обновления.
• Ошибка ScratchDir (нехватка места) — RAM-диск среды восстановления X: слишком мал для распаковки огромных временных файлов.

Чтобы решить вторую проблему, я принудительно перенаправляю рабочую директорию DISM на жесткий диск. Создаю временную папку:

mkdir E:\scratch

Шаг 5: Поиск установочного файла на флешке

Вставляю в ПК загрузочную флешку с Windows 11 (диск F: в моем примере). И мне нужно выяснить, какой именно тип сжатого образа на ней записан — install.wim или install.esd. Для этого ввожу:

dir F:\sources\install*

Тут нужно запомнить расширение файла, которое отобразится в результатах поиска.

Шаг 6: Определение индекса нужной редакции ОС

На загрузочной флешке обычно записано сразу несколько редакций ОС (Домашняя, Профессиональная, Корпоративная и т.д.). Мне нужен точный индекс (номер) установленной версии, чтобы DISM взял файлы именно от неё.

Выполняю команду (с заменой расширения на .wim или .esd в зависимости от того, что показал предыдущий шаг):

dism /Get-WimInfo /WimFile:F:\sources\install.esd

В выданном списке нашел свою редакцию (например, индекс 1 для Home или 4 для Pro) и запоминаю эту цифру.

Шаг 7: Запуск офлайн-восстановления с флагом /LimitAccess

И вот теперь этап когда собираю всё воедино. Запускаю DISM, принудительно указав использовать файлы с флешки в качестве источника, запрещаю лезть в интернет (/LimitAccess) и указываю созданную ранее временную папку на жестком диске (/ScratchDir).

Команда для моего случая (образ install.esd, индекс 4):

dism /image:E:\ /cleanup-image /restorehealth /source:esd:F:\sources\install.esd:4 /LimitAccess /ScratchDir:E:\scratch

Примечание: Главное не перепутать: E: — это буква моего системного диска, F: — буква флешки, а :4 в конце пути — мой индекс редакции.

Шаг 8: Финальный аккорд

После того как DISM успешно завершит восстановление (шкала дойдет до 100% и появится сообщение об успехе), обязательно необходимо закрепить результат классической проверкой системных файлов:

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

Теперь все системные файлы заменены на абсолютно чистые, оригинальные копии. Закрываю командную строку и перезагружаю компьютер в обычном режиме — система должна успешно загрузиться!

Вместо заключения: Помогло ли?

В теории этот алгоритм — панацея для 90% сложных системных сбоев Windows. Но в моем случае глубокое копание в автономных логах, очистка поврежденных системных «хвостов» и запуск продвинутого восстановления через DISM не помогли вернуть Windows 11 к жизни. Сбой оказался глубже — судя по всему, произошло критическое повреждение кустов реестра, не подлежащее автоматической сборке.

Пришлось пойти на крайнюю меру: резервное копирование пользовательских данных (благо всегда под рукой LiveUSB Debian 13) на внешний диск и чистая установка системы.

Теперь на компьютере клиента красуется великолепная новая Windows 11 — полностью настроенная, обслуженная, оптимизированная и работающая как швейцарские часы. А главное — ни один важный файл пользователя при переносе не пострадал!

Да, вместо банального хэппи-энда, где всё заработало по щелчку пальцев, реальность бывает другой — когда даже тяжелая артиллерия в виде автономного DISM пасует, и приходится накатывать чистую ОС.