Для устранения повреждений целостности Windows в системе предусмотрена утилита SFC. Запущенная с ключом /scannow, она сравнивает контрольные суммы системных файлов и в случае несоответствия восстанавливает модифицированные, поврежденные или отсутствующие файлы из локального хранилища компонентов. Увы, SFC не всесильна, более того, проблемы могут возникнуть с самой утилитой.
Одной из таких проблем является требование перезагрузки компьютера, смотрите скриншот.
Сообщение «Ожидается восстановление системы, для завершения которого требуется перезагрузка» обычно появляется, когда обрабатываемые SFC файлы оказываются заняты каким-то процессом. В большинстве случаев перезагрузка действительно может помочь, но если этого не случилось, запланированное действие придется сбросить, в противном случае требование перезагрузки станет появляться вновь и вновь.
Редактирование реестра
Одним из способов устранения этой неполадки является удаление подраздела RebootPending в ключе:
HKLMSOFTWAREMicrosoftWindowsCurrentVersion
Так как его владельцем является системный процесс, встроенный редактор реестра нужно запускать с наивысшими правами.
Рекомендуем воспользоваться для этих целей бесплатной утилитой ExecTI, с описанием которой вы можете познакомиться на странице нашего блога www.white-windows.ru/execti-utilita-dlya-zapuska-programm-s-pravami-trustedinstaller.
Можно обойтись и без ExecTI, получив на каталог RebootPending права доступа в самом редакторе реестра, но это менее удобный вариант.
После удаления подраздела RebootPending перезагрузите компьютер и выполните команду sfc /scannow повторно.
Удаление файла pending.xml
Альтернативным или дополнительным решением проблемы может стать удаление файла запланированных операций pending.xml.
Располагается этот файл в каталоге C:Windowswinsxs
Если в работающей системе файл удалить не удается, загрузите компьютер с установочного диска, зайдите в среду восстановления, запустите командную строку и выполните команду удаления:
del D:Windowswinsxspending.xml
Обратите внимание, что в загрузочной среде буквы разделов могут отличаться. Чаще всего раздел с Windows имеет букву D, но может быть и иначе, рекомендуем уточнить ее в Diskpart.
Кстати, просканировать систему средствами SFC вы можете тут же в среде восстановления, сразу же после удаления файла pending.xml.
Команда запуска сканирования в этом случае будет отличаться, но ненамного:
sfc /scannow /offbootdir=C: /offwindir=D:windows
В качестве значения первого аргумента передается буква загрузочного раздела, а в качестве значения второго аргумента – буква раздела с Windows.
Загрузка…
- Здравствуйте админ! На моём компьютере установлена Windows 7 и периодически на ней выходят различные ошибки, также система может зависнуть или перезагрузиться в самый неподходящий момент. Вы посоветовали мне проверить винду на вирусы и произвести проверку целостности системных файлов. Вирусов у меня не оказалось, а вот с проверкой целостности всё оказалось намного интересней. Запускаю командную строку от имени администратора и ввожу команду sfc /scannow и через некоторое время командная строка выдаёт: «Защита ресурсов Windows обнаружила поврежденные файлы, но не может восстановить некоторые из них», что означает повреждение хранилища системных компонентов Windows 7. Знаю, что это самое хранилище можно в Windows 8.1, 10 восстановить с помощью системы обслуживания образов Dism, командами: Dism.exe /Online /Cleanup-image /ScanHealth и Dism.exe /Online /Cleanup-image /RestoreHealth. Думал, что в Windows 7 тоже так можно, ведь там есть Dism, но при вводе команды «Dism.exe /Online /Cleanup-image /ScanHealth» у меня выходит ошибка: «Ошибка 87. Параметр restorehealth не распознан в этом контексте».
- Здравствуйте админ! Произвожу восстановление целостности системных файлов Windows 7 с помощью sfc /scannow и выходит сообщение: «Для завершения восстановления системы требуется перезагрузка. Перезапустите систему Windows и выполните sfc еще раз», перезагружаюсь и опять тоже самое. Подумал, что это из-за повреждения хранилища компонентов Windows 7, хочу восстановить это хранилище, запускаю командную строку от имени администратора и ввожу команду: «Dism.exe /Online /Cleanup-image /ScanHealth» и выходит: «Ошибка 87. Параметр restorehealth не распознан в этом контексте». Что делать дальше?
Восстановление повреждённого хранилища системных компонентов возможно не только в Windows 8.1/10, но и в Windows 7
Привет друзья! В Windows 7, как и в Windows 8.1, 10 существует хранилище системных компонентов операционной системы — папка WinSxS, находящаяся по адресу C:WindowsWinSxS.
Если по каким-либо причинам (вирусы, системный сбой, нарушения в файловой системе) операционная система теряет важный системный файл, то этот файл тут же заменяется его работоспособной версией из хранилища системных компонентов (папки WinSxS).
При необходимости, пользователь сам может запустить проверку целостности системных файлов операционной системы с помощью командной строки (запущенной от администратора) командой sfc /scannow. Средство sfc произведёт проверку целостности системных файлов и если повреждения обнаружатся, то результат будет выглядеть так: «Защита ресурсов Windows обнаружила поврежденные файлы и успешно их восстановила», но в некоторых случаях ответ будет другим: «Защита ресурсов Windows обнаружила поврежденные файлы, но не может восстановить некоторые из них», что означает повреждение хранилища системных компонентов операционной системы (папки WinSxS).
В этом случае вводим в командной строке (запущ. от администратора) команду:
Dism.exe /Online /Cleanup-image /ScanHealth
которая в свою очередь проверит и восстановит целостность самого хранилища системных компонентов
Windows 7.
Примечание: Начиная с Windows 8 операционная система получила возможность восстанавливать поврежденное хранилище компонентов с помощью системы обслуживания образов Dism. Для восстановления хранилища нужно ввести две команды:
Dism.exe /Online /Cleanup-image /ScanHealth — проверяет состояние целостности хранилища компонентов.
Dism.exe /Online /Cleanup-image /RestoreHealth — восстанавливает хранилище.
В Windows 7 тоже существует данная возможность, но в Windows 7 обе эти команды объединены в одну и для восстановления хранилища компонентов необходимо воспользоваться только командой
Dism /Online /Cleanup-Image /ScanHealth, но эта команда не сработает и вы получите ошибку: «Ошибка 87. Параметр ScanHealth не распознан в этом контексте», если в вашей Windows 7 не установлено обновление KB2966583.
Скачайте данное обновление KB2966583 по ссылке
https://support.microsoft.com/ru-ru/kb/2966583
выберите обновление в соответствии с разрядностью вашей операционной системы, например, у меня установлена Windows 7 64-бит, значит я скачаю пакет для всех поддерживаемых 64-разрядных версий Windows 7.
Загрузить пакет.
Выбираем язык — Русский и жмём Download.
- Remove From My Forums
-
Question
-
hi,
i have server 2012 r2 standard.
i have an error with veeam software so their support
asked me to run sfc/scannow.
however, when i ran it, i get the following error:
«There Is System Repair Pending Which Requires Reboot To Complete. Restart Windows And Run SFC Again»
please you advice,
many thanks,
zachi
All replies
-
-
Proposed as answer by
Tuesday, June 6, 2017 3:26 PM
-
Proposed as answer by
-
Hi,
According to my research, the system checks for pending system repair files when initiated SFC. Thus, if we could delete that/those pending file(s), SFC would work.
Here is how you delete pending system repair file.
1. Open Command Prompt at boot.
2. Type following command and hit Enter key:
dism.exe /image:c: /cleanup-image /revertpendingactions
Note: Substitute C: with your system root drive.
You’ll see The operation completed successfully message when execution finishes. You can now try to run SFC scan and repair your system using it, no issues will be countered.
In case if problem still persists, please try to use registry manipulation.
There is a registry key for pending system repair, which Windows always checks when you initiate SFC at boot. So you need to delete that key as well, if deleting only the pending files not works for you. Try these steps for that:
1. Open Command Prompt at boot
2. Type regedit command and hit Enter key to open Registry Editor at boot.
3. Navigate to following registry key:
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionRebootPending
4. Right click on RebootPending key and select Delete. Provide your confirmation with Yes here.
Minimize Registry Editor and now try to run SFC scan, it should propagate as expected.
Best Regards,
Alvin Wang
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact
tnmff@microsoft.com.-
Proposed as answer by
Alvwan
Tuesday, June 6, 2017 3:26 PM
-
Proposed as answer by
-
Hi,
Just checking in to see if the information provided was helpful. Please let us know if you would like further assistance.
Best Regards,
Alvin Wang
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact
tnmff@microsoft.com. -
For anyone who encounters this problem. i tried all of the above and still had the same issue. i finally found this link here:
https://superuser.com/questions/608371/how-do-i-recover-from-repair-pending-error-in-sfc
I did only the following: after DISM failed to run at all and would not work.
del d:windowswinsxspending.xml del x:windowswinsxspending.xml
and then
sfc /SCANNOW /OFFBOOTDIR=c: /OFFWINDIR=d:WindowsD is the drive letter assigned to my C drive when starting in Repair Console. Now SFC is running. I dont know if it will actually do anything.
Robert
Robert
-
Proposed as answer by
81vette
Monday, April 16, 2018 2:52 PM
-
Proposed as answer by
-
If you are booting for Windows repair from a LiveCD/ISO to run SFC than you may need to specify the OFFBOOTDIR and OFFWINDIR options, just as Microsoft’s SFC help example indicates:
«e.g. sfc /SCANFILE=d:windowssystem32kernel32.dll /OFFBOOTDIR=d: /OFFWINDIR=d:windows»
Alternately,
sfc /SCANNOW /OFFBOOTDIR=d: /OFFWINDIR=D:WINDOWS
In my scenario, I could not log into windows 7 as it would hang, or bluescreen and reboot. This above SFC from a LiveCD fixed the corrupt files, but until I specified the /OFFBOOTDIR or /OFFWINDIR I had the same «System Repair Pending Which Requires
Reboot To Complete»… obstacle as you. -
Hi Five-NineTips,
If you are having BSOD or other problems they can be troubleshooted.
Please open a new thread and post a link into this thread.
-
Thanks mate! That did the trick for me. :o)
- Remove From My Forums
-
Question
-
hi,
i have server 2012 r2 standard.
i have an error with veeam software so their support
asked me to run sfc/scannow.
however, when i ran it, i get the following error:
«There Is System Repair Pending Which Requires Reboot To Complete. Restart Windows And Run SFC Again»
please you advice,
many thanks,
zachi
All replies
-
-
Proposed as answer by
Tuesday, June 6, 2017 3:26 PM
-
Proposed as answer by
-
Hi,
According to my research, the system checks for pending system repair files when initiated SFC. Thus, if we could delete that/those pending file(s), SFC would work.
Here is how you delete pending system repair file.
1. Open Command Prompt at boot.
2. Type following command and hit Enter key:
dism.exe /image:c: /cleanup-image /revertpendingactions
Note: Substitute C: with your system root drive.
You’ll see The operation completed successfully message when execution finishes. You can now try to run SFC scan and repair your system using it, no issues will be countered.
In case if problem still persists, please try to use registry manipulation.
There is a registry key for pending system repair, which Windows always checks when you initiate SFC at boot. So you need to delete that key as well, if deleting only the pending files not works for you. Try these steps for that:
1. Open Command Prompt at boot
2. Type regedit command and hit Enter key to open Registry Editor at boot.
3. Navigate to following registry key:
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionRebootPending
4. Right click on RebootPending key and select Delete. Provide your confirmation with Yes here.
Minimize Registry Editor and now try to run SFC scan, it should propagate as expected.
Best Regards,
Alvin Wang
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact
tnmff@microsoft.com.-
Proposed as answer by
Alvwan
Tuesday, June 6, 2017 3:26 PM
-
Proposed as answer by
-
Hi,
Just checking in to see if the information provided was helpful. Please let us know if you would like further assistance.
Best Regards,
Alvin Wang
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact
tnmff@microsoft.com. -
For anyone who encounters this problem. i tried all of the above and still had the same issue. i finally found this link here:
https://superuser.com/questions/608371/how-do-i-recover-from-repair-pending-error-in-sfc
I did only the following: after DISM failed to run at all and would not work.
del d:windowswinsxspending.xml del x:windowswinsxspending.xml
and then
sfc /SCANNOW /OFFBOOTDIR=c: /OFFWINDIR=d:WindowsD is the drive letter assigned to my C drive when starting in Repair Console. Now SFC is running. I dont know if it will actually do anything.
Robert
Robert
-
Proposed as answer by
81vette
Monday, April 16, 2018 2:52 PM
-
Proposed as answer by
-
If you are booting for Windows repair from a LiveCD/ISO to run SFC than you may need to specify the OFFBOOTDIR and OFFWINDIR options, just as Microsoft’s SFC help example indicates:
«e.g. sfc /SCANFILE=d:windowssystem32kernel32.dll /OFFBOOTDIR=d: /OFFWINDIR=d:windows»
Alternately,
sfc /SCANNOW /OFFBOOTDIR=d: /OFFWINDIR=D:WINDOWS
In my scenario, I could not log into windows 7 as it would hang, or bluescreen and reboot. This above SFC from a LiveCD fixed the corrupt files, but until I specified the /OFFBOOTDIR or /OFFWINDIR I had the same «System Repair Pending Which Requires
Reboot To Complete»… obstacle as you. -
Hi Five-NineTips,
If you are having BSOD or other problems they can be troubleshooted.
Please open a new thread and post a link into this thread.
-
Thanks mate! That did the trick for me. :o)
28.11.2018 windows | для начинающих
Проверка целостности системных файлов Windows 10 может пригодиться в том случае, если у вас есть основания полагать, что такие файлы были повреждены или же возникли подозрения о том, что какая-либо программа могла изменить системные файлы операционной системы.
В Windows 10 присутствует два инструмента для проверки целостности защищенных системных файлов и их автоматического восстановления при обнаружении повреждений — SFC.exe и DISM.exe, а также команда Repair-WindowsImage для Windows PowerShell (использующая DISM для работы). Вторая утилита служит дополнением первой, в случае, если SFC не удается восстановить поврежденные файлы.
Примечание: описываемые в инструкции действия безопасны, однако, в том случае, если до этого вы проделывали какие-либо операции, связанные с заменой или изменением системных файлов (например, для возможности установки сторонних тем и т.п.), в результате восстановления системных файлов, эти изменения будут отменены.
Что такое sfc /scannow?
Практически – это программа, которая, как и многие из других системных располагается в папке
C:WindowsSystem32
и является неотъемлемой частью механизма защиты ресурсов Windows, который охраняет реестровые ключи и отдельные параметры от поражения (равно как и критически важные системные файлы). Если только после запуска утилиты та обнаружит изменения в этих файлах или параметрах, она – утилита – приступит (по команде пользователю) к исправлению ситуации. Для этого сама Windows всегда держит кэшированную копию файлов в системной папке с одноимённым названием. Есть желание – взгляните:
C:WindowswinsxsBackup
Выводы
Очевидно, что утилита sfc не является панацеей от всех видов проблем, возникающих в операционной системе Windows. Нередки случаи, когда sfc не может найти никаких повреждений в системных компонентах, или же находит и устраняет их, однако ошибки возникают вновь. Подобное поведение намекает на то, что сам механизм компонентов в операционной системе Windows довольно «сырой» и находится в перманентной «бете», о чем разработчики предпочитают молчать, просто поддерживая его в более-менее работоспособном состоянии и дорабатывая по мере своих возможностей от версии к версии. Эта догадка подтверждается большим количеством ошибок, которые невозможно исправить автоматизированными системными средствами. В этом случае, как и в случае, когда утилита sfc не обнаружила в системе поврежденных компонентов, при сохранении тенденции к нестабильной работе системы стоит рассмотреть иные способы диагностики.
System File Checker = Sfc.exe = sfc /scannow
Для запуска проверки системных файлов откройте cmd от имени админа:
В окне консоли пишем знакомую команду:
sfc /scannow
Утилита проверит нужное, в случае обнаружения несоответствия будет проведена подмена после перезагрузки. У SFC есть маленькие хитрости и скрытые нюансы. Любому из тех, кто прибегает к возможностям этого инструмента, следуют помнить, что если sfc не справилась сразу, не пренебрегите запустить её повторно. Но на этот раз отключите режим Быстрой загрузки. Оптимально количество попыток – 3. Только после трёх неудачных следует приступать к остальным средствам.
Ошибка утилиты Sfc.exe: Для завершения восстановления системы требуется перезагрузка…
Восстановление поврежденного хранилища компонентов Windows 10/Server 2020 с помощью PowerShell
В версии PowerShell в Windows 10 и Windows Server 2016/2019 есть аналоги рассмотренных выше команд DISM. Для сканирования хранилища компонентов и поиска повреждений в образе выполните:
Repair-WindowsImage -Online –ScanHealth
Если ошибок в хранилище компонентов не обнаружено, появится сообщение:
ImageHealth State: Healthy
Для запуска восстановления системных компонентов и файлов наберите:
Repair-WindowsImage -Online -RestoreHealth
При отсутствии доступа к интернету эта команда может зависнуть в процессе восстановления образа. Вы можете восстановить системные компоненты из локальной копии образа Windows в виде WIM/ESD файла, скопированного с установочного ISO образа Windows 10: Repair-WindowsImage -Online -RestoreHealth -Source E:sourcesinstall.wim:1
Где, 1 – индекс используемой у вас редакции Windows из WIM или ESD файла (список редакций Windows в WIM файле можно вывести так: Get-WindowsImage -ImagePath «E:sourcesinstall.wim»).
Результаты проверки sfc /scannow
Результаты работы утилиты будут сопровождаться некоторыми сообщениями в зависимости от того, успешно ли прошло восстановление или в работе произошёл сбой. Но сразу запомните: не торопитесь паниковать в случае неудачных выводов утилиты. Запустите sfc.exe несколько раз и в разных режимах.
- Для завершения восстановления системы требуется перезагрузка. Перезапустите систему Windows и выполните sfc ещё раз:
Окно означает, что в текущем сеансе окно консоли можно закрыть: утилита запустится только после ПЕРЕЗАГРУЗКИ ( после ВЫКЛЮЧЕНИЯ компьютера ситуация может повториться). Причина сообщения ясна – файлы кэша в данную минуту обрабатываются системой (“заняты” каким-то процессом/ами: Windows элементарно ждёт применения только что установленных обновлений).
Проблема, которую вы пытаетесь разрешить, лежит, по-видимому, в иной плоскости.
- Защита ресурсов Windows обнаружила поврежденные файлы и успешно их восстановила.
Наиболее частое повреждение файлов – либо неправильная работа (а чаще удаление) сторонних программ в/из Windows, а также сбои в работе жёсткого диска (см. “Плохие секторы жёсткого диска“). И утилита частично эти проблема разрешила, подменив на исходные. Настоятельно рекомендую взглянуть на лог утилиты по адресу в консоли – там могут быть интересные детали для разрешения вероятных в последующем ошибок:
C:WindowsLogsCBSCBS.log
- Защита ресурсов Windows обнаружила поврежденные файлы, но не может восстановить некоторые из них. При этом система отправляет вас в лог программы за подробностями. Реже, но также встречается ещё более категорическое
- Защита ресурсов Windows не может выполнить запрошенную операцию.
Большинство пользователей подобное “заявление” ставит в тупик. Я могу предложить вам несколько вариантов действий:
- Иногда камнем преткновения является аудиослужба Windows, причём в Windows 10 это сплошь и рядом. Откройте консоль cmd от имени администратора и введите две последовательные команды:
sc config trustedinstaller start=auto net start trustedinstaller
- Сразу проверяем готовность соответствующей службы. Набираем (в строке Найти/Выполнить) команду на открытие консоли
services.msc
Ищем в списке служб Установщик модулей Windows. Тип запуска: Вручную.
- Проверьте, на месте ли папки (и не пусты ли они) PendingDeletes и PendingRenames в директории
C:WindowsWinSxSTemp
- Повторите операцию по запуску sfc /scannow, но уже в Безопасном режиме. Запуск Windows в щадящем режиме можно запланировать прямо сейчас из другой системной утилиты msconfig:
Если результат окажется тем же, возможно попробовать сдвинуть запуск утилиты восстановления ещё ближе к запуску Windows: на этот раз sfc /scannow может проверить файлы ещё до загрузки системы. Однако для этого вам потребуется загрузочный носитель с той копией Windows, которая у вас установлена:
вставьте загрузочный диск/флешку
удостоверьтесь, что система на жёстком диске видна с флешки/дисковода
Обратите внимание на букву Локального диска (D) в столбце Папка: запомните её!
ищем консоль в параметрах восстановления
и вводим команду на офлайн проверку вашей Windows:
sfc /scannow /offbootdir=d: /offwindir=d:windows
где d – имя локального диска на компьютере/ноутбуке. Обратите внимание: эта команда позволит вам проверять внешние носители с установленной Windows.
Восстановление с внешнего носителя
Добраться до «Recovery Mode» можно несколькими способами. Самым надежным будет загрузка с флешки или диска, на котором находится официальный дистрибутив Win10.
- После запуска процедуры установки после выбора русского языка слева снизу появится надпись «Восстановление системы».
- Ее нажатие приводит вот к этому окну.
- Далее — запуск командной строки и ввод следующего набора команд:
- diskpart;
- list volume;
- exit;
- sfc /scannow /offbootdir=C: /offwindir=C:Windows.
Это нужно для того, чтобы указать командной строке с загрузочного диска, где именно находится система, которая нуждается в починке. C:Windows является значением по умолчанию, но в принципе установочная папка может находиться где угодно.
Длительность сканирования зависит от множества параметров: от скорости работы флэшки до уровня неполадок в проверяемой системе.
Примечание! Учтите, что пока мигает указатель подчеркивания на последней строчке, компьютер не завис и выполняет работу.
Путь расположения лог-файла sfc.exe вы уже знаете. Чтобы его не искать в терниях системы, по аналогии с официальной справкой по sfc.exe я предлагаю вам набрать такую команду в консоли от имени админа:
findstr /c:»[SR]» %windir%LogsCBSCBS.log >»%userprofile%Desktopсправка.txt»
На Рабочем столе появится текстовый файл, в котором вы найдёте подробности того, с чем команда sfc /scannow столкнулась:
Большинство записей (а в “холостом” режиме работы утилиты) в логах должны выглядеть так:
Дата Время Тип Режим доступа Подробности
А вот и проблема “…но не может восстановить некоторые из них“:
для увеличение изображения откройте его в новой вкладке
где самые частые содержания в строках такие:
- beginning verifiyng … – проверка файлов в текущем блоке начата
- cannot repaire member file… – не могу починить файл имя.расширение
- file is missing – файл отсутствует
- hash mismatch – хэш-код файла не соответствует системному (“родному”)
- this component was referenced by… – компонент изначально относился к… (на него ссылался…)
- verifying 100 components – проверка 100 составляющих блока завершена успешно
- repairing corrupted file – ремонт повреждённого файла
- repair complete – ремонт закончен
Пробуем восстановить файл вручную.
Восстановление файлов из списка логов sfc вручную.
Напоминаю, что логи sfc содержат в себе только информацию о СИСТЕМНЫХ файлах: часто эта программа бесполезна против части подгружаемых со стороны библиотек DirectX, .Net и прочего. Исправит она и не все файлы для установленных программ, если такая беда случится.
Но если логами sfc битый или пустой/отсутствующий файл зафиксирован, его можно исправить. Повторяю: если вы сидите в Windows 10, у вас есть более быстрый вариант. Тут же в cmd наберите:
dism /online /cleanup-image /restorehealth
В Windows 7 придётся попотеть. Сначала получите к нему доступ и права на работу с файлом:
takeown /f полный-путь-к-файлу/папке
и
icacls полный-путь-к-файлу/папке /GRANT Администраторы:F
Например, система обнаружила повреждение файла System.Management.Automation.dll и не смогла его починить.
откройте в новой вкладке
Попробуем его отыскать. В логах приводится подробная о нём информация. Для таких целей идеально подходит средство поиска файлов из консоли же:
cd dir имя-файла /s
Консоль, скорее всего, выдаст несколько вариантов (заметьте, что нередко в Windows папка таковой не является – это может быть всего лишь системный узел или вид “с нескольких ракурсов”). Так что, опираясь на логи, откиньте ненужные результаты. Если всё ещё не удаётся его вычленить, используйте повторную проверку каждого из “подозреваемых” с помощью той же sfc.exe в формате (смотрите справку):
sfc /verifyfile=полный-путь-к-файлу
Остаётся обнаружить и заполучить искомый файл. Для того есть несколько способов:
- взять у друга с такой же Windows (попросить на добропорядочном форуме)
- скачать аккуратно из сети, не нарвавшись на бяку
- забрать с установочного диска/флешки/образа (тогда проще уж просто запустить sfc.exe с загрузочного диска)
После того, как вы утвердились в выборе, замените повреждённый файл на обновлённый командой в cmd в формате:
copy полный-путь-к-хорошему-файлу полный-путь-к-плохому-файлу
Не забывая о правильности вводимых путей к обоим файлам, включая буквы томов (логических дисков).
Замена системного файла вручную в Windows
Если не получилось восстановить поврежденный файл средством sfc.exe, попробуйте заменить поврежденный файл вручную. Сначала найдите информацию о неисправном файле, которая содержится в файле «CBS.log».
Для ручной замены файла нам понадобится точно такая версия Windows, откуда необходимо скопировать гарантированно работоспособный файл на свой компьютер.
Я поместил исправный файл с другого ПК в корень Локального диска «C:» (можете использовать другой диск или другое место) своего компьютера. Расположение файла: «C:winml.dll», оно нам понадобится для выполнения команды.
Запустите командную строку от имени администратора.
Для принятия файла во владение введите команду:
takeown /f C:полный_путь_и_имя_файла
В моем случае, если на ПК поврежден файл «winml.dll», путь будет таким:
takeown /f C:WindowsSystem32winml.dll
Теперь мне нужно получить полный доступ к файлу:
icacls C:полный_путь_и_имя_файла /Grant Administrators:F
Для этого, я ввожу команду:
icacls C:WindowsSystem32winml.dll /Grant администраторы:F
Теперь необходимо заменить поврежденный файл работоспособной копией. Для этого введите команду:
copy путь_и_имя_работоспособного_файла путь_и_имя_поврежденного_файла
Я выполнил следующую команду:
copy C:winml.dll C:WindowsSystem32winml.dll
Для подтверждения замены файла, введите: «Yes».
Если не получается выполнить восстановление системных файлов при помощи утилиты sfc.exe, переустановите Windows.
Добрый день!
Установлена Windows 7 Профессиональная, 32-разрядная, лицензионная (коробочное издание).
С недавнего времени (точную дату определить трудно) стал замечать, что при включении/выключении Windows появляется надпись «Идёт настройка Windows. Не выключайте компьютер», что увеличивает загрузку/выгрузку системы. Грешу на какое-то обновление (включено автоматическое обновление Windows), поскольку никакие программы в ближайший месяц не устанавливались и не удалялись. При попытке проверить системные файлы командой sfc /scannow пишет следующее:
«Для завершения восстановления системы требуется перезагрузка. Перезапустите систему Windows и выполните sfc еще раз»
Перезагрузка ничего не даёт. Пробовал загрузиться с установочного диска, выбрать пункт «Восстановление системы», затем «Командная строка» и далее снова sfc /scannow или sfc /scannow /offbootdir=D: /offwindir=D:windows . Результат то же: «Для завершения восстановления системы требуется перезагрузка. Перезапустите систему Windows и выполните sfc еще раз».
Ещё пробовал восстановление повреждённого хранилища системных компонентов командой DISM.exe /Online /Cleanup-image /ScanHealth , после чего компьютер мучительно долго загружался, но в результате тоже ничего не изменилось. Вопрос следующий: можно ли как-нибудь ещё запустить команду sfc /scannow? Очень не хочется переустанавливать систему!
P.S. ТОЧЕК ВОССТАНОВЛЕНИЯ СИСТЕМЫ НЕТ!
Добавлено через 7 часов 7 минут
Решение нашёл самостоятельно, здесь подробно расписан алгоритм действий: http://maks-1.com/windows/wind… pasnomhtml И хотя у меня симптомы были несколько иные — Windows всё же запускалась, — тем не менее лечение оказалось схожим. Возможно кому-либо пригодится.
__________________
Помощь в написании контрольных, курсовых и дипломных работ, диссертаций здесь
В процессе жизненного цикла операционной системы Windows, периодически возникает необходимость установки/удаления того или иного программного обеспечения. Понятно, что программное обеспечение достаточно многообразно и порой довольно сложно оценить степень его влияния на систему, одни программы являются достаточно безобидными, другие же могут вносить в систему настолько существенные изменения, что в пору говорить о масштабном системном обновлении. К тому же, если эксплуатационный цикл системы достаточно продолжителен, то в процессе установки/удаления/замены различных обновлений и ПО можно наблюдать накопление/удаление/повреждение различных версий системных библиотек, всевозможных ключевых системных структур (реестра, библиотек, исполняемых модулей). Особое внимание стоит обратить на то, что критично-важные компоненты операционной системы могут повреждаться, либо удаляться вовсе в следствии деятельности вредоносного программного обеспечения (вирусы, трояны), разнородных ошибок в работе программной и аппаратной частей компьютера. Во всем многообразии этого броуновского движения, крайне сложно спрогнозировать последствия подобных изменений системы, возникшие на каком-либо этапе проблемы могут оставаться определенное время незамеченными, либо вовсе никогда не проявить себя, однако чаще всего случается, что спустя некоторое время мы начинаем наблюдать довольно таки интересные «нештатные ситуации», в которых операционная система ведет себя довольно странно.
Проблема сохранения работоспособности ключевых системных компонентов и, как следствие, операционной системы в целом, стояла перед разработчиками Microsoft Windows с самого того дня, когда первые версии ОС начинали своё знакомство с широкой аудиторией, ведь по началу сама система была и вовсе беззащитна от вмешательства различного рода стороннего программного обеспечения, инсталлируемого с использованием административных привилегий и беззастенчиво переписывающего своими компонентами «родные» системные модули. Понятно, что столь серьезная проблема требовала своего скорейшего решения и в итоге Microsoft начали предоставлять изнемогающей от глюков общественности различные методы выхода из ситуации. Это были, по-началу, и службы контроля за целостностью важных системных файлов, и утилиты привидения их к эталонным версиям, в конечном итоге был разработан принцип компонентизации или модуляризации. «-Ну Конечно»,- скажете Вы,- «зачем нам все это? Мы всегда можем решить проблему и более кардинальным образом, ведь у нас в запасе есть проверенное десятилетиями, безотказное средство под названием «переустановка», либо такое как возврат к ранее созданной точке восстановления». Можно восстановить из ранее созданного образа системы, но этим могут похвастаться лишь самые педантичные, а у обычных обывателей довольно редко резервный образ бывает актуальным (если вообще присутствует), в любом случае, придется затратить свое драгоценное личное время на приведение системы к необходимому состоянию. Да, описанные методы действительно актуальны, однако подобное решение и так рассматривалось разработчиками как выход из сложившейся ситуации довольно продолжительное время 
Все это не делает саму систему стабильнее, а ведь одна из задач авторов хорошей ОСи — сделать её отказоустойчивой. Но в итоге разработчики Microsoft предоставили пользователям средство под названием sfc, о котором и пойдет речь в данной статье.
Sfc (System file checker) — утилита проверки целостности системных файлов операционной системы Windows. Выполняет проход по каталогам, содержащим ключевые системные файлы операционной системы и производит восстановление поврежденных или отсутствующих системных файлов.
В общем случае, утилита выполняет сканирование и восстановление поврежденных или отсутствующих системных файлов путем сравнения экземпляра, установленного в системе с эталонной версией, размещенной в специализированном защищенном хранилище системных компонентов.
Запуск проверки целостности файлов
Все приведенные в данном разделе команды необходимо выполнять от имени учетной записи, входящей в группу локальных администраторов.
Поскольку sfc является консольной утилитой (утилитой командной строки), то и запускать её следует из командного интерпретатора cmd. Для выполнения комплексной проверки всех системных файлов, выполните следующую команду:
sfc /scannow
Утилита стартует процесс проверки системных файлов, в ходе которого будут заменяться/восстанавливаться поврежденные/отсутствующие файлы. Теперь оставьте окно в покое и дождитесь окончания процесса проверки.
Естественно что утилита sfc возвращает статус завершения процедуры проверки системных файлов на консоль в виде строки, отражающей результат проверки. На приведенной выше картинке данная строка результата выделена красным цветом. Очевидно, что от того, как именно завершилась проверка, зависят и дальнейшие наши действия по восстановлению работоспособности системы. Давайте разберем возможные результаты и методы реакции на них:
- Защита ресурсов Windows не обнаружила нарушений целостности. Это сообщение говорит о том, что WRP не смогла найти каких-либо повреждений в операционной системе и стоит задуматься о диагностировании системы другими способами;
- Защита ресурсов Windows не может выполнить запрошенную операцию. Утилита sfc сообщает нам, что WRP не смогла выполнить необходимые операции восстановления. В этом случае можно попробовать:
- перезагрузить систему в защищенный режим и запустить sfc из-под него;
- дополнительно удостоверьтесь что папки PendingDeletes и PendingRenames присутствуют в директории %WinDir%WinSxSTemp;
- проверьте что у sfc (пользователь
TrustedInstaller) есть разрешения на доступ к директории %WinDir%WinSxS и множеству вложенных поддерикторий командой icacls c:/windows/winsxs;
- Защита ресурсов Windows обнаружила поврежденные файлы и успешно их восстановила. В этом случае процесс завершился удачно, ради интереса Вы можете ознакомиться с результатами работы утилиты sfc в файле %WinDir%LogsCBSCBS.log;
- Защита ресурсов Windows обнаружила поврежденные файлы, но не может восстановить некоторые из них. Утилита сообщает нам о том, что WRP не смогла восстановить некоторые несоответствия. В этом случае у нас, с большой вероятностью, повреждено хранилище компонентов (WinSxS) и у нас имеется два возможных варианта решения проблемы, которые описаны в разделе Восстановление хранилища компонентов.
- Для завершения восстановления системы требуется перезагрузка. Перезапустите систему Windows и выполните sfc еще раз. Обычно подобная ошибка появляется при запуске из-под ограниченного рабочего окружения, такого, например, как среда восстановления (Windows RE). Для решения проблемы попробуйте запустить утилиту sfc с дополнительными параметрами, как описано в разделе Запуск из среды восстановления.
- Защите ресурсов Windows не удается запустить службу восстановления. Ошибка говорит нам о том, что службы, от которых зависит работа утилиты, не могут запуститься. Службы, которые могут являться причиной ошибки: «Теневое копирование тома», «Установщик модулей Windows» и «Установщик Windows». Проверьте, возможен ли вообще запуск данных служб, в случае возникновения проблем проверьте зависимости. Иногда причина может крыться в запуске консоли, из-под которой выполняется команда sfc, с ограниченными правами.
- В данный момент выполняется другая операция обслуживания или восстановления. Дождитесь ее завершения и повторно запустите SFC. Информационное сообщение информирует о том, что в данный момент стек обслуживания занят. На низком уровне единственное приложение, которое может работать со стеком обслуживания, это модуль TrustedInstaller.exe. Соответственно, когда происходит попытка одновременного обращения к функциям стека обслуживания другого источника, возникают проблемы доступа. Но если Вам уж очень необходимо освободить стек для проведения неотложных манипуляций, то просто попробуйте снять через Диспетчер задач процесс с именем TrustedInstaller.exe, однако имейте в виду, что в этом случае возможны проблемы!!
Если в процессе проверки/восстановления в самой утилите sfc возникли ошибки (описанные выше), то можно руководствоваться простым алгоритмом:
- попытаться повторно запустить её еще пару-тройку раз. В практике нередко наблюдались случаи, когда в ходе очередного запуска sfc все же удавалось нормально выполнить свою работу.
- если все же устойчиво получаем ошибки, то производим анализ результатов в файле %WinDir%LogsCBSCBS.log.
- по результатам анализа результатов в файле отчета производим ручное восстановление недостающих/битых компонентов. Возможно привлечение этапов работы с компонентной моделью Windows, как описано в этом хабе.
Часто алгоритм восстановления работоспособности не так тривиален, и приходится выполнять шаги по несколько раз. Например, запустили sfc, получили отчет, прошлись dism до момента, пока он не сообщает о том, что ошибок нет, затем снова sfc и по результатам ручное восстановление из рабочей системы недостающих/битых файлов. И так по кругу до появления результатов sfc: Защита ресурсов Windows обнаружила поврежденные файлы и успешно их восстановила или Защита ресурсов Windows не обнаружила нарушений целостности.
Фактически утилита sfc в процессе работы производит обход системных директорий (таких как %Windir%System32), замену (удаление) некорректных образов системных библиотек и синхронизацию жестких ссылок на актуальные версии библиотек в хранилище компонентов WinSxS. Фактически SFC в своей работе опирается на контрольные суммы файлов, сравнивая их с копиями, которые Windows хранит в специальной базе.
Анализ результатов
Для того, чтобы лицезреть результаты работы утилиты sfc нам предлагается открыть файл журнала компонентной модели %WinDir%LogsCBSCBS.log любым доступным в системе текстовым редактором.
Возможна ситуация, когда по причине некорректной работы сервиса обслуживания, файл отчетов CBS.log не успевает «ротироваться» и раздувается до немыслимых величин. На одной из систем я наблюдал аж 990Мб живых записей. Для открытия файла подобного объема придется постараться!
Сразу спешу предупредить, что в данный лог-файл пишет несколько источников, поэтому в файле достаточно много лишней для нас информации. Для того, чтобы отфильтровать из этого огромного объема интересующую нас информацию, необходимо поиском найти дату и время конкретно нашего запуска sfc. Дата и время фигурируют в файле в каждой записи в первых двух параметрах:
|
. . . 2015—12—23 15:25:51, Info CBS Starting TrustedInstaller initialization. 2015—12—23 15:25:51, Info CBS Loaded Servicing Stack v6.1.7601.18766 with Core: C:Windowswinsxsamd64_microsoft—windows—servicingstack_31bf3856ad364e35_6.1.7601.18766_none_675144b3de10d6f7cbscore.dll . . . |
Однако это еще не все, следующее неудобство в самостоятельном анализе результатов работы утилиты sfc заключается в том, что процесс, порожденный sfc, записывает в файл отчета в рамках нашей сессии довольно много лишней информацию обо всей активности WRP. Однако нам то необходимо найти информацию лишь об обнаруженных ошибках. Поэтому следующим шагом мы должны идентифицировать записи о интересующей нас сессии проверки утилиты sfc, для этого надо ориентироваться на указание в строках префикса восстановления [SR], располагающийся сразу после кода операции. Информация в файле отчета группируется в своеобразные контейнеры, представляющие из себя группу записей по устранению какой-либо проблемы либо группу родственных проблем. Судя по всему, применяется два основных типа контейнеров. В первом из них содержится информация по восстановлению компонентов и границы блоков помечаются как:
|
<дата> <время>, Info CSI xxxxxxxx [SR] Repairing XX components . . . <дата> <время>, Info CSI xxxxxxxx [SR] Repair complete |
, во втором содержится информация по проверке компонентов и границы блоков помечаются так:
|
<дата> <время>, Info CSI xxxxxxxx [SR] Verifying XX components . . . <дата> <время>, Info CSI xxxxxxxx [SR] Verify complete |
информация по обнаруженным ошибкам может встречаться в обеих типах контейнеров, поэтому анализировать их надо оба. Но анализировать исходный файл с большим количеством избыточной информации довольно трудно, поэтому с целью облегчить техническому специалисту работу по анализу журнала проверки, имеется рекомендация от разработчиков, советующих фильтровать весь массив записей отчета. Для этого наберите вручную в консоли команду:
findstr /c:»[SR]» %windir%logscbscbs.log > c:sfcdetails.txt
в результате выполнения приведенной команды, в корне диска C: будет создан файл sfcdetails.txt, содержащий только лишь те строки исходного файла, которые содержат префикс [SR], что существенно упрощает поиск необходимой нам информации об обнаруженных утилитой ошибках. В получившемся после фильтрации файле ищем записи о неудачных попытках восстановления:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
. . . 2020—05—30 12:34:22, Info CSI 000005ac [SR] Beginning Verify and Repair transaction 2020—05—30 12:34:22, Info CSI 000005ad Hashes for file member SystemRootWinSxSx86_microsoft—windows—mfplat_31bf3856ad364e35_6.1.7601.24499_none_f8e9d951cb11bac7mfplat.dll do not match actual file [l:20{10}]«mfplat.dll» : Found: {l:32 b:1XsFZPITt9hYGb0SUMHPa32OJGefp2O0TdRWcHelghE=} Expected: {l:32 b:T9qLTbsZEERFvFGvivtc2yfwDwoRncRznjbIZZaDzzI=} 2020—05—30 12:34:22, Info CSI 000005ae [SR] Cannot repair member file [l:20{10}]«mfplat.dll» of Microsoft—Windows—MFPlat, Version = 6.1.7601.24499, pA = PROCESSOR_ARCHITECTURE_INTEL (0), Culture neutral, VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type neutral, TypeName neutral, PublicKey neutral in the store, hash mismatch 2020—05—30 12:34:22, Info CSI 000005af Hashes for file member SystemRootWinSxSx86_microsoft—windows—mfplat_31bf3856ad364e35_6.1.7601.24499_none_f8e9d951cb11bac7mfplat.dll do not match actual file [l:20{10}]«mfplat.dll» : Found: {l:32 b:1XsFZPITt9hYGb0SUMHPa32OJGefp2O0TdRWcHelghE=} Expected: {l:32 b:T9qLTbsZEERFvFGvivtc2yfwDwoRncRznjbIZZaDzzI=} 2020—05—30 12:34:22, Info CSI 000005b0 [SR] Cannot repair member file [l:20{10}]«mfplat.dll» of Microsoft—Windows—MFPlat, Version = 6.1.7601.24499, pA = PROCESSOR_ARCHITECTURE_INTEL (0), Culture neutral, VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:31bf3856ad364e35}, Type neutral, TypeName neutral, PublicKey neutral in the store, hash mismatch 2020—05—30 12:34:22, Info CSI 000005b1 [SR] This component was referenced by [l:162{81}]«Package_130_for_KB4507456~31bf3856ad364e35~amd64~~6.1.1.8.4507456-271_neutral_LDR» 2020—05—30 12:34:22, Info CSI 000005b2 [SR] This component was referenced by [l:164{82}]«Package_952_for_KB4534310~31bf3856ad364e35~amd64~~6.1.1.9.4534310-3286_neutral_LDR» 2020—05—30 12:34:22, Info CSI 000005b3 [SR] This component was referenced by [l:164{82}]«Package_351_for_KB4534310~31bf3856ad364e35~amd64~~6.1.1.9.4534310-1407_neutral_LDR» 2020—05—30 12:34:22, Info CSI 000005b4 Hashes for file member ??C:WindowsSysWOW64mfplat.dll do not match actual file [l:20{10}]«mfplat.dll» : Found: {l:32 b:1XsFZPITt9hYGb0SUMHPa32OJGefp2O0TdRWcHelghE=} Expected: {l:32 b:T9qLTbsZEERFvFGvivtc2yfwDwoRncRznjbIZZaDzzI=} 2020—05—30 12:34:22, Info CSI 000005b5 Hashes for file member SystemRootWinSxSx86_microsoft—windows—mfplat_31bf3856ad364e35_6.1.7601.24499_none_f8e9d951cb11bac7mfplat.dll do not match actual file [l:20{10}]«mfplat.dll» : Found: {l:32 b:1XsFZPITt9hYGb0SUMHPa32OJGefp2O0TdRWcHelghE=} Expected: {l:32 b:T9qLTbsZEERFvFGvivtc2yfwDwoRncRznjbIZZaDzzI=} 2020—05—30 12:34:22, Info CSI 000005b6 [SR] Could not reproject corrupted file [ml:48{24},l:46{23}]«??C:WindowsSysWOW64»[l:20{10}]«mfplat.dll»; source file in store is also corrupted 2020—05—30 12:34:22, Info CSI 000005b7 Repair results created: . . . |
В данном случае обращать внимание на строки, содержащие фразы 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 не обнаружила в системе поврежденных компонентов, при сохранении тенденции к нестабильной работе системы стоит рассмотреть иные способы диагностики.