SFC не может восстановить файлы и при чем здесь лог CBS

Встроенная утилита sfc.exe является одним из наиболее часто используемых консольных инструментов Windows. Служит она для проверки целостности системы и восстановления поврежденных, модифицированных или удаленных системных файлов – с командой sfc /scannow, полагаем, знакомы многие. Увы, помогает она не во всех случаях, всегда есть вероятность, что SFC обнаружит, но так и не сможет восстановить поврежденные файлы.

При этом утилита не указывает, какие именно файлы ей не удалось восстановить, а отсылает пользователя к некоему файлу CBS.log. Проанализировав последний, можно идентифицировать повреждения и внести исправления путем выборочной установки пакетов обновлений или вручную – заменив «битые» файлы оригинальными. Однако, учитывая структуру лога, для начинающих пользователей такой анализ может оказаться непростой задачей.

Что такое файл CBS.log

Файл CBS.log представляет собой отдельный журнал в папке %windir%LogsCBS, содержащий сведения об установленных и/или удаленных обновлениях Windows, кроме того, он содержит сведения об ошибках интерактивного и автономного обслуживания средствами sfc и dism.

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

Парсинг CBS.log

Результаты работы sfc.exe в файле лога обозначены тегом [SR], что существенно упрощает поиск нужных сведений. Впрочем, искать относящиеся к работе SFC записей в самом логе нет нужды, поскольку вы можете его распарсить, вытащив сведения в отдельный текстовый файл.

Для этого откройте от имени администратора классическую командную строку и выполните следующую команду:

findstr /c:»[SR]» %windir%LogsCBSCBS.log >»%userprofile%Desktopsfc.txt»

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

Анализ записей

Содержащиеся в нем записи представлены в виде табличного списка, каждая строка содержит дату и время проверки, тип отчета, сокращенное название инфраструктуры обслуживания компонентов (CSI), код, тег [SR] и результат выполненной операции.

В случае обнаружения повреждений целостности и удачного восстановления блок записей будет выглядеть так:

Если SFC потерпит фиаско, записи будут иметь совсем другой вид.

В данном случае они будут содержать элементы строк «Cannot repair member file» (невозможно восстановить файл), «PublicKey neutral in the store, hash mismatch» (контрольные суммы не совпадают), «Could not reproject corrupted file» (не удалось восстановить поврежденный файл). В этом же блоке строк будет указано имя файла, его версия и путь.

Восстановление файлов

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

• Пробив информацию о файле в Интернете и определив, в каком патче или накопительном обновлении он содержится. Зная номер обновления, скачиваем его с каталога Центра обновлений catalog.update.microsoft.com/Home.aspx и устанавливаем.
• Заменив поврежденные файлы оригинальными, взятыми из рабочей Windows той же версии, сборки и разрядности.
• Выполнить сканирование средствами sfc, подключив смонтированный образ WIM или ESD системы той же версии и разрядности.

Наиболее правильным и оптимальным является первый вариант, поскольку не факт, что замененный вручную файл будет принят системой как родной. Гарантировать его корректную работу можно только в том случае, если он взят из системы не просто той же версии, а из системы с тем же набором патчей и обновлений.