Перезапустите систему windows и выполните sfc еще раз

Ошибка sfc.exe: Для завершения восстановления системы требуется перезагрузка. Приветствую всех на страницах блога К76, сегодня попытаемся справиться с очередной ошибкой утилиты восстановления системных файлов Windows sfc.exe. На этот раз симптомы проблемы таковы. Запуская утилиту с целью проверить целостность жизненно важных для Windows файлов из консоли

sfc /scannow

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

Для завершения восстановления системы требуется перезагрузка. Перезапустите систему Windows и выполните sfc еще раз.

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

Как избавиться от ошибки » Для завершения восстановления системы требуется перезагрузка «?

Чаще всего эта проблема подстерегает владельцев Windows 7. Подойдём к решению вопроса с нескольких сторон. По определению, я всё-таки должен вас попросить послушаться совета консоли и перезагрузить Windows с целью запустить sfc.exe повторно. Но, раз уж вы здесь, постоянный перезапуск системы уже не помогает.

Убиваем файл pending.xml

Ну не могу я вас оставить без теории. Вероятнее всего, что причиной такого поведения утилиты (и системы в целом) стали некорректно установленные обновления. И указанный файл pending.xml содержит в себе информацию по полученным и применяемым файлам обновлений и ключей (а иногда и целых разделов) реестра. Которые, как вы успели заметить, просятся к установке во время завершения работы Windows. Как только мы согласимся, в систему полезут критические и не очень обновления. Если что-то пойдёт не так ещё на этапе применения критических обновлений, система откатится обратно. Если критические обновления установятся успешно, но неудача подстережёт нас на этапе установки некритических, система попытается их установить при перезагрузке, используя ключ реестра SetupExecute и подсистему Диспетчера сеанса (smss.exe). Когда система загружается, она читает указанный ключ реестра на повторную установку обновлений. И, если снова беда — установка обновлений откладывается. Так что при круговой перезагрузке из-за неудачных обновлений следует удалять именно указанный ключ. Однако в нашем случае система не может именно разобрать границы между «качеством» обновлений на очереди: где критические, а где нет. И Windows загружается нормально. А, раз она загрузилась, значит и обновлений никаких к применению нет. Таким образом ситуация глупая — внешне всё работает, однако до очередной попытки обновиться неполадки в системе может заметить только sfc и DISM. Вывод? Он в заглавии абзаца.

• Отправляемся в папку

C:\Windows\WinSxS\

ищем файл pending.xml и переименуем его любым понравившимся вам способом. Все стающие в очередь при перезагрузке задачи не появятся в следующем сеансе, и можно будет попробовать запустить sfc повторно.

Если не помогло…

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

• Запускаем команды поочерёдно:

del *:\Windows\WinSxS\cleanup.xml

del *:\Windows\WinSxS\pending.xml

где * — буква тома с системными файлами Windows. ВНИМАНИЕ! Буква диска может отличаться от привычной С. Для определения нужной буквы вам пригодится утилита по работе с разделами DISKPART.

Для Windows 8|10 можно попробовать и такую команду:

dism.exe /image:*:\ /cleanup-image /revertpendingactions

Обратите внимание, флаг /online отсутствует не случайно, дабы избежать ошибки типа DISM doesn’t support servicing Windows PE with /Online option.

• Теперь попробуем запустить sfc.exe отсюда:

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

• Выходим из консоли

exit

и перезагружаемся.

Успехов.

Означает ли это, что всё так плохо, что даже SFC не работает? Не всегда, просто во время проверки в системе происходит сбой или инструмент не может получить доступ к каталогу WinSxS, в коем расположены важные файлы. Вероятны и другие причины — повреждение файловой системы, наличие физически нечитаемых секторов на диске, отсутствие у пользователя соответствующих прав доступа. Что делать и с чего начинать поиск причин неполадки?

Причиной ошибки сканирования может быть ограничение доступа SFC к каталогу WinSxS. Попробуйте снять их, выполнив в консоли CMD команду

и перезагрузив компьютер.

sfc /scannow /offbootdir=D:\ /offwindir=C:\Windows

• Примечание: определить буквы томов в загрузочной среде проще всего с помощью Блокнота, запустив его командой notepad и выбрав Файл → Сохранить как.

Если приведенные выше способы не дали результатов, высока вероятность, что отказ защиты ресурсов Windows вызван повреждением самого хранилища системных компонентов, то есть содержимого папки WinSxS. Проверить его состояние можно командой

если она выдает сообщение о необходимости восстановление хранилища, выполняем в консоли такую команду:

Компьютер при этом должен быть подключен к интернету, поскольку Windows может потребоваться подключиться к серверу Microsoft и скачать недостающие файлы. По завершении процедуры перезагружаемся. Теперь, когда хранилище восстановлено, sfc/scannow должна заработать как надо.

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

Проблема сохранения работоспособности ключевых системных компонентов и, как следствие, операционной системы в целом, стояла перед разработчиками Microsoft Windows с самого того дня, когда первые версии ОС начинали своё знакомство с широкой аудиторией, ведь по началу сама система была и вовсе беззащитна от вмешательства различного рода стороннего программного обеспечения, инсталлируемого с использованием административных привилегий и беззастенчиво переписывающего своими компонентами «родные» системные модули. Понятно, что столь серьезная проблема требовала своего скорейшего решения и в итоге Microsoft начали предоставлять изнемогающей от глюков общественности различные методы выхода из ситуации. Это были, по-началу, и службы контроля за целостностью важных системных файлов, и утилиты привидения их к эталонным версиям, в конечном итоге был разработан принцип компонентизации или модуляризации. «-Ну Конечно»,- скажете Вы,- «зачем нам все это? Мы всегда можем решить проблему и более кардинальным образом, ведь у нас в запасе есть проверенное десятилетиями, безотказное средство под названием «переустановка», либо такое как возврат к ранее созданной точке восстановления». Можно восстановить из ранее созданного образа системы, но этим могут похвастаться лишь самые педантичные, а у обычных обывателей довольно редко резервный образ бывает актуальным (если вообще присутствует), в любом случае, придется затратить свое драгоценное личное время на приведение системы к необходимому состоянию. Да, описанные методы действительно актуальны, однако подобное решение и так рассматривалось разработчиками как выход из сложившейся ситуации довольно продолжительное время Все это не делает саму систему стабильнее, а ведь одна из задач авторов хорошей ОСи — сделать её отказоустойчивой. Но в итоге разработчики Microsoft предоставили пользователям средство под названием sfc, о котором и пойдет речь в данной статье.

Sfc (System file checker) — утилита проверки целостности системных файлов операционной системы Windows. Выполняет проход по каталогам, содержащим ключевые системные файлы операционной системы и производит восстановление поврежденных или отсутствующих системных файлов.

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

Запуск проверки целостности файлов

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

Поскольку sfc является консольной утилитой (утилитой командной строки), то и запускать её следует из командного интерпретатора cmd. Для выполнения комплексной проверки всех системных файлов, выполните следующую команду:

sfc /scannow

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

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

• Защита ресурсов Windows не обнаружила нарушений целостности. Это сообщение говорит о том, что WRP не смогла найти каких-либо повреждений в операционной системе и стоит задуматься о диагностировании системы другими способами;
• Защита ресурсов Windows не может выполнить запрошенную операцию. Утилита sfc сообщает нам, что WRP не смогла выполнить необходимые операции восстановления. В этом случае можно попробовать:
  1. перезагрузить систему в защищенный режим и запустить sfc из-под него;
  2. дополнительно удостоверьтесь что папки PendingDeletes и PendingRenames присутствуют в директории %WinDir%\WinSxS\Temp;
  3. проверьте что у sfc (пользователь TrustedInstaller) есть разрешения на доступ к директории %WinDir%\WinSxS\ и множеству вложенных поддерикторий командой icacls c:/windows/winsxs;
