Cbs log error

При проверке целостности системных файлов с помощью утилиты SFC пользователь может получить сообщение об обнаружении ряда повреждённых файлов, восстановить которые не удалось. Данные о таких файлах система записывает в файл CBS.log, открыть который также не удаётся по различным причинам (в частности из-за повреждения данного файла). В данном материале я разберу, что предпринять в такой ситуации, и каким образом исправить дисфункцию windirLogsCBSCBS.log повреждён на вашем ПК

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

Системная утилита SFC, предназначенная для проверки целостности системных файлов ОС Виндовс, записывает данные по проверке и восстановлению файлов в файл CBS.log. Последний расположен по адресу %windir%LogsCBS, и может быть недоступным при попытке просмотреть его содержимое стандартным способом (через «Блокнот», файловый менеджер и др.).

Это может быть связано с закрытием доступа к данному файлу со стороны Виндовс, а также с повреждением данного файла по различным причинам (вирусы, осыпание диска, другие релевантные причины).

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

Как исправить ошибку WindirLogsCBSCBS.log

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

после чего нажать на ввод. Файл данного лога будет сохранён на рабочем столе вашего PC, и вы сможете его просмотреть через самый обычный «Блокнот». Во время данного просмотра, в частности, вы можете увидеть, какие именно файлы утилита SFC посчитала повреждёнными, и скопировать их из стабильной системы.

Если же после запуска и работы утилиты SFC система выдала текст о невозможности восстановления ряда файлов, и записи информации об них в файле CBS, тогда выполните следующее:

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

затем

а уже потом

Дождитесь полного окончания данных процедур (могут занять полчаса-час), а затем перезагрузите ваш PC. После этого всё должно стабильно работать.

Альтернативные решения при повреждении CBS.log

В ряде случаев причиной возникновения проблемы является действие вирусных программ и осыпание диска. В первом случае рекомендуется проверить ваш PC с помощью соответствующего антивирусного инструментария (например, Доктор Веб Кюрейт, AdwCleaner и других аналогов). Затем перезагрузить ПК, и постараться вновь получить доступ к данному лог-файлу.

В случае осыпания диска, рекомендую воспользоваться такими утилитами как «Victoria HDD», «HDD Regenerator» и других, которые проверят ваш диск на наличие битых секторов, и при возможности восстановят его.

Заключение

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

Всем привет.

Начну с небольшого определения:
Что такое cbs.log?

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

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

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

Обзор утилиты sfc.exe

)
Результат ее работы будет отражен как раз так же в этом логе.
Но, для большинства пользователей, анализ результата проверки остается трудновыполнимой задачей.

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

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

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

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

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

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

Проверка целостности системных файлов утилитой sfc

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

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

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

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

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

* предварительно необходимо

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

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

Вернемся, непосредственно, к файлу 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 SystemRootWinSxSx86_microsoft-windows-grouppolicy-script_31bf3856ad364e35_6.1.7601.23452_none_677acd98e72e71ccgpscript.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 SystemRootWinSxSx86_microsoft-windows-grouppolicy-script_31bf3856ad364e35_6.1.7601.23452_none_677acd98e72e71ccgpscript.exe
Версия его: Version = 6.1.7601.23452 и на него ссылается компонент патча KB3159398.
Открываем упомянутый патч на сайте Microsoft:
Download Обновление для системы безопасности Windows 7 (KB3159398) from Official Microsoft Download Center
Находим там ссылку «Связанные ресурсы», переходим.
https://support.microsoft.com/ru-ru…-the-security-update-for-group-policy-june-14
Открываем сведения о файлах и находим тот, что нам нужен:

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

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

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

Почему?

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

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

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

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

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

Можно попытаться выполнить автоматическое восстановление хранилища компонентов через пункт «Расширенная проверка и восстановление файлов» скрипта, или запустив командную строкуот имени Администратора и ввести команду:
(Для Windows 8 — 10)
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:WindowsSysWOW64userinit.exe; source file in store is also corrupted

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

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

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

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

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

