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, однако имейте в виду, что в этом случае возможны некоторые нюансы :)

Хранилище компонетов

В версиях операционных систем, предшествующих Windows XP, обновлялись единственные экземпляры системных файлов, при этом старые версии безвозвратно удалялись, тем самым часто вызывая проблемы в работе определенных программ (проблемы совместимости). С целью дальнейшего решения проблемы совместимости конкретного приложения и DLL, в версиях начиная с Windows XP произошло отсупление от традиционной модели обновления системных файлов (библиотек, исполняемых модулей и прч.) и было введено хранилище компонентов, концепция которого заключалась в тиражировании компонентов (общих сборок). В Windows Vista эта модель была существуенно доработана и уже обеспечивала отслеживание и обслуживание всех компонентов системы.

Применительно к операционной системе Windows, компонент (сборка) представляет собой группу файлов, включающую: сами бинарные файлы, .cat-файл каталога безопасности и .manifest-файл (манифест, XML-файл с описанием настроек безопасности, метода инсталляции и параметров реестра).

Компоненты

Сборки бывают приватными и общими. Все общие сборки размещаются в системе в специальном хранилище компонентов, которое располагается в дереве директорий с корнем в %WinDir%\WinSxS (традиционно: C:\Windows\WinSxS).
Хранилише компонентов участвует в поддержке следующих основных задач:

• Включение/отключение компонентов Windows (апплет Программы и компоненты);
• Добавление ролей посредством апплета Server Manager;
• Восстановление системы после сбоев и проблем загрузки;
• Удаления проблемных обновлений;
• Поддержка функционирования приложений, использующих технологию side-by-side;
• Используется Центром обновления Windows при установке новых компонентов;
• Перенос системы между различными редакциями Windows;

Именование каталога выбрано от сокращения названия механизма Side-by-Side (Бок о бок), который обеспечивает одновременное существование в системе нескольких версий одноименной библиотеки. Из этого следует, что одним из предназначений технологии является устранение конфликтов между глобальными библиотеками DLL, установленными в операционной системе. В хранилище компонентов WinSxS каждый компонент помещается в свой подкаталог, определяемый собственным уникальным именем, которое включает в себя архитектуру процессора, имя компонента, уникальный идентификатор, версию компонента, язык локализации, для которых он был собран.

По причине того, что теперь атомарной единицей при обновлении Windows является не файл, а компонент, при обновлении единственного файла выпускается новая версия всего компонента, в состав которого входит обновляемый файл. Различные версии компонентов носят название сборок - экземпляров определенной версии компонента, которые формируются при обновлении данного компонента. На практике это выглядит так: в процессе установки библиотеки, которая уже имеется в системе, конфликт обнаруживается, но файл библиотеки DLL не перезаписывается, а устанавливаемая версия помешается в папку WinSxS, при этом сохраняются соответствующие записи реестра, данных и прочее. Таким образом, наряду с новой версией компонента, в системе остаются и все старые его версии, призванные обеспечить штатное функционирование программного обеспечения, нуждающегося в строго определенной версии компонента. При этом, в системных местоположениях (например, в каталоге %WinDir%\System32) отображаются текущие версии системных библиотек, которые представляют собой жесткие ссылки, ведущие на оригиналы, размещаемые в хранилище компонентов с корнем в каталоге %WinDir%\WinSxS. Компоненты состоят из полезной нагрузки (различные системные файлы: библиотеки, исполняемые файлы, локальные файлы конфигурации и прочее) и манифеста (определяет зависимости).

Пакеты

Помимо компонентов, в системе присутствуют так называемые пакеты, которые могут представлять собой как отдельные автономные инсталляции (например: Internet Explorer Optional Package, Remote Desktop Service WinIP и прч.), содержащие системные приложения, так и исправления операционной системы (KB???????) и комплекты драйверов.
Хранилище пакетов состоит из двух основных частей:

• одна часть пакета располагается в дереве директорий с корнем в %WinDir%\servicing\Packages. В ней содержатся конфигурационные файлы пакета, тут каждый установленный пакет/обновление представлен двумя файлами: файлом каталога безопасности (.cat) и манифеста (.mum), определяется собственным уникальным именем, которое включает в себя архитектуру процессора, имя пакета, уникальный идентификатор, версию пакета, язык локализации, для которых он был собран.
• другая часть (основные файлы) пакета размещается в директории %WinDir%\WinSxS.

