Прочее Как правильно анализировать cbs.log и результаты проверки sfc /scannow

[Кирилл]

Всем привет.

Начну с небольшого определения:

Что такое cbs.log?

Файл-лог журнала обслуживания windows, который содержит подробные сведения об ошибках автономного обслуживания, подробные сведения об ошибках интерактивного обслуживания, а так же как вспомогательный элемент для dism.exe

Не вдаваясь в тонкости осмысливания написанного ( определение взято отсюда ) сообщу следующее:

Многим из нас знакома программа sfc.exe, с помощь которой можно проверить состояние целостности защищенных системных файлов.
(Обсуждение в этой теме: Обзор утилиты sfc.exe )
Результат ее работы будет отражен как раз так же в этом логе.
Но, для большинства пользователей, анализ результата проверки остается трудновыполнимой задачей.

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

Программа защиты ресурсов Windows обнаружила поврежденные файлы, но не может восстановить некоторые из них

Один из шагов к решению проблемы - это произвести анализ лога, который создается при сканировании. Лог-файл находится по пути %windir%\logs\cbs\cbs.log и открыть его можно любым текстовым редактором, включая стандартный notepad.
Неподготовленный пользователь, открыв и посмотрев лог, скорее всего испытает острое желание закрыть файл и больше не открывать. Поэтому, для комфорта восприятия, пользователи придумали приводить лог в более читабельный вид, распарсив его и отфильтровав "лишние" записи оставить только те, что нужны.
Сделать это можно разными методами, кстати - в сети распространен метод с парсингом файла cbs.log введя в командной строке простую команду:

findstr/c: «[SR]» %windir%\logs\cbs\cbs.log > "указать адрес, куда вы хотите сохранить лог"\sfcdetails.txt

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

Как быть?
Для более комфортного первоначального анализа мы с коллегами создали такой скрипт:
Проверка целостности системных файлов утилитой sfc

Запустив скрипт вы сможете произвести проверку целостности системных файлов, произвести очистку и восстановление хранилища данных windows, в котором хранятся резервные копии защищенных системных файлов windows.
Из этих копий и производится восстановление поврежденных файлов.
Скрипт выводит аналогичный, но чуть более информативный лог + копирует в каталог запуска скрипта сам файл cbs.log.
А так же очищает старые записи, что немного экономит место на диске и спасает от зависаний компьютера ( при определенных условиях) при попытке открыть cbs.log. Да и читать будет удобнее и меньше.
Это связано с тем, что порой размер файла cbs.log может раздуваться и я видел монстров по 40 с лишним мегабайт... в общем, скрипт его "облегчает" до оптимального объема.
Идем дальше.
Пробуем читать cbs.log.

Что нужно знать?​

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

%SystemRoot%\WinSxS

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

Напомню, что лог cbs.log находится по такому пути:

%SystemRoot%\Logs\CBS

* предварительно необходимо включить отображение скрытых и системных файлов.

=========================================================

Вернемся, непосредственно, к файлу cbs.log. Вы его уже открыли в текстовом редакторе?
Открывайте.
Лично мне более удобным для работы с файлами такого типа является редактор notepad++
Так как редакторов много и каждый волен выбирать тот, что ему по душе - то далее я буду описывать свои действия в редакторе в контексте интерфейса notepad++ , а вы (если пользуетесь другим) , можете ориентироваться по аналогии в своем.

Думаю вы уже до этого находили информацию о том, что нужные нам действия помечаются тегом [SR] в каждой строке - именно по этому признаку и принято парсить cbs.log. А если вы не знали - значит узнали теперь)
Теперь у нас с вами два варианта: либо переходить сразу к проблемным файлам через поиск (это если у вас уже есть отфильтрованный одним из упомянутых методов лог) либо вывести все строки с тегом [SR].
Я лично всегда так делаю - легче потом будет навигация.
В notepad++ есть возможность вывести в дополнительной области все найденные по маске ( тегу [SR] ) строки.

Делается это просто: открываем поиск (кнопка в виде бинокля), вводим в строку поиска [SR], далее нажимаем кнопку "Найти все в текущем документе" и получаем в нижней области программы все строки найденные по нужному фильтру, а в верхней области основной текст файла cbs.log, как видно на скриншоте:

Это позволит вам видеть проблемные места (нижняя область) и одновременно смотреть сопутствующую информацию по ним в основном логе (верхняя область).
Ну как, все получилось?