• Защита ресурсов Windows обнаружила поврежденные файлы и успешно их восстановила. В этом случае процесс завершился удачно, ради интереса Вы можете ознакомиться с результатами работы утилиты sfc в файле %WinDir%\Logs\CBS\CBS.log;
• Защита ресурсов Windows обнаружила поврежденные файлы, но не может восстановить некоторые из них. Утилита сообщает нам о том, что WRP не смогла восстановить некоторые несоответствия. В этом случае у нас, с большой вероятностью, повреждено хранилище компонентов (WinSxS) и у нас имеется два возможных варианта решения проблемы, которые описаны в разделе Восстановление хранилища компонентов.
• Для завершения восстановления системы требуется перезагрузка. Перезапустите систему Windows и выполните sfc еще раз. Обычно подобная ошибка появляется при запуске из-под ограниченного рабочего окружения, такого, например, как среда восстановления (Windows RE). Для решения проблемы попробуйте запустить утилиту sfc с дополнительными параметрами, как описано в разделе Запуск из среды восстановления.
• Защите ресурсов Windows не удается запустить службу восстановления. Ошибка говорит нам о том, что службы, от которых зависит работа утилиты, не могут запуститься. Службы, которые могут являться причиной ошибки: «Теневое копирование тома», «Установщик модулей Windows» и «Установщик Windows». Проверьте, возможен ли вообще запуск данных служб, в случае возникновения проблем проверьте зависимости. Иногда причина может крыться в запуске консоли, из-под которой выполняется команда sfc, с ограниченными правами.
• В данный момент выполняется другая операция обслуживания или восстановления. Дождитесь ее завершения и повторно запустите SFC. Информационное сообщение информирует о том, что в данный момент стек обслуживания занят. На низком уровне единственное приложение, которое может работать со стеком обслуживания, это модуль TrustedInstaller.exe. Соответственно, когда происходит попытка одновременного обращения к функциям стека обслуживания другого источника, возникают проблемы доступа. Но если Вам уж очень необходимо освободить стек для проведения неотложных манипуляций, то просто попробуйте снять через Диспетчер задач процесс с именем TrustedInstaller.exe, однако имейте в виду, что в этом случае возможны проблемы!!

Если в процессе проверки/восстановления в самой утилите sfc возникли ошибки (описанные выше), то можно руководствоваться простым алгоритмом:

1. попытаться повторно запустить её еще пару-тройку раз. В практике нередко наблюдались случаи, когда в ходе очередного запуска sfc все же удавалось нормально выполнить свою работу.
2. если все же устойчиво получаем ошибки, то производим анализ результатов в файле %WinDir%\Logs\CBS\CBS.log.
3. по результатам анализа результатов в файле отчета производим ручное восстановление недостающих/битых компонентов. Возможно привлечение этапов работы с компонентной моделью Windows, как описано в этом хабе.

Часто алгоритм восстановления работоспособности не так тривиален, и приходится выполнять шаги по несколько раз. Например, запустили sfc, получили отчет, прошлись dism до момента, пока он не сообщает о том, что ошибок нет, затем снова sfc и по результатам ручное восстановление из рабочей системы недостающих/битых файлов. И так по кругу до появления результатов sfc: Защита ресурсов Windows обнаружила поврежденные файлы и успешно их восстановила или Защита ресурсов Windows не обнаружила нарушений целостности.

Фактически утилита sfc в процессе работы производит обход системных директорий (таких как %Windir%\System32), замену (удаление) некорректных образов системных библиотек и синхронизацию жестких ссылок на актуальные версии библиотек в хранилище компонентов WinSxS. Фактически SFC в своей работе опирается на контрольные суммы файлов, сравнивая их с копиями, которые Windows хранит в специальной базе.

Анализ результатов

Для того, чтобы лицезреть результаты работы утилиты sfc нам предлагается открыть файл журнала компонентной модели %WinDir%\Logs\CBS\CBS.log любым доступным в системе текстовым редактором.

Возможна ситуация, когда по причине некорректной работы сервиса обслуживания, файл отчетов CBS.log не успевает «ротироваться» и раздувается до немыслимых величин. На одной из систем я наблюдал аж 990Мб живых записей. Для открытия файла подобного объема придется постараться!

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

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