Пакеты бывают установленными и подготовленными (к установке).

Манифест

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

• Манифест компонента – описатель компонента Windows. Манифест компонента задает его зависимости от имен, версий, ресурсов и других компонентов, в нем указываются различные параметры компонента, такие как наименование, каталог установки, параметры (ключи) реестра, исполняемые файлы, наименования служб и прочие. Имя файла манифеста включает имя соответствующей сборки, размещаемой в каталоге %WinDir%\WinSxS. Имеет расширение .manifest. Размещается в каталоге %WinDir%\WinSxS\Manifests;
• Манифест пакета или обновления - описатель пакета/обновления Windows. В нем указываются различные параметры пакета: наименование, идентификатор, язык установки, зависимости. Этот типа манифеста используется в качестве идентификатора (символического имени) сервиса обслуживания, для выполнения над пакетом операций включения/отключения/удаления посредством различных сервисных утилит (например, Диспетчера пакетов (pkgmgr)). Имя файла манифеста включает имя соответствующего пакета, размещаемого в каталоге %WinDir%\WinSxS. Имеет расширение .mum. Размещается в каталоге %WinDir%\servicing\Packages;

Применительно же к приложению, манифест определяет зависимости, которые приложение использует и связывает его со строго определенной версией компонента (сборки), библиотеки. Другими словами, приложение связывается с конкретной сборкой посредством информации, размещаемой непосредственно в ресурсной секции приложения, в ресурсе с именем Manifest. Желающие использовать строго определенные версии библиотек, должны непосредственно указывать идентификаторы сборок в собственном манифесте.

Обслуживание

По заявлению разработчиков, папка WinSxS является хранилищем разных версий общих библиотек и представляет собой "установочное и обслуживаемое состояние" всех системных компонентов.
Теперь поговорим об обслуживании. Обслуживание системы в новых реалиях происходит уже на уровне компонентов. Даже технология носит название Обслуживание на основе компонентов (Component Based Servicing, CBS). Файлы поддержки технологии расположены в каталоге %SystemRoot%\servicing. В этом каталоге размещаются:

Судя по всему, в стеке обслуживания реализован давно уже знакомый специалистам системный механизм под названием Защита Ресурсов Windows (Windows Resource Protection (WRP)), в операционных системах до Windows Vista более известный под именем Защита Файлов Windows (Windows File Protection (WFP)).

Сам принцип защиты критических файлов так же поменялся со времен WFP, теперь отсутствует системный процесс, который в реальном времени следит за попытками модификации критических файлов, а система ограничивает доступ к важным системным файлам при помощи списков контроля доступа (DACL/ACL), то есть WRP контролирует только определенные местоположения в операционной системе.

Логично, что утилита sfc в своей работе активно эксплуатирует стек обслуживания и, соответственно, функции библиотеки wrpinitapi.dll, которая предоставляет поддержку функций работы с WRP. В процессе работы утилиты sfc, WRP посредством процесса TrustedInstaller.exe производит обход всех критических системных компонентов, которые важны для поддержки функционирования операционной системы. В процессе обхода файл, размещенный в системном каталоге, сравнивается с эталонным файлом, размещенным в хранилище %WinDir%\WinSxS. Если обнаруживаются какие-либо модификации системного файла, WRP восстанавливает оригинальную копию данного файла из директории %WinDir%\WinSxS\Backup, которая содержит все защищаемые системные файлы.

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

Для того, чтобы лицезреть результаты работы утилиты 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 из командной строки консоли восстановления. Для запуска консоли восстановления перезагрузите компьютер и после вывода статусных сообщений BIOS/UEFI нажмите несколько раз клавишу F8, либо загрузитесь с установочного диска ОС. В появившемся меню (либо на соответствующем этапе загрузки с установочного диска) выбираем пункт "Устранение неполадок компьютера". Далее, после нескольких окон выбора языка и авторизации, в финальном меню выбираем пункт "Командная строка".

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

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

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

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

Выводы

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