Далее в нижней области, где отфильтрованы строки с тегом [SR] пропускаем все что выглядит примерно так:

2018-01-22 19:54:56, Info                  CSI    00000015 [SR] Verifying 100 (0x0000000000000064) components
2018-01-22 19:54:56, Info                  CSI    00000016 [SR] Beginning Verify and Repair transaction
2018-01-22 19:54:59, Info                  CSI    00000018 [SR] Verify complete

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

Как только находим нечто отличающееся - стоп.
Например:
2017-10-29 21:28:40, Info CSI 000001e1 [SR] Cannot repair member file [l:24{12}]"gpscript.exe" of Microsoft-Windows-GroupPolicy-Script, Version = 6.1.7601.23452, 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

Все, сейчас мы нашли то, что надо.
Если вбить в переводчик то, что написано раздельным текстом, то можно вполне понять что не так.
На примере данной строки давайте и разберемся.

Cannot repair member file  - не удается восстановить файл-член...
PublicKey neutral in the store, hash mismatch - Открытый ключ нейтральный  в магазине, несоответствие хэша

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

2017-10-29 21:28:40, Info                  CSI    000001e0 Hashes for file member \SystemRoot\WinSxS\x86_microsoft-windows-grouppolicy-script_31bf3856ad364e35_6.1.7601.23452_none_677acd98e72e71cc\gpscript.exe do not match actual file [l:24{12}]"gpscript.exe" :
  Found: {l:32 b:yHkCWhwG8j0IOFAIlAuv4/o6FtEO2tqdJOWtoUpBlck=} Expected: {l:32 b:GQ5AzLEfZ9lH3YTPo9vNHTiesdUCuZnB7IW2XQQmn1c=}
2017-10-29 21:28:40, Info                  CSI    000001e1 [SR] Cannot repair member file [l:24{12}]"gpscript.exe" of Microsoft-Windows-GroupPolicy-Script, Version = 6.1.7601.23452, 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
2017-10-29 21:28:40, Info                  CSI    000001e2 [SR] This component was referenced by [l:154{77}]"Package_40_for_KB3159398~31bf3856ad364e35~x86~~6.1.1.1.3159398-40_neutral_LDR"

Тут мы отчетливо видим, что файл в хранилище должен быть по адресу:
Hashes for file member \SystemRoot\WinSxS\x86_microsoft-windows-grouppolicy-script_31bf3856ad364e35_6.1.7601.23452_none_677acd98e72e71cc\gpscript.exe
Версия его: Version = 6.1.7601.23452 и на него ссылается компонент патча KB3159398.
Открываем упомянутый патч на сайте Microsoft:
Download Обновление для системы безопасности Windows 7 (KB3159398) from Official Microsoft Download Center
Находим там ссылку "Связанные ресурсы", переходим.
https://support.microsoft.com/ru-ru/help/3159398/ms16-072-description-of-the-security-update-for-group-policy-june-14
Открываем сведения о файлах и находим тот, что нам нужен:

​

Все, значит это то, что нам нужно.
Просто переустанавливаем это обновление и нужные файлы перезаписываются. А значит - все станет ОК.

Это был пример на живом логе реальной системы.

Почему необходимо найти именно такой же файл и такой же версии?
Потому что когда данный файл внедрялся в систему, то создается ряд условий, на основании которых система защиты будет считать "правильным" только такой файл, который будет соответствовать этим самым условиям.
Другими словами, если какое то из обновлений системы, к примеру, обновляло версию файла и эталоны, то файл из ранее сделанной резервной копии, но другой версии будет считаться неактуальным.
Именно поэтому часто встречающуюся рекомендацию:
Вставьте диск (флэшку) с дистрибутивом вашей версии операционной системы и введите sfc / scannow ...
Можно смело пропускать мимо ушей, глаз или как там еще информация дошла до вас.

Почему?

Тут имеется очень важный нюанс - дистрибутив должен быть именно таким же.
То есть с точно таким же набором обновлений, патчей и заплаток.
А найти такой дистрибутив довольно сложно, если вообще будет возможным.

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

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

Отсюда можно сделать вывод, что при первоначальной проверке заморачиваться на счет наличия дистрибутива не стоит.
Исключение Windows XP - там система потребует наличия папки I386, которая имеется как раз на дистрибутиве (если у вас нет где то отдельно).
В нашем скрипте проверка ее наличия осуществляется автоматически и пользователю не придется выполнять танцы с бубном для того, что бы указать системе где она, если не удастся обнаружить.
Достаточно смонтировать образ диска и все.

