Как исправить windir\Logs\CBS\CBS.log повреждён

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

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

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

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

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

Как исправить ошибку Windir\Logs\CBS\CBS.log

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

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

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

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

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

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

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

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

Утилита «Виктория HDD» поможет в проверке вашего диска

Почему размер файла CBS.log составляет 20 ГБ?

Два дня назад у меня был полный C: диск, после которого я удалил 8 ГБ данных. На следующий день жесткий диск снова был заполнен, поэтому я продолжил удаление еще 5 ГБ, и на следующий день диск снова был заполнен.

После некоторых поисков причин, по которым дисковое пространство заполнялось так быстро, я воспользовался этим windirstat инструментом, чтобы определить, какие файлы занимают больше всего места. Я обнаружил, что CBS.log размер файла c:\windows\logs\cbs\ 20 ГБ.

Я использую Windows 8.

• Должен ли этот файл быть таким большим, а если нет, как я могу уменьшить его размер?
• Какова цель этого файла?
• Могу ли я удалить это?

Это файл, который создается средством проверки ресурсов Microsoft Windows (SFC.exe).

Нет, оно не должно быть таким большим. CBS.persist.log должен генерироваться, когда размер CBS достигает около 50 мегабайт. CBS.log должен быть скопирован в cbs.persist.log, и должен быть запущен новый файл cbs.log.

Вы можете попробовать сжать файл:

• Если вы щелкните правой кнопкой мыши на файле CBS.log
• Затем нажмите на Свойства
• На вкладке Общие нажмите Дополнительно
• Установите флажок «Сжать содержимое для экономии места на диске» и нажмите «ОК».

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

100 МБ в вашей временной папке. Решение состоит в том, чтобы удалить файл журнала объемом 2 ГБ (это можно безопасно сделать, поскольку они используются только для устранения неполадок).

У меня был файл cbs.persist.log 17 ГБ, так как я был уверен, что это не я заполняю свой ssd, я искал необычные большие файлы в каталоге журналов Windows. В любом случае мог думать только о проблеме сжатия.

Итак, чтобы сбросить сжатие в папке CBS, я использовал следующий метод:

1. Отключите TrustedInstaller.exe (установщик модуля Windows) в службах диспетчера задач
2. Удалите все файлы .log в каталоге C: \ Windows \ Logs \ CBS , а также удалите файлы .persist и .cab
3. Снова включите TrustedInstaller.exe

ПРИМЕЧАНИЕ. Очистка папки CBS сбрасывает процесс сжатия, поэтому новые созданные файлы журналов не должны превышать 50 МБ до сжатия в CAB-файлы, как это должно быть.

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

Это решение все еще работает для меня на Windows 7/8 / 8.1 через 1 год

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

Надеюсь это поможет.

На всякий случай, если кто-то задается вопросом, почему это происходит в первую очередь. Я считаю, что я воспроизвел особые условия (я уверен, что есть другие варианты этих условий, которые могут вызвать тот же результат):

1. Я запустил очень большое количество очень больших обновлений Windows (кучу языковых пакетов и пакетов обновления и т. Д.), В то время как у меня также было открыто большое количество других приложений и окон (я разработчик). Затем я пошел на обед.
2. Центр обновления Windows работал, пока система не исчерпала память (RAM). У меня 32 гигабайта, но этого было недостаточно.
3. «Trusted Installer.exe» (служба «Установщик модуля Windows») пыталась сжать быстро растущий файл журнала, но не смогла запустить его, либо потому, что журнал рос слишком быстро, либо не мог запуститься из-за нехватки памяти, или оба. Поэтому, когда это было необходимо, служба установщика модулей Windows даже не запускалась вообще (даже временно).
4. С тех пор он не мог обрабатывать файл журнала, поскольку он был слишком большим для сжатия .CAB (около 25 гигабайт!), И поэтому начался порочный цикл, и ничто не могло его остановить (кроме как при ручном вмешательстве, как описано в « Джин «выше).
5. Как только размер файла журнала увеличился до 60 гигабайт на моем SSD, он занял все мое свободное пространство, и я получил предупреждение «недостаточно места на диске», и начал искать причину.

Кажется, следующий процесс устранил проблему: «отключите службу установщика модуля Windows, удалите содержимое папки C: \ Windows \ Logs \ CBS \ и папки« C: \ Windows \ Temp »- пропустите все используемые файлы, затем снова запустите службу установщика модулей Windows и установите для нее «ручной» запуск (по умолчанию) ». Перезагрузка.

