В процессе жизненного цикла операционной системы Windows, периодически возникает необходимость установки/удаления того или иного программного обеспечения. Понятно, что программное обеспечение достаточно многообразно и порой довольно сложно оценить степень его влияния на систему, одни программы являются достаточно безобидными, другие же могут вносить в систему настолько существенные изменения, что в пору говорить о масштабном системном обновлении. К тому же, если эксплуатационный цикл системы достаточно продолжителен, то в процессе установки/удаления/замены различных обновлений и ПО можно наблюдать накопление/удаление/повреждение различных версий системных библиотек, всевозможных ключевых системных структур (реестра, библиотек, исполняемых модулей). Особое внимание стоит обратить на то, что критично-важные компоненты операционной системы могут повреждаться, либо удаляться вовсе в следствии деятельности вредоносного программного обеспечения (вирусы, трояны), разнородных ошибок в работе программной и аппаратной частей компьютера. Во всем многообразии этого броуновского движения, крайне сложно спрогнозировать последствия подобных изменений системы, возникшие на каком-либо этапе проблемы могут оставаться определенное время незамеченными, либо вовсе никогда не проявить себя, однако чаще всего случается, что спустя некоторое время мы начинаем наблюдать довольно таки интересные "нештатные ситуации", в которых операционная система ведет себя довольно странно.
Проблема сохранения работоспособности ключевых системных компонентов и, как следствие, операционной системы в целом, стояла перед разработчиками Microsoft Windows с самого того дня, когда первые версии ОС начинали своё знакомство с широкой аудиторией, ведь по началу сама система была и вовсе беззащитна от вмешательства различного рода стороннего программного обеспечения, инсталлируемого с использованием административных привилегий и беззастенчиво переписывающего своими компонентами "родные" системные модули. Понятно, что столь серьезная проблема требовала своего скорейшего решения и в итоге Microsoft начали предоставлять изнемогающей от глюков общественности различные методы выхода из ситуации. Это были, по-началу, и службы контроля за целостностью важных системных файлов, и утилиты привидения их к эталонным версиям, в конечном итоге был разработан принцип компонентизации или модуляризации. "-Ну Конечно",- скажете Вы,- "зачем нам все это? Мы всегда можем решить проблему и более кардинальным образом, ведь у нас в запасе есть проверенное десятилетиями, безотказное средство под названием "переустановка", либо такое как возврат к ранее созданной точке восстановления". Можно восстановить из ранее созданного образа системы, но этим могут похвастаться лишь самые педантичные, а у обычных обывателей довольно редко резервный образ бывает актуальным (если вообще присутствует), в любом случае, придется затратить свое драгоценное личное время на приведение системы к необходимому состоянию. Да, описанные методы действительно актуальны, однако подобное решение и так рассматривалось разработчиками как выход из сложившейся ситуации довольно продолжительное время :) Все это не делает саму систему стабильнее, а ведь одна из задач авторов хорошей ОСи - сделать её отказоустойчивой. Но в итоге разработчики Microsoft предоставили пользователям средство под названием sfc, о котором и пойдет речь в данной статье.
В общем случае, утилита выполняет сканирование и восстановление поврежденных или отсутствующих системных файлов путем сравнения экземпляра, установленного в системе с эталонной версией, размещенной в специализированном защищенном хранилище системных компонентов.
Запуск проверки целостности файлов
Поскольку sfc является консольной утилитой (утилитой командной строки), то и запускать её следует из командного интерпретатора cmd
. Для выполнения комплексной проверки всех системных файлов, выполните следующую команду:
sfc /scannow
Утилита стартует процесс проверки системных файлов, в ходе которого будут заменяться/восстанавливаться поврежденные/отсутствующие файлы. Теперь оставьте окно в покое и дождитесь окончания процесса проверки.
Естественно что утилита sfc возвращает статус завершения процедуры проверки системных файлов на консоль в виде строки, отражающей результат проверки. На приведенной выше картинке данная строка результата выделена красным цветом. Очевидно, что от того, как именно завершилась проверка, зависят и дальнейшие наши действия по восстановлению работоспособности системы. Давайте разберем возможные результаты и методы реакции на них:
- Защита ресурсов Windows не обнаружила нарушений целостности. Это сообщение говорит о том, что WRP не смогла найти каких-либо повреждений в операционной системе и стоит задуматься о диагностировании системы другими способами;
- Защита ресурсов Windows не может выполнить запрошенную операцию. Утилита sfc сообщает нам, что WRP не смогла выполнить необходимые операции восстановления. В этом случае можно попробовать:
- перезагрузить систему в защищенный режим и запустить sfc из-под него;
- дополнительно удостоверьтесь что папки PendingDeletes и PendingRenames присутствуют в директории %WinDir%\WinSxS\Temp;
- проверьте что у 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 возникли ошибки (описанные выше), то можно руководствоваться простым алгоритмом:
- попытаться повторно запустить её еще пару-тройку раз. В практике нередко наблюдались случаи, когда в ходе очередного запуска sfc все же удавалось нормально выполнить свою работу.
- если все же устойчиво получаем ошибки, то производим анализ результатов в файле %WinDir%\Logs\CBS\CBS.log.
- по результатам анализа результатов в файле отчета производим ручное восстановление недостающих/битых компонентов. Возможно привлечение этапов работы с компонентной моделью Windows, как описано в этом хабе.
Часто алгоритм восстановления работоспособности не так тривиален, и приходится выполнять шаги по несколько раз. Например, запустили sfc, получили отчет, прошлись dism до момента, пока он не сообщает о том, что ошибок нет, затем снова sfc и по результатам ручное восстановление из рабочей системы недостающих/битых файлов. И так по кругу до появления результатов sfc: Защита ресурсов Windows обнаружила поврежденные файлы и успешно их восстановила или Защита ресурсов Windows не обнаружила нарушений целостности.
Анализ результатов
Для того, чтобы лицезреть результаты работы утилиты sfc нам предлагается открыть файл журнала компонентной модели %WinDir%\Logs\CBS\CBS.log любым доступным в системе текстовым редактором.
CBS.log
не успевает "ротироваться" и раздувается до немыслимых величин. На одной из систем я наблюдал аж 990Мб живых записей. Для открытия файла подобного объема придется постараться!Сразу спешу предупредить, что в данный лог-файл пишет несколько источников, поэтому в файле достаточно много лишней для нас информации. Для того, чтобы отфильтровать из этого огромного объема интересующую нас информацию, необходимо поиском найти дату и время конкретно нашего запуска sfc. Дата и время фигурируют в файле в каждой записи в первых двух параметрах:
1 2 3 4 |
. . . 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:\Windows\winsxs\amd64_microsoft-windows-servicingstack_31bf3856ad364e35_6.1.7601.18766_none_675144b3de10d6f7\cbscore.dll . . . |
Однако это еще не все, следующее неудобство в самостоятельном анализе результатов работы утилиты sfc заключается в том, что процесс, порожденный sfc, записывает в файл отчета в рамках нашей сессии довольно много лишней информацию обо всей активности WRP. Однако нам то необходимо найти информацию лишь об обнаруженных ошибках. Поэтому следующим шагом мы должны идентифицировать записи о интересующей нас сессии проверки утилиты sfc, для этого надо ориентироваться на указание в строках префикса восстановления [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 \SystemRoot\WinSxS\x86_microsoft-windows-mfplat_31bf3856ad364e35_6.1.7601.24499_none_f8e9d951cb11bac7\mfplat.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 \SystemRoot\WinSxS\x86_microsoft-windows-mfplat_31bf3856ad364e35_6.1.7601.24499_none_f8e9d951cb11bac7\mfplat.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:\Windows\SysWOW64\mfplat.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 \SystemRoot\WinSxS\x86_microsoft-windows-mfplat_31bf3856ad364e35_6.1.7601.24499_none_f8e9d951cb11bac7\mfplat.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:\Windows\SysWOW64"\[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 с детальной информацией по самому объекту (файлу). До тех пор, пока мы не исправим данные ошибки самостоятельно (в ручном режиме), утилита sfc в ряде случаев будет давать на выходе ошибочный статус завершения.
Кроме того, как мы видим, информация в файле отчета группируется в своеобразные контейнеры, представляющие из себя группу записей по устранению какой-либо проблемы либо группу родственных проблем. Судя по всему, применяется два основных типа контейнеров. В первом из них содержится информация по восстановлению компонентов и границы блоков помечаются как:
1 2 3 |
<дата> <время>, Info CSI xxxxxxxx [SR] Repairing XX components . . . <дата> <время>, Info CSI xxxxxxxx [SR] Repair complete |
, во втором содержится информация по проверке компонентов и границы блоков помечаются так:
1 2 3 |
<дата> <время>, Info CSI xxxxxxxx [SR] Verifying XX components . . . <дата> <время>, Info CSI xxxxxxxx [SR] Verify complete |
информация по обнаруженным ошибкам может встречаться в обеих типах контейнеров, поэтому анализировать их надо оба.
Можно подойти к вопросу изучения отчета с другой стороны. С целью облегчить техническому специалисту работу по анализу журнала проверки, имеется рекомендация от разработчиков, которые советуют определенным образом отфильтровать весь массив записей отчета. Для этого наберите вручную в консоли команду:
findstr /c:"[SR]" %windir%\logs\cbs\cbs.log > c:\sfcdetails.txt
в результате выполнения приведенной команды, в корне диска C:\ будет создан файл sfcdetails.txt
, содержащий только лишь те строки исходного файла, которые содержат префикс [SR]
, что существенно упрощает поиск необходимой нам информации об обнаруженных утилитой ошибках.
Запуск из среды восстановления
Если сама операционная система уже не в состоянии загрузиться в штатном режиме, можно запустить 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 10 не грузится (зависает на экране загрузке при попытке автоматического восстановления системы), а при загрузке с установочной флешки Windows 10 и запуске из командной строки sfc /scannow выдается надпись "Защите ресурсов Windows не удалось выполнить запрошенную операцию"?
В логе проверки sfc огромное количество ошибок, в основном то что у папок в system32 оказалось больше одного владельца.
При попытке восстановить систему, переустановив ее поверх, Windows 10 предлагает перезагрузиться и повторить попытку непосредственно из системы. Великолепно.
Интересная ошибка. Попробуйте пропустить ошибки владельца файлов и сосредоточиться именно на ошибках восстановления системных файлов и устранить эти ошибки вручную, друг за другом.
Отличная статья.
спасибо :)
Некоторые уточнения по поводу DISM в Windows 7:
- здесь нет ключей /CheckHealth и /RestoreHealth, и всю работу выполняет ключ /ScanHealth
- команду можно выполнять только на работающей системе, т.е. восстановление отключенных образов не реализовано
- появилась возможность проверки и восстановления компонентов Internet Explorer, которой не было в старом CheckSUR
спасибо за уточнение
Только начинает сканирование, сразу просит перезагрузку. 50 раз сделал, и бросил...
В тексте ясно написано:
Для завершения восстановления системы требуется перезагрузка. Перезапустите систему Windows и выполните sfc еще раз.
Обычно подобная ошибка появляется при запуске из-под ограниченного рабочего окружения, такого, например, как среда восстановления (Windows RE). Для решения проблемы попробуйте запустить утилиту sfc с дополнительными параметрами, как описано в разделе Запуск из среды восстановления.