Sfc - проверка системных файлов

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

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

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

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

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

sfc /scannow

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

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

• Защита ресурсов Windows не обнаружила нарушений целостности. Это сообщение говорит о том, что WRP не смогла найти каких-либо повреждений в операционной системе и стоит задуматься о диагностировании системы другими способами;
• Защита ресурсов Windows не может выполнить запрошенную операцию. Утилита sfc сообщает нам, что WRP не смогла выполнить необходимые операции восстановления. В этом случае можно попробовать запустить sfc, перегрузившись в защищенный режим. Дополнительно удостоверьтесь что папки PendingDeletes и PendingRenames присутствуют в директории %WinDir%\WinSxS\Temp;
• Защита ресурсов 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 нам предлагается открыть файл журнала компонентной модели %WinDir%\Logs\CBS\CBS.log любым доступным в системе текстовым редактором.

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

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

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

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

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

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 не обнаружила в системе поврежденных компонентов, при сохранении тенденции к нестабильной работе системы стоит рассмотреть иные способы диагностики.