Що таке CBS.log і чому він розростається до гігабайтів

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, розуміючи, що стираєте щоденник.

Питання та відповіді

Читайте також