Notepad++

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

2017-10-26 23:38:05, Info                  CSI    000041c2 Hashes for file member SystemRootWinSxSwow64_microsoft-windows-userinit_31bf3856ad364e35_10.0.15042.0_none_f7a5dd2f3ed02235userinit.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:WindowsSysWOW64userinit.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 SystemRootWinSxSwow64_microsoft-windows-userinit_31bf3856ad364e35_10.0.15042.0_none_f7a5dd2f3ed02235userinit.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:WindowsSysWOW64userinit.exe; source file in store is also corrupted

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

SystemRootWinSxSwow64_microsoft-windows-userinit_31bf3856ad364e35_10.0.15042.0_none_f7a5dd2f3ed02235userinit.exe

Запомните, что SystemRootWinSxS — это адрес расположения хранилища данных.
Где 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:WindowsSysWOW64userinit.exe
Тут есть особенность: так как произвести замену C:WindowsSysWOW64userinit.exe в загруженной системе вряд ли удастся, то вам либо придется сделать это из среды восстановления (в таком случае путь будет Х:Windowsuserinit.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 SystemRootWinSxSx86_microsoft-windows-grouppolicy-script_31bf3856ad364e35_6.1.7601.23452_none_677acd98e72e71ccgpscript.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.
Далее будут в таком же формате излагаться другие варианты, если есть вопросы и замечания пишите.

Проблемы с файлом CBS.log встречаются нередко. Из расширения становится ясно, что это файл-лог. В нем хранятся изменения в статичных системных файлах. В случае если файл CBS.log поврежден или отсутствует, система не может гарантировать стабильность работы. появляется ошибка ERROR Can not open file «C:WindowsLogsCBSCBS.log». Давайте попробуем разобраться в причинах данной ошибки, а ниже дадим рекомендации по ее устранению.

Причины

Повредить хранимые данные могут:

• вирусы;
• обновления Windows;
• обновления драйверов оборудования;
• установленные приложения;
• неполная установка приложений, обновлений;
• повреждения жесткого диска или его износ;
• конфликт оборудования или программ.

Вследствие этого возникают следующие проблемы:

1. повреждение ключей реестра;
2. удаление или повреждение непосредственно самого файла;
3. стирание вспомогательных файлов.

В результате пользователь получает сообщения о том, что CBS.log не найден (отсутствует), возникли ошибки его работы (ошибка загрузки, не удалось загрузить) и прочие: ошибка выполнения, не удалось зарегистрировать и сообщение ERROR Can not open file «C:WindowsLogsCBSCBS.log».

О том, что делать в таких ситуациях, далее и пойдет речь

Способы восстановления

Итак, рассмотрим возможные варианты по порядку увеличения их сложности и начнем с чистки реестра Windows.

Чистка реестра

Так как причина может крыться во всевозможных остаточных файлах и пустых ключах, то начнем именно отсюда. Перед проведением процедуры рекомендуем заготовить резервную копию реестра и использовать специальные программы: CCleaner, JV-16 Power Tools и прочие.
В этом случае нужно сделать несколько шагов.

• Найти раздел «Работа с реестром» в выбранной утилите.
• Создать резервную копию реестра.
• Нажать кнопку поиска неисправностей.
• Произвести чистку.

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

Поиск вредоносных объектов

Как и в предыдущем методе, ничего делать самому не нужно – все сделает выбранное приложение. В качестве лечащей утилиты можно использовать Dr. Web CureIt!, NOD32 и прочие.

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

Восстановление системы

Если все вышеперечисленное не решило проблемы, то можно воспользоваться восстановлением системы. Для этого нужно сделать следующее.

1. Нажать «Пуск».
2. В поисковой строке набрать «восстановление системы».
3. Начать процедуру от имени Администратора.
4. Следовать инструкциями.

Альтернативным вариантом является инициирование процесса при запуске загрузочного диска. Еще один способ активации службы – восстановление при загрузке. Для этого нужно нажимать клавишу «F8» (несколько раз) после включения компьютера. В появившемся окне выбрать пункт «Восстановление Windows», и дождаться завершения процедуры. Здесь же дополнительно можно выбрать «Устранение неполадок компьютера».

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

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

Как запустить средства проверки системных файлов?

1. Нажать «Пуск».
2. В поиске набрать «cmd» или «командная строка» и запустить ее от имени Администратора.
3. В открывшемся окне ввести: sfc /scannow.

   

   команда sfc/ scannow

4. Дождаться завершения процедуры.

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

Если же были обнаружены повреждения файла CBS.log, но восстановить его не удалось, то можно попробовать скопировать его с другого компьютера с соответствующей версией ОС.

Windows Update для Windows 8 и 8.1 дает возможность воспользоваться восстановлением хранилища. Чтобы сделать это, нужно открыть PowerShell от имени администратора, и в окне ввести: Dism /Online /Cleanup-Image /RestoreHealth. Против надписи Image Health State должно значиться Healthy. Восстановление самого хранилища может помочь, команда «sfc /scannow» выполняется с ошибками.

Завершение работ

Если же все вышеописанное не помогло и Файл CBS.log поврежден или отсутствует, как и ранее, то остается только один выход – чистая установка Виндовс. Напишите в комментариях какой из способов помочь вам решить проблему «файл CBS.log поврежден» и вы знаете что делать в подобной ситуации. Если у вас остались вопросы — сообщите о них нам и мы постараемся помочь вам.

Иногда при проверке используемых ОС Виндовс системных элементов на экране возникает сообщение о том, что применяемый инструмент обнаружил файлы, которые являются поврежденными, но исправить ситуацию не удалось. После этого пользователь может захотеть просмотреть информацию по этой проблеме с помощью специального файла, где сохраняются подобные сведения, но видит перед собой очередное окошко — windirLogsCBSCBS.log файл поврежден.

Что такое CBS.log? Это специальный и очень важный компонент Windows, который операционка заносит все изменения, связанные с работой системных файлов. То есть, при его повреждении существует вероятность того, что стабильная работа используемой ОС будет нарушена. Поэтому необходимо знать, как исправить возникшую ситуацию.

Основные причины возникновения такого сбоя

Существует несколько основных первопричин, которые при попытке перейти по ссылке «подробные сведения см в файле CBS.log» приводят к сообщению о ошибке:

1. Сама система заблокировала доступ к этому журналу Windows.
2. Используемый жесткий диск начал «сыпаться».
3. На винчестере завелись вирусные заражения.
4. Проблемы с системным реестром.

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

Инструкция по устранению ошибки

Вполне логично, что всегда следует начинать с наиболее простых решений. Поэтому изначально стоит попробовать такие действия:

• Есть очень удобная программа – CCleaner. Установить ее на жесткий диск. Можно воспользоваться и альтернативными вариантами ПО со схожим функционалом. После инсталляции, запустить и воспользоваться инструментов, позволяющим почистить реестр и исправить его ошибки;
• Выполнить установку на винчестер Dr. Web CureIt!, NOD32 или иных, схожих антивирусников. Обязательно с наличием свежей базы данных и актуальной версии. Прогнать операционку на наличие заражений и избавиться от них, в случае обнаружения;
• Через кнопочку «Пуск» перейти к встроенной в OS поисковой строке. Вбить в нее «восстановление системы» и перейти по предложенной ссылке. Действовать на основе автоматической инструкции.

Если методика не привела к нужному результату и при обращении к этому файлу все равно ОС отказывает в доступе, то следует перейти к следующему этапу.

Прежде всего можно попытаться получить доступ к этому файлу, который находится здесь: windirLogsCBSCBS.log. Как это сделать:

• Кликнуть на «Пуск» и в поисковой строке вбить «командная строка» (Win+R);
• Запустить предложенный вариант обязательно с правами администратора;
• В открывшемся окошке использовать следующую команду: %windir%logscbscbs.log/c: «[SR]» findstr ˃ sfcdetails.txt. В конце – точку не ставить! Обязательно соблюдать пробелы;
• Если команда набрана правильно, то после нажатия клавиши Enter», требуемый файлик будет перенесен на рабочий стол.

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

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

• Еще раз перейти в строку для ввода команд;
• Использовать в ней команду: dism /online /cleanup-image /checkhealth;
• Нажать на ввод, вбить очередной приказ: dism /online /cleanup-image /restorehealth;
• Очень важно соблюсти правильность расставления пробелов;
• Ну и завершить все уже классическим вариантом: sfc /scannow.

Запустится автоматический процесс проверки и исправления. Он может длиться достаточно долго. Поэтому нужно дождаться его завершения, обязательно перезапустить комп и оценить полученный результат.

Если же ситуация продолжает оставаться прежней, то следует обратить внимание на состояние используемого накопителя. Чтобы проверить винчестер на наличие битых секторов и попытаться как-то избавиться от них, рекомендуется воспользоваться одной из следующих программ: «Victoria HDD» или «HDD Regenerator». Важно понимать, если данное ПО найдет слишком много неисправляемых повреждений, то стоит оперативно начать собирать деньги на покупку нового жесткого диска.

Иногда может оказаться так, что все методики опробованы, винчестер находится в исправном состоянии, а ситуация остается без каких-то положительных изменений. В этом случае решение только одно – полная переустановка операционной системы.

Отзывы

Отзывы других юзеров позволят узнать, как именно они справились с подобной ситуацией:

1. Родион. Воспользовался инструкцией и вроде бы все исправилось. Но сразу же возникли новые последствия. Получил доступ к этому лог-файлу. Внутри информация про повреждение обновления КВ2966583. Полез в настройки – в Центр установки обновлений. Смотрю, там написано, что этот пакет установлен. Деактивировал его, нашел в интернете и просто заменил на новый.
2. Сергей. После проверки на вирусы и удаления заражений доступ к этому файлу получил спокойно. Обнаружил в нем наличие повреждений в hal.dll и ntoskrnl.exe. Вот теперь думаю, поможет ли, если я просто найду их в Сети и закину в систему? Просто знаю, что простое копирование не всегда помогает – требуется еще же внесение в системный реестр?
3. Александр. Ну вот неоднозначный у меня результат. Пробовал вводить эти команды. Например, %windir%logscbscbs.log/c: «[SR]» findstr > scfcdetails.txt приводит к тому, что Винда сообщает о неверном пути. А вот dism /online /cleanup-image /restorehealth прекрасно срабатывает. И вот после этого запускаю сканирование с помощью команды scannow и результат – лог-файл поврежден. Хотя доступ к нему, да – я получаю спокойно. В общем, буду проверять еще винчестер, так как вирусов на нем я не обнаружил.
4. Вася. В вводе этих команд очень важно соблюдать правила пробелов. Если хотя бы в одном из них будет совершенна ошибка, то команды просто не сработают. Я несколько раз невнимательно ввел, и только потом понял, как именно необходимо действовать – спасибо за уточнение в статье!
5. Олег. Некоторые люди почему-то пишут, что у них нет каких-то символов на клавиатуре. И они пытаются вписать команды с помощью комбинаций клавиш. Смотрите просто внимательно. Например, знак больше есть на клавише с «Ю». Нужно просто переключиться на английский язык и воспользоваться шифтом. Аналогичная ситуация с квадратными скобками. Двоеточия и проценты можно ввести при использовании русскоязычной раскладки!

Судя по оставленным комментариям, инструкция работает. Важно только правильно вводить все команды и понимать, что это решение позволяет только получить доступ к ЛОГ-файлу, а вот исправление описанных внутри поврежденных элементов делается уже индивидуально, в зависимости от ситуации.