Как еще можно восстановить поврежденные файлы?​

Можно попытаться выполнить автоматическое восстановление хранилища компонентов через пункт "Расширенная проверка и восстановление файлов" скрипта, или запустив командную строку от имени Администратора и ввести команду:
(Для Windows 8 - 11)
dism /Online /cleanup-image /restorehealth

Для Windows 7 команда будет выглядеть немного иначе, а так же потребуется наличие установленного Download Обновление для Windows 7 (KB2966583) from Official Microsoft Download Center
DISM /Online /Cleanup-Image /ScanHealth

В обоих случаях интернет должен быть подключен.
После того, как хранилище компонентов будет восстановлено, попробуйте снова выполнить проверку sfc /scannow
Как правило этой операции бывает достаточно.

=================================

Если вам понадобилось восстановление файлов хранилища данных вручную - то вам понадобится стать владельцем объекта и получить права на изменение.


=================================


Итак, теперь общее понимание у нас имеется, далее просто будем собирать типовые примеры записей лога cbs.log и методы исправления проблем.

Для того, что бы облегчить себе задачу и сэкономить время и силы, я использую для первоначального анализа файл sfcdoc.log, создаваемый скриптом.
Можно использовать и sfcdetalis.txt - но он менее информативен.

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

------ SFCDoc parsing (start process) ------

Там выводится результат работы программы sfc.exe, который записывается в cbs.log и имеет строки с тегом [sr]
Программа sfc.exe проверяет файлы блоками по 100 штук, отсюда и появляются записи типа:

000028a5 [SR] Verify complete
000028a6 [SR] Verifying 100 components
000028a7 [SR] Beginning Verify and Repair transaction

Итак, в логе sfcdoc.log (или sfcdetalis.txt) мы находим примерно такие строки:

00004fa9 [SR] Cannot repair member file [l:12]'userinit.exe' of Microsoft-Windows-UserInit, version 10.0.15042.0, arch Host= amd64 Guest= x86, nonSxS, pkt {l:8 b:31bf3856ad364e35} in the store, hash mismatch
00004fac [SR] Cannot repair member file [l:12]'userinit.exe' of Microsoft-Windows-UserInit, version 10.0.15042.0, arch Host= amd64 Guest= x86, nonSxS, pkt {l:8 b:31bf3856ad364e35} in the store, hash mismatch
00004fad [SR] This component was referenced by [l:181]'Microsoft-Windows-Client-Features-WOW64-Package-AutoMerged-onecore~31bf3856ad364e35~amd64~~10.0.15042.0.Microsoft-Windows-Client-Features-WOW64-Package-AutoMerged-onecore-Deployment
00004fb0 [SR] Could not reproject corrupted file \??\C:\Windows\SysWOW64\userinit.exe; source file in store is also corrupted

Это файлы, которые не удалось восстановить, либо те, что были восстановлены.

Если буквально, то Could not reproject corrupted file \??\C:\Windows\SysWOW64\userinit.exe значит что указанный файл не удалось восстановить из хранилища.
А source file in store is also corrupted - это говорит нам о том, что в хранилище файл тоже поврежден.

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

Теперь имеет смысл обратиться к файлу cbs.log.
Скопируйте его в удобное место из каталога

%SystemRoot%\Logs\CBS

Открыть его можно любым текстовым редактором, лично я предпочитаю Notepad++
Открываем cbs.log и ищем ближайшую с конца строку с искомым нам файлом: в данном случае это userinit.exe

2017-10-26 23:38:05, Info                  CSI    000041c2 Hashes for file member \SystemRoot\WinSxS\wow64_microsoft-windows-userinit_31bf3856ad364e35_10.0.15042.0_none_f7a5dd2f3ed02235\userinit.exe do not match actual file [l:12]'userinit.exe' :
  Found: {l:32 mhHTAD/21TkyflJQwItWEJZr9UaGJebx3CamF6tUPf4=} Expected: {l:32 +bkkt7edQArLakaOJRdpxV8MvpFumMUD88WNy60YfA0=}
2017-10-26 23:38:05, Info                  CSI    000041c3 [SR] Cannot repair member file [l:12]'userinit.exe' of Microsoft-Windows-UserInit, version 10.0.15042.0, arch Host= amd64 Guest= x86, nonSxS, pkt {l:8 b:31bf3856ad364e35} in the store, hash mismatch
2017-10-26 23:38:05, Info                  CSI    000041c4 [SR] This component was referenced by [l:181]'Microsoft-Windows-Client-Features-WOW64-Package-AutoMerged-onecore~31bf3856ad364e35~amd64~~10.0.15042.0.Microsoft-Windows-Client-Features-WOW64-Package-AutoMerged-onecore-Deployment'
2017-10-26 23:38:05, Info                  CSI    000041c5 Hashes for file member \??\C:\Windows\SysWOW64\userinit.exe do not match actual file [l:12]'userinit.exe' :
  Found: {l:32 K1Y9CBrNZsBLg7IsV/u9IEgYQ9xrk8frQkTDRknlyMA=} Expected: {l:32 +bkkt7edQArLakaOJRdpxV8MvpFumMUD88WNy60YfA0=}
2017-10-26 23:38:05, Info                  CSI    000041c6 Hashes for file member \SystemRoot\WinSxS\wow64_microsoft-windows-userinit_31bf3856ad364e35_10.0.15042.0_none_f7a5dd2f3ed02235\userinit.exe do not match actual file [l:12]'userinit.exe' :
  Found: {l:32 mhHTAD/21TkyflJQwItWEJZr9UaGJebx3CamF6tUPf4=} Expected: {l:32 +bkkt7edQArLakaOJRdpxV8MvpFumMUD88WNy60YfA0=}
2017-10-26 23:38:05, Info                  CSI    000041c7 [SR] Could not reproject corrupted file \??\C:\Windows\SysWOW64\userinit.exe; source file in store is also corrupted

Что мы видим?
Hashes for file member ..... do not match actual file
Эта запись гласит о том, что хэш сумма файла не совпадает с оригинальным.
Это и есть причина.
Где надо заменить файл?

\SystemRoot\WinSxS\wow64_microsoft-windows-userinit_31bf3856ad364e35_10.0.15042.0_none_f7a5dd2f3ed02235\userinit.exe

Запомните, что SystemRoot\WinSxS - это адрес расположения хранилища данных.
Где SystemRoot эквивалентен переменной %SystemRoot% - путь до каталога windows на системном диске.

wow64 - это говорит нам о том, что речь идет о 64 разрядной системе и версии файла.

Строка

Cannot repair member file [l:12]'userinit.exe' of Microsoft-Windows-UserInit, version 10.0.15042.0

отображает так же служебную информацию, тут нам важно отметить что исходя из этой записи мы видим, что речь идет о версии файла 10.0.15042.0 (version 10.0.15042.0).
Это значит, что мы должный найти точно такую же версию файла и произвести замену в указанном каталоге.
Равно как и в каталоге C:\Windows\SysWOW64\userinit.exe
Тут есть особенность: так как произвести замену C:\Windows\SysWOW64\userinit.exe в загруженной системе вряд ли удастся, то вам либо придется сделать это из среды восстановления (в таком случае путь будет Х:\Windows\userinit.exe, где Х - это системный диск), либо из под Live CD/USB, либо - самый оптимальный вариант - просто производим замену в хранилище, а затем производим стандартную проверку sfc /scannow и система все сделает за вас сама.
То есть восстановит поврежденные файлы из хранилища.

* узнать версию файла можно кликнув по нему правой кнопкой мыши - свойства -Подробно.

==================================================


Далее разберем следующие строки лога cbs.log

Found: {l:32 b:yHkCWhwG8j0IOFAIlAuv4/o6FtEO2tqdJOWtoUpBlck=} Expected: {l:32 b:GQ5AzLEfZ9lH3YTPo9vNHTiesdUCuZnB7IW2XQQmn1c=}
2017-10-29 21:28:40, Info                  CSI    000001dd [SR] Cannot repair member file [l:24{12}]"gpscript.exe" of Microsoft-Windows-GroupPolicy-Script, Version = 6.1.7601.23452, 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
2017-10-29 21:28:40, Info                  CSI    000001de [SR] Cannot repair member file [l:72{36}]"Microsoft.Build.Engine.resources.dll" of Microsoft.Build.Engine.resources, Version = 3.5.7600.16385, pA = PROCESSOR_ARCHITECTURE_MSIL (8), Culture = [l:10{5}]"ru-ru", VersionScope = 1 nonSxS, PublicKeyToken = {l:8 b:b03f5f7f11d50a3a}, Type neutral, TypeName neutral, PublicKey neutral in the store, file is missing
2017-10-29 21:28:40, Info                  CSI    000001df [SR] This component was referenced by [l:168{84}]"Microsoft-Windows-NetFx3-OC-Package~31bf3856ad364e35~x86~ru-RU~6.1.7601.17514.NetFx3"
2017-10-29 21:28:40, Info                  CSI    000001e0 Hashes for file member \SystemRoot\WinSxS\x86_microsoft-windows-grouppolicy-script_31bf3856ad364e35_6.1.7601.23452_none_677acd98e72e71cc\gpscript.exe do not match actual file [l:24{12}]"gpscript.exe" :
  Found: {l:32 b:yHkCWhwG8j0IOFAIlAuv4/o6FtEO2tqdJOWtoUpBlck=} Expected: {l:32 b:GQ5AzLEfZ9lH3YTPo9vNHTiesdUCuZnB7IW2XQQmn1c=}
2017-10-29 21:28:40, Info                  CSI    000001e1 [SR] Cannot repair member file [l:24{12}]"gpscript.exe" of Microsoft-Windows-GroupPolicy-Script, Version = 6.1.7601.23452, 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
2017-10-29 21:28:40, Info                  CSI    000001e2 [SR] This component was referenced by [l:154{77}]"Package_40_for_KB3159398~31bf3856ad364e35~x86~~6.1.1.1.3159398-40_neutral_LDR"

Cannot repair member file ... hash mismatch

Здесь так же говорится, что файл такой то не удалось восстановить и имеется несоответствие суммы хэш.

А вот запись in the store, file is missing говорит о том, что файл не просто поврежден, а полностью отсутствует в хранилище компонентов.

А вот эта строка

2017-10-29 21:28:40, Info                  CSI    000001e2 [SR] This component was referenced by [l:154{77}]"Package_40_for_KB3159398~31bf3856ad364e35~x86~~6.1.1.1.3159398-40_neutral_LDR"

нам говорит о том, что этот компонент связан с обновлением KB3159398.
Если найти в базе Microsoft соответствующую ссылку, то там в перечне изменяемых файлов мы как раз увидим, что обновление выполняет установку файла необходимой версии.
Другими словами решением будет - переустановка обновления KB3159398.

Вот еще один интересный вариант, который вам может попасться в логе:

9:15, Error                 CSI    00000187 (F) Failed on regenerating file [l:22{11}]"browaub.ttf"[gle=0x80004005]

Здесь говорится о том, что попытка восстановления файла была завершена с ошибкой 0x80004005
Не буду вас гонять по поисковикам и скажу сразу что в данном случае процесс блокировал брандмауэр Windows, как бы бредово это не звучало)

P.S.
Далее будут в таком же формате излагаться другие варианты, если есть вопросы и замечания пишите.

 

[monowar]

@Кирилл, Очень хорошая статья,тема нужная

 

[Кирилл]

Добавлю: при обнаружении ошибок типа

(f)    CBS MUM Corrupt    0x00000000    servicing\Packages\Microsoft-Windows-IE-Spelling-Parent-Package-Russian~31bf3856ad364e35~~~11.2.9412.0.mum        Expected file name Microsoft-Windows-IE-Spelling-Parent-Package-Russian~31bf3856ad364e35~neutral~~11.2.9412.0.mum does not match the actual file name

Вводим команду удаления соответствующего пакета:

pkgmgr  /up:Microsoft-Windows-IE-Spelling-Parent-Package-Rus
sian~31bf3856ad364e35~~~11.2.9412.0

Перезагружаем ПК

 

[Dragokas]

Вводим команду удаления соответствующего пакета:

А если мне этот пакет нужен?

 

[Кирилл]

А если мне этот пакет нужен?

То тем более так нужно сделать, а потом установить заново.
does not match the actual file name - не соответствие фактическому имени файла, то есть этот пакет имеет ошибку взаимосвязей - некорректно установлено одно из обновлений, либо есть повреждения его компонентов.
Система при распаковке обновления, видимо, не проверяет целостность его компонентов. А когда все чисто - обновление должно установиться гладко.
По крайней мере именно так я это и понял.

 

[Dragokas]

@Кирилл, т.е. для обратной операции достаточно просто выполнить повторный поиск обновлений?

 

[Кирилл]

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

 

[Resistonyx]

@Кирилл спасибо за этот "гайд". Очень подробно разобрал! Низкий поклон, моя благодарочка!)