Мне удалось разобраться, почему возникает сообщение «Было предпринято несколько попыток, но причину проблемы определить не удалось» и как вернуть жизнь операционке без радикальной переустановки.
Симптомы проблемы: с диском всё в порядке, файловая система в порядке, на разделах файлы с загрузочной флешки или диска просматриваются, внешне всё на месте, все тесты система восстановления заканчивает с кодом 0x0 (нет ошибок), но Windows упорно не стартует, предлагая восстановление, при этом не может объяснить пользователю — почему.
Единственная зацепка — в описании проблемы, выдаваемом средством восстановления, есть строчка вида
Сигнатура проблемы 07: CorruptFile
На этом этапе уже можно догадаться, что операционная система не запускается по причине отсутствия или повреждения какого-то из файлов, необходимых на этапе старта ядра. Однако, нигде нет упоминаний, о каком именно файле речь. Это можно узнать лишь «доломав» операционку: нужно заменить процесс загрузки так, чтобы система восстановления просто не запускалась. Ниже готовая пошаговая инструкция.
1. Находясь в средстве восстановления, нажимаем «Показать дополнительные возможности восстановления системы» и выбираем запуск командной строки для ручного вмешательства.
Нас спросят логин и пароль для пользователя Windows, под которым мы сможем залогиниться в упавшую Windows, хотя это нам не принципиально.
2. В консоли выполняем последовательно две команды:
bootrec /RebuildBcd
bcdboot d:\windows
На всякий случай — предварительно убедитесь (путём dir d:\windows) что буква диска в данной среде восстановления действительно «d».
Вот, теперь мы «прибили» систему восстановления. Возможно даже, что кое-где на начальном этапе у нас теперь будут надписи не по-русски (или какой там был язык, если Windows локализованная), а по-английски. Если это нежелательно, то в конец второй команды добавьте опцию "/l ru-RU":
bcdboot d:\windows /l ru-RU
Ну или какой там у вас язык использовался. Далее. Смело перезагружаемся и (если спрашивают) выбираем обычную загрузку Windows. Очень скоро загрузка прервётся, показав на чёрном экране кучку белых букв, примерно так:
Разумеется, строчка с «File:» — единственное для чего всё это и затевалось. Хорошенько запоминаем имя указанного файла (или фотографируем на мобильник, записываем на бумажку и т.п.) и достаём нашу козырную загрузочную флешку с установщиком Windows (или вставляем аналогичный DVD), жмём Reset (при наличии) и загружаемся в установщик. Главное — чтобы у нас совпадала редакция (7, 8, ...), язык системы и разрядность (x86/x64) систем на диске и на установочном носителе.
Теперь нам надо вернуть всё как было до нашего прихода.
Выбираем, дойдя до изображения справа, восстановление системы. Нас просят, какую из систем мы собираемся восстанавливать:
Если что-то не так — нам скажут, что установочный диск не подходит к установленной системе. Следует убедиться в правильности выбранной разрядности (посмотрите на диске наличие папки «Program files (x86)» — если есть, то это 64-битная ось, если нет, соответственно, 32-битная, хотя надёжнее поискать SysWOW64 в папке самой оси), попытаться загрузить инсталлятор в другим языком, а может быть и взять другую редакцию.
Пришла пора откинуться в кресле и наблюдать за процессом.
По окончании этого процесса мы вернёмся туда, откуда начинали — к постоянному запуску системы восстановления, которая не знает в чём проблема. Если бы мы могли сразу увидеть название файла, который создал проблему — всего выше не потребовалось бы!
Как бы то ни было, теперь нам остаётся лишь исправить саму проблему, к которой мы так долго подбирались. Снова жмём «Показать дополнительные возможности восстановления системы» и выбираем запуск командной строки. Это нам нужно лишь для того, чтобы запустить regedit.exe
В редакторе реестра выбираем ветвь HKEY_LOCAL_MACHINE и в меню выбираем подгрузку куста реестра из файла:
В открывшемся диалоге скармливаем редактору файл SYSTEM из папки d:\windows\system32\config (это кусок реестра восстанавливаемой оси).
Нас спрашивают имя — даём абсолютно любое имя, например «1». Куст подключается и мы можем его выбрать в окне редактора. Теперь надо просто найти и удалить сведения о том файле, имя которого мы наблюдали белым по чёрному. Нажимаем Ctrl+f (можно даже просто F3) и вбиваем то самое имя в строку поиска (путь вводить совсем не обязательно). Когда редактор найдёт запись, удаляем всю ветвь (в левой части окна редактора, где дерево реестра) с этой записью и повторяем поиск (F3). Когда получим сообщение «Поиск в реестре завершён» — можно закругляться: сматываем дерево обратно на наше заданное кусту имя («1» например) и через меню редактора выгружаем куст.
Всё, ремонт закончен, перезагружаемся и проверяем работу операционки!
P.S.: Как должно быть видно по имени файла, которое мы с таким трудом выудили у системы — проблему как правило создают разного рода трояны, любезно устанавливаемые пользователями, работающими с административным аккаунтом системы, причём проблема возникает не тогда, когда троян (или даже просто малварь) устанавливается, а тогда, когда зверя выпиливает насильно антивирус. Оставшаяся в реестре запись файла трояна, как «позарез нужного для запуска», и приводит Windows к зацикливанию с попыткой восстановления. Поэтому, чтобы не вставать дважды — желательно сначала просканировать файлы антивирусом, поудалять мусорных троянов с диска, и потом приступать к описанным процедурам — на случай, если в системе прописалось больше одного таких зверька.
Комментарии (17)
jok40
29.01.2016 15:44+3Если это остатки от вирусни, то могут быть поменяны права доступа к ветке реестра, да и владелец ветки может быть сменён. Так что поиск в реестре через F3 или попытка удалить ветку может не сработать. Например, можете получить акцесс денайд. Тогда нужно будет дополнительно поколдовать — вернуть админа в владельцы ветки и дать ему полные права на доступ к ней — прежде чем удалять.
jok40
30.01.2016 21:57Дополнение про поиск: если вирус сменил владельца и права у своей ветки, то регедит вообще не найдёт эту ветку при поиске имени файла. Тогда нужно будет пойти в загруженный куст в ветку HKLM/SYSTEM/ControlSet001/services и искать там папку, при попытке открытия которой будет появляться акцесс денайд. Если таковая нашлась — тогда стандартно: меняем её владельца на админа, даём ему полные права, заходим, смотрим имя файла: если не то — выходим и ищем дальше. Если то — удаляем. Хотя лучше не удалять, а просто отключить автозапуск: изменить параметр start на 4. А удалить потом из под работающей оси командой «sc delete имя_службы». Где имя_службы — название той самой папки, в которую невозможно было зайти. Я считаю последний вариант более корректным, потому что системе виднее — какие у службы зависимости и она их тоже удалит.
DmitryAnatolich
30.01.2016 06:55По-моему, если вы отхватили Corrupted File, то это верный признак того, что нужно сливать образ диска и прогонять по жесткому тесты.
nik_vr
30.01.2016 08:30+1А вот, кстати, я пару раз сталкивался с описанной в статье проблемой, и прогон диска в Victoria ничего не давал — HDD исправен. Chkdsk /f /r тоже ничего не находил, откат системы к точке восстановления либо отрабатывал с ошибкой, либо не давал результата. Т.е. имело место просто повреждение файла по какой-либо причине (возможно, именно вирус).
Frankenstine
30.01.2016 18:29+2CorruptFile вы получите, даже если файла совсем нет. То есть его удалили.
ComodoHacker
30.01.2016 21:19+2операционная система не запускается по причине отсутствия или повреждения какого-то из файлов
«Corrupt» в переводе с языка разработчиков ядра означает «ZwOpenFile() вернула что-то непонятное». Диагностика ошибок это не про них.
nitro80
02.02.2016 13:00+1У меня раз так было. Свежеустановленная 7ка отказалась работать, я только приехал в Паттайю в отпуск, надо было доделать рабочие дела, а комп не работает. На телефоне нашел где можно купить установочный диск (да здравствуют пираты!!) и пришлось от винта отрезать кусок (методом тыка определил необходимый размер). При этом, винда упорно молчала что винт битый. Просто в какой-то момент зависала и переставали загружаться. В итоге, в первые 3-4 дня отпуска винду я переустановил несколько раз, буквально по 2 раза в день.
xforce
А если бутлог включить в нем разве не видно проблему с файлом?
Frankenstine
В следующий раз попробую найти альтернативный способ узнать проблемный файл :)
ComodoHacker
Напишите уж тогда конкретные команды.
xforce
Это не команды, это по ф8 при старте включается с 2000 до 7. В 8 и выше не знаю. Создается в %windir%\ntbtlog.txt
vlivyur
Насколько помню, после такого в bootmenu не войти.
ComodoHacker
Мне как раз интересно про 8-10 — изменилось ли что-нибудь.
Okloks
Ни разу бутлог не выручал
Мало того, что он стопорится перед проблемным файлом (т.е. чтобы узнать имя файла — надо опять же вывернуться), так ещё иногда тупо не пишется на диск (хотя windows как бы грузится и он должен по идее уже писаться)