, во втором содержится информация по проверке компонентов и границы блоков помечаются так:

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

findstr /c:»[SR]» %windir%\logs\cbs\cbs.log > c:\sfcdetails.txt

в результате выполнения приведенной команды, в корне диска C:\ будет создан файл sfcdetails.txt, содержащий только лишь те строки исходного файла, которые содержат префикс [SR], что существенно упрощает поиск необходимой нам информации об обнаруженных утилитой ошибках. В получившемся после фильтрации файле ищем записи о неудачных попытках восстановления:

В данном случае обращать внимание на строки, содержащие фразы Could not reproject corrupted file и source file in store is also corrupted, содержащих информацию и по самому объекту (файлу). Они означают, что файл в хранилище так же поврежден и не может быть перепроецирован вообще никак и ни от куда. До тех пор, пока мы не исправим данные ошибки самостоятельно (в ручном режиме), утилита sfc (в большинстве случаев) при повторной проверке будет давать на выходе ошибочный статус завершения.

Запуск из среды восстановления

Если сама операционная система уже не в состоянии загрузиться в штатном режиме, можно запустить sfc из командной строки консоли восстановления. Для запуска консоли восстановления можно загрузиться в одном из следующим режимов:

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

Далее, в зависимости от выбранного метода, после нескольких окон выбора языка и авторизации, в финальном меню выбираем пункт «Командная строка».

В случае запуска из командной строки среды восстановления, имеется дополнительная специфика работы утилиты sfc. Перво-наперво нам потребуется задать переменную окружения WINDOWS_TRACING_LOGFILE для спецификации расположения файла с результатами работы (иначе результаты попросту не сохранятся):

set WINDOWS_TRACING_LOGFILE=d:\cbs.log

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

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

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

Для чего нам конкретизировать системный раздел параметром offbootdir? Вероятно, как раз на основании этого параметра высчитывается путь к папке хранилища WinSxS и реестра, содержащей сами эталонные файлы и записи о регистрации компонентов.

Выводы

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

Для устранения повреждений целостности Windows в системе предусмотрена утилита SFC. Запущенная с ключом /scannow, она сравнивает контрольные суммы системных файлов и в случае несоответствия восстанавливает модифицированные, поврежденные или отсутствующие файлы из локального хранилища компонентов. Увы, SFC не всесильна, более того, проблемы могут возникнуть с самой утилитой.

Одной из таких проблем является требование перезагрузки компьютера, смотрите скриншот.

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

Редактирование реестра

Одним из способов устранения этой неполадки является удаление подраздела RebootPending в ключе:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion

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

Рекомендуем воспользоваться для этих целей бесплатной утилитой ExecTI, с описанием которой вы можете познакомиться на странице нашего блога www.white-windows.ru/execti-utilita-dlya-zapuska-programm-s-pravami-trustedinstaller.

Можно обойтись и без ExecTI, получив на каталог RebootPending права доступа в самом редакторе реестра, но это менее удобный вариант.

После удаления подраздела RebootPending перезагрузите компьютер и выполните команду sfc /scannow повторно.

Удаление файла pending.xml

Альтернативным или дополнительным решением проблемы может стать удаление файла запланированных операций pending.xml.

Располагается этот файл в каталоге C:\Windows\winsxs

Если в работающей системе файл удалить не удается, загрузите компьютер с установочного диска, зайдите в среду восстановления, запустите командную строку и выполните команду удаления:

del D:\Windows\winsxs\pending.xml

Обратите внимание, что в загрузочной среде буквы разделов могут отличаться. Чаще всего раздел с Windows имеет букву D, но может быть и иначе, рекомендуем уточнить ее в Diskpart.

Кстати, просканировать систему средствами SFC вы можете тут же в среде восстановления, сразу же после удаления файла pending.xml.

Команда запуска сканирования в этом случае будет отличаться, но ненамного:

sfc /scannow /offbootdir=C:\ /offwindir=D:\windows

В качестве значения первого аргумента передается буква загрузочного раздела, а в качестве значения второго аргумента – буква раздела с Windows.