Component-Based Servicing в одном абзаце
CBS — это Component-Based Servicing, обслуживающий стек: механизм, стоящий за Центром обновления, необязательными компонентами и восстановлением через DISM. Он готовит компоненты из хранилища WinSxS, применяет пакеты в транзакциях, которыми владеет TrustedInstaller, и откатывает всё назад при сбое шага; каждый шаг пишется в CBS.log, строка за строкой, с метками времени и кодами ошибок. Туда же попадают отчёты проверки системных файлов: строки [SR], оставляемые sfc /scannow, выуживают командой findstr /c:"[SR]", когда нужны подробности. Здоровая машина накапливает десятки мегабайт такого дневника за месяцы; чистить там нечего, потому что чинить нечего.
Так что лог — диагностический прибор, а не мусор. Он существует именно на день поломки: когда обновление падает на 87% или установка компонента отказывается фиксироваться, настоящий код ошибки — не общий, который показывает Параметры, — записан именно здесь.
Что раздувает его до гигабайтов
Гигабайтный рост почти всегда объясняется одним: циклом повторов. Обновление падает на одном и том же шаге, Windows назначает повтор, повтор падает так же, и каждая попытка пишет тысячи строк. Типичные триггеры — повреждение хранилища компонентов (семейство 0x80073712 и 0x800f081f), пакет в состоянии pending, который никак не может зафиксироваться, ошибки диска, обрывающие транзакцию TrustedInstaller посередине. Застрявшая таким образом машина может добавлять по сотне-другой мегабайт в день — и тогда лог уже не проблема, а счётчик симптомов.
Если ваш CBS.log распух, не спешите его удалить и забыть. Файл защищён владением TrustedInstaller, обычное удаление всё равно отскочит; переименовать его можно, лишь забрав владение, а к тому моменту вы уничтожите единственную запись, где названы падающий пакет и код ошибки.
- CBS.log прибавляет десятки мегабайт в день и больше
- один и тот же KB раз за разом падает в истории обновлений
- TrustedInstaller часами ест процессор после каждой загрузки
- DISM /CheckHealth или /ScanHealth сообщает о повреждении хранилища
- ошибки вроде 0x80073712 или 0x800f081f повторяются в логе
- машина подозрительно долго висит на «Установка обновлений»
Лечить цикл, а не файл
Последовательность, которая реально работает: DISM /Online /Cleanup-Image /RestoreHealth для ремонта хранилища компонентов, затем sfc /scannow, затем перезагрузка и новая попытка обновления — именно в таком порядке, потому что DISM чинит то, на чём работает SFC. Потом загляните в историю обновлений: если раз за разом падает один конкретный KB, поставьте обновления на паузу и дождитесь следующего накопительного пакета вместо того, чтобы позволять циклу молотить. Когда цикл мёртв, CBS.log возвращается к своим десяткам мегабайт и там остаётся.
Чистильщики, рекламирующие «сжатие CBS.log», лечат чек, а не покупку. Удаление лога ничего не меняет в причинах падения обновлений — оно лишь уничтожает улики. Переименовывайте его в крайних случаях — многогигабайтный лог на маленьком диске, уже после починки цикла — и только тогда, с правами TrustedInstaller, понимая, что стираете дневник.
Вопросы и ответы
Можно ли удалить CBS.log?
Windows продолжит работать — файл создастся заново, — но вы потеряете запись о том, почему падают обновления, а для удаления всё равно нужны права TrustedInstaller. Сначала почините цикл обслуживания: лог тогда сам останется маленьким.
Почему CBS.log занимает несколько гигабайтов?
Почти всегда потому, что обновление или восстановление раз за разом падает и повторяется, а каждая попытка пишет тысячи строк. DISM /RestoreHealth, а затем sfc /scannow обычно останавливают цикл.
Понятно до покупки: что входит в лицензию
Разовый 30-минутный триал даёт доступ к базовым инструментам. Возможности с меткой PRO остаются закрыты до активации платной лицензии.
Читайте также
Написать нам: [email protected]