В качестве обходного пути, в Windows 7, если служба «Установщик модулей Windows» остановлена, то ее запуск запускает процесс ротации журналов, который создает новый файл cbs.log и перемещает старый файл в сжатый архив CbsPersist .cab. Мой лог-файл 500 МБ был сжат до 30 МБ.

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

100 МБ в вашей временной папке. Решение состоит в том, чтобы удалить файл журнала объемом 2 ГБ (это можно безопасно сделать, поскольку они используются только для устранения неполадок). Большое спасибо SamB за публикацию, вы достигли первопричины этой проблемы. Я на Windows 7 SP1 64-разрядная. Я не могу поверить, что Microsoft еще не исправила это.

Windows занимает много места на диске.

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

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

Пользователи Windows иногда, между тем, сообщают о странном поведении системы. Используя методы обнаружения “поглотителей пространства” в статье “Почему жёсткий диск переполнен?” или правильные настройки дефрагментации с оптимизацией таблицы MFT, можно рассчитывать на временные положительные результаты. Однако к концу сеанса Windows занимает много места повторно : лог-файлы Windows накапливаются раз от раза, занимая порой сотни гигабайт, генерируя отдельные файлы пачками по 100 Мб каждый. “Вредная” папка вроде бы обнаружена – это C:\Windows\Temp, однако поделать нельзя ничего: файлы с раcширением .cab заполняют временное хранилище до тех пор, пока свободное место на диске не исчезнет совсем. Это действие схоже с манёвром трояна, замаскированного под антивирус, который к концу “сеанса” сожрёт всё свободное место на HDD.

Windows занимает много места: суть вопроса

Разрабам Windows об этой проблеме давно известно. Известно, что проблема проистекает от результатов работы Компонентно-Ориентированного Обслуживания системы (Component-Based Servicing), создающего порой логи неимоверных размеров. Располагаются оные в папке C:\Windows\Logs\CBS. Текущий лог именуется как cbs.log. Но как только он достигает в своём размере некоего значения, запускаемый процесс очистки сразу переименовывает этот файл в файл типа .log и сразу пытается его сжать в размерах, присвоив в итоге получившемуся файлу расширение .cab. при помощи системной утилиты makecab.exe. Но вот тут-то пользователя порой и подстерегает “бонус”: когда файл cbs.log достигает размера 2 Гб перед тем, как процесс очистки успевает к нему обратиться за сжатием, указанная утилита.. с ним справиться не может – а он, мол, уже слишком большой: утилита makecab.exe откровенно “тупит”, когда сталкивается с файлами таких размеров. Лог переименовывается в CbsPersist-время-дата.log и, когда makecab.exe пытается его сжать, появляется ошибка. Ошибка зацикливается и в итоге: каждые 15 – 30 мин. (у всех по-разному)

• утилита создаёт первые 100 МБ “компрессии” .cab
• натыкается на ошибку
• и повторяется всё тоже самое.

Windows занимает много места: вероятное решение

Итак, если вы столкнулись с ситуацией, когда раз от раза Windows занимает много места на жёстком диске, попробуйте так:

• на время работы “тормозим” службуУстановщик модулей Windows через консоль

• ищем папку C:\Windows\Logs\CBS и внутри папки переименуем все файлы (как угодно)
• ищем папку C:\Windows\Temp и удаляем все файлы cab
• перезагружаемся

Теперь makecab.exe не сможет неправильно обрабатывать файлы и захламление диска должно прекратиться. А если лог-файлы Windows не понадобятся, вы можете удалить и их.

Второй вариант

Скачайте, разархивируйте и запустите через Power Shell от имени администратора файл

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

Кирилл

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

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

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

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

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

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

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

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

Как быть?
Для более комфортного первоначального анализа мы с коллегами создали такой скрипт:
Проверка целостности системных файлов утилитой 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] пропускаем все что выглядит примерно так:

Сделать это легко — достаточно воспользоваться скроллом, потянув за него указателем мышки.
Почему пропустить? Файлы системой защиты проверяются блоками по 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 = , Type neutral, TypeName neutral, PublicKey neutral in the store, hash mismatch

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

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

Тут мы отчетливо видим, что файл в хранилище должен быть по адресу:
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. -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 — но он менее информативен.

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