Co to jest CBS.log i dlaczego rośnie do gigabajtów

Component-Based Servicing w jednym akapicie

CBS to skrót od Component-Based Servicing — mechanizm stojący za Windows Update, opcjonalnymi funkcjami i naprawami DISM. Komponenty są przygotowywane z magazynu WinSxS, pakiety aplikowane wewnątrz transakcji należących do TrustedInstaller, a awaria kroku cofa całość — i każdy z tych kroków ląduje w CBS.log, wiersz po wierszu, ze znacznikami czasu i kodami błędów. Raporty System File Checker trafiają do tego samego pliku — wiersze [SR], które zostawia sfc /scannow, wyławia się poleceniem findstr /c:"[SR]", gdy komuś potrzebne są szczegóły. Zdrowa maszyna zbiera przez miesiące dziesiątki megabajtów takiego dziennika; nie ma tu czego czyścić, bo nic nie jest zepsute.

Ten log to więc przyrząd diagnostyczny, a nie śmieć. Istnieje właśnie na dzień, w którym coś się posypie: gdy aktualizacja wykłada się na 87% albo instalacja funkcji odmawia zatwierdzenia, w CBS.log zapisywany jest właściwy błąd — nie ten ogólnikowy, który pokazuje aplikacja Ustawienia.

Co nadyma go do gigabajtów

Wzrost do skali gigabajtów ma jedną dominującą przyczynę: pętlę ponawiania. Aktualizacja wykłada się na tym samym kroku, Windows planuje ponowienie, ponowienie wykłada się tak samo, a każda próba dopisuje tysiące wierszy. Typowe wyzwalacze to uszkodzenie magazynu komponentów (rodzina 0x80073712 i 0x800f081f), pakiet wiszący w stanie oczekującym, który nigdy nie może się zatwierdzić, albo błędy dysku przerywające transakcję TrustedInstallera w pół. Maszyna uwięziona w takim cyklu potrafi dokładać setki megabajtów dziennie — i wtedy log przestaje być problemem, a staje się licznikiem objawów.

Jeśli twój CBS.log jest olbrzymi, powstrzymaj ochotę na zwykłe usunięcie i pójście dalej. Plik chroni własność TrustedInstaller, więc gołe delete i tak odbija się od ściany; zmiana nazwy wymaga uprzedniego przejęcia własności, a zanim to skończysz, niszczysz dokładnie ten zapis, który wymienia zawodny pakiet i kod błędu.

• CBS.log rośnie o dziesiątki megabajtów dziennie lub więcej
• ten sam KB psuje się w historii aktualizacji w kółko
• TrustedInstaller mieli CPU godzinami po każdym rozruchu
• DISM /CheckHealth lub /ScanHealth zgłasza uszkodzenie magazynu
• błędy w stylu 0x80073712 czy 0x800f081f powtarzają się w logu
• maszyna podejrzanie długo stoi na „Praca nad aktualizacjami”

Napraw pętlę, nie plik

Sekwencja, która faktycznie działa: uruchom DISM /Online /Cleanup-Image /RestoreHealth, żeby naprawić magazyn komponentów, potem sfc /scannow, potem restart i jeszcze jedna próba Windows Update — w tej kolejności, bo DISM naprawia to, na czym musi pracować SFC. Sprawdź potem historię aktualizacji: jeśli jeden konkretny KB dalej pada, wstrzymaj aktualizacje i poczekaj na kolejne wydanie skumulowane zamiast pozwalać pętli mielić. Gdy pętla umiera, CBS.log wraca do swoich normalnych dziesiątek megabajtów i tam zostaje.

Narzędzia czyszczące reklamujące „zmniejszanie CBS.log” leczą paragon, a nie zakup. Usunięcie loga niczego nie zmienia w przyczynie padów aktualizacji; odbiera tylko dowody. Zmiana nazwy ma sens w skrajnych przypadkach — wielogigabajtowy log na małym dysku, po naprawieniu pętli — i tylko wtedy, z uprawnieniami TrustedInstaller, przy pełnej świadomości, że kasujesz dziennik.

Pytania i odpowiedzi

Przeczytaj także