- Сообщения
- 13,330
- Решения
- 3
- Реакции
- 5,705
Небольшая вставка перед статьей:
Наш коллега @Dragokas разработал скрипт, который фильтрует строки журнала SFC, исключая записи об успешных операциях проверки и оставляя только информацию о повреждениях и успешно исправленных записях.
Всем привет.
Начну с небольшого определения:
Что такое cbs.log?
Файл-лог журнала обслуживания windows, который содержит подробные сведения об ошибках автономного обслуживания, подробные сведения об ошибках интерактивного обслуживания, а так же как вспомогательный элемент для dism.exe
Не вдаваясь в тонкости осмысливания написанного ( определение взято отсюда ) сообщу следующее:
Многим из нас знакома программа sfc.exe, с помощь которой можно проверить состояние целостности защищенных системных файлов.
(Обсуждение в этой теме: Обзор утилиты sfc.exe )
Результат ее работы будет отражен как раз так же в этом логе.
Но, для большинства пользователей, анализ результата проверки остается трудновыполнимой задачей.
Хорошо, если система рапортует о том, что защита ресурсов wiindows не обнаружила поврежденных файлов или что все поврежденные файлы восстановлены.
А что делать, если мы видим что то вроде такого сообщения?
Программа защиты ресурсов Windows обнаружила поврежденные файлы, но не может восстановить некоторые из нихОдин из шагов к решению проблемы - это произвести анализ лога, который создается при сканировании. Лог-файл находится по пути
%windir%\logs\cbs\cbs.log и открыть его можно любым текстовым редактором, включая стандартный notepad.Неподготовленный пользователь, открыв и посмотрев лог, скорее всего испытает острое желание закрыть файл и больше не открывать. Поэтому, для комфорта восприятия, пользователи придумали приводить лог в более читабельный вид, распарсив его и отфильтровав "лишние" записи оставить только те, что нужны.
Сделать это можно разными методами, кстати - в сети распространен метод с парсингом файла cbs.log введя в командной строке простую команду:
CMD/BATCH:
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Это значит, что мы должный найти точно такую же версию файла и произвести замену в указанном каталоге.
Равно как и в каталоге 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"Если найти в базе Microsoft соответствующую ссылку, то там в перечне изменяемых файлов мы как раз увидим, что обновление выполняет установку файла необходимой версии.
Другими словами решением будет - переустановка обновления KB3159398.
Вот еще один интересный вариант, который вам может попасться в логе:
Код:
9:15, Error CSI 00000187 (F) Failed on regenerating file [l:22{11}]"browaub.ttf"[gle=0x80004005]Здесь говорится о том, что попытка восстановления файла была завершена с ошибкой 0x80004005
Не буду вас гонять по поисковикам и скажу сразу что в данном случае процесс блокировал брандмауэр Windows, как бы бредово это не звучало)
P.S.
Далее будут в таком же формате излагаться другие варианты, если есть вопросы и замечания пишите.
Последнее редактирование модератором:
