Pliki dzienników CBS.log i DISM.log: Jak analizować błędy aktualizacji i integralności systemu Windows?

Pliki CBS.log i DISM.log to Twoi najlepsi przyjaciele, gdy system Windows odmawia współpracy po aktualizacji, `sfc /scannow` zgłasza błędy, lub po prostu masz wrażenie, że coś jest nie tak. Służą one do szczegółowego rejestrowania procesów instalacji, modyfikacji i weryfikacji komponentów systemu, pozwalając na precyzyjne zdiagnozowanie problemów z integralnością i aktualizacjami. Dzięki nim dowiesz się, co poszło nie tak i gdzie szukać przyczyny awarii.

Co to za pliki i gdzie je znajdziesz?

Zacznijmy od podstaw, bo lokalizacja jest kluczowa. Oba pliki to dzienniki tekstowe o rozszerzeniu `.log`.

• CBS.log: Ten plik, czyli Component Based Servicing log, znajdziesz w katalogu `C:\Windows\Logs\CBS\`. Jest to główny dziennik usługi Instalator modułów systemu Windows (inaczej TrustedInstaller.exe). Zapisuje on absolutnie wszystko, co dzieje się podczas instalacji, konfiguracji, odinstalowywania i naprawiania komponentów systemu, a także wszelkich aktualizacji czy pakietów serwisowych. U mnie potrafi osiągać nawet 200-300 MB, zwłaszcza po kilku nieudanych próbach aktualizacji.
• DISM.log: Dziennik narzędzia Deployment Image Servicing and Management (DISM). Główne pliki dziennika DISM znajdują się w `C:\Windows\Logs\DISM\dism.log`. To tutaj zapisywane są wszystkie operacje wykonywane za pomocą narzędzia `dism.exe`, które służy do serwisowania obrazów systemu Windows, sprawdzania i naprawy magazynu komponentów, czy dodawania/usuwania funkcji systemowych. DISM często współdziała z TrustedInstallerem, więc znajdziesz tam odwołania do działań, które później są szczegółowo opisane w CBS.log.

Do czego służą i kto ich używa?

Te pliki są nieocenione w diagnostyce, zwłaszcza gdy mówimy o problemach z aktualizacjami Windows lub uszkodzonymi plikami systemowymi.

• CBS.log jest wykorzystywany głównie przez systemową usługę TrustedInstaller oraz narzędzie System File Checker (sfc.exe). Kiedy uruchamiasz `sfc /scannow`, narzędzie to skanuje integralność plików systemowych i jeśli znajdzie uszkodzenia, próbuje je naprawić. Cały ten proces, wraz z informacjami o plikach, które nie mogły zostać naprawione, jest szczegółowo zapisywany w CBS.log. Bez tego pliku praktycznie nie miałbyś szansy zidentyfikować, które dokładnie pliki są uszkodzone i dlaczego `sfc` nie dał rady ich naprawić. U mnie pierwszy raz to było zbawienie, gdy sfc wyświetliło ogólny błąd i tylko w logu znalazłem konkretną nazwę uszkodzonego pliku DLL.
• DISM.log z kolei służy narzędziu DISM.exe. To kluczowe, gdy `sfc /scannow` zawiedzie. Wtedy często uruchamiasz DISM z parametrami `RestoreHealth` lub `CheckHealth`, aby naprawić sam magazyn komponentów Windows, z którego `sfc` czerpie „zdrowe” wersje plików. DISM zapisuje w swoim logu każdą operację – od skanowania magazynu po próbę pobrania i zastosowania poprawek. Jeśli DISM napotka problem (np. nie znajdzie źródła do naprawy), znajdziesz to w DISM.log.

Czy to wirus? Czy można je usunąć i co się stanie?

Zdecydowanie nie są to wirusy. To całkowicie legalne i niezbędne pliki systemowe, tworzone i zarządzane przez sam system Windows.

Czy można je usunąć? Technicznie tak, ale nie jest to zalecana praktyka dla zwykłego użytkownika. Są to pliki systemowe i mają podwyższone uprawnienia dostępu. System Windows na bieżąco do nich zapisuje i automatycznie je odtworzy, jeśli zostaną usunięte. Natomiast częściej niż „usuwanie” stosuje się resetowanie lub archiwizowanie tych dzienników w celach diagnostycznych. Jeśli chcesz rozpocząć nową sesję diagnostyczną z czystym dziennikiem:

• Przejdź do `C:\Windows\Logs\CBS`.
• Znajdź `CBS.log` oraz `CBSPersist_*.log` (archiwa).
• Zmień nazwę `CBS.log` na `CBS_OLD.log` (lub przenieś go w bezpieczne miejsce).
• Zrób to samo z `dism.log` w `C:\Windows\Logs\DISM`.
• Po restarcie lub uruchomieniu usługi TrustedInstaller/DISM, system automatycznie utworzy nowe, puste pliki `CBS.log` i `DISM.log`.

Konsekwencje usunięcia? Utrata historii zdarzeń systemowych, co utrudni analizę wcześniejszych problemów. Poza tym system sam zadba o ich rozmiar, archiwizując starsze wpisy do plików `CBSPersist_*.log` lub kompresując je.

Typowe problemy i jak je analizować

Najczęściej zaglądam do tych logów, gdy mam problem z:

• Nieudane aktualizacje Windows: System pobiera, instaluje, a potem wycofuje zmiany lub wyświetla błąd ogólny.
• `sfc /scannow` zgłasza, że nie może naprawić wszystkich plików: To klasyk!
• Narzędzie DISM zgłasza błędy: Szczególnie `Error: 0x800f081f` (nie znaleziono plików źródłowych) lub `Error: 0x80070002`.

Jak analizować?

1. Otwórz plik w Notatniku lub Notepad++ (zalecam Notepad++ dla dużych plików).

2. Szukaj kluczowych słów:

• `ERROR`
• `FAIL`
• `Warning`
• `Could not`
• `0x` (kody błędów heksadecymalnych)
• `[SR]` (oznaczenia od `sfc`)
• `[DISM]` (oznaczenia od `dism`)

3. W CBS.log skup się na ostatnich wpisach po nieudanej operacji `sfc`. Często znajdziesz tam linijki typu `[SR] Cannot repair member file…` z konkretną ścieżką i nazwą pliku.

4. W DISM.log poszukaj linijek zaczynających się od `Error` lub `Failed`. To da Ci wskazówkę, co poszło nie tak podczas próby naprawy magazynu komponentów. Pamiętam, jak kiedyś po nieudanej aktualizacji systemu Windows, spędziłem niemal godzinę na przeszukiwaniu `CBS.log` w poszukiwaniu `ERROR` i `fail`, aż w końcu znalazłem informację o uszkodzonym sterowniku, który blokował całą operację. U mnie pierwszy raz wyszło dopiero za trzecim razem.

Dlaczego są to pliki systemowe i chronione?

Pliki CBS.log i DISM.log są traktowane jako pliki systemowe i podlegają ochronie, co oznacza, że dostęp do nich, a zwłaszcza możliwość modyfikacji czy usunięcia, jest ograniczony. Dlaczego? Głównie z trzech powodów:

• Integralność: Aby zapobiec celowemu lub przypadkowemu uszkodzeniu dzienników, co mogłoby uniemożliwić prawidłową diagnostykę.
• Niezawodność: System musi mieć pewność, że wszystkie krytyczne zdarzenia są rejestrowane w sposób ciągły i niezmienny.
• Bezpieczeństwo: Modyfikacja logów mogłaby służyć do ukrywania śladów złośliwego oprogramowania lub działań nieautoryzowanych.

Najczęstsze pytania

Czy muszę ręcznie usuwać stare pliki logów?

Nie, system Windows zarządza nimi automatycznie. Starsze wpisy są kompresowane lub przenoszone do plików archiwum (np. `CBSPersist_*.log`), aby utrzymać rozsądny rozmiar głównego `CBS.log`.

Co zrobić, gdy logi są zbyt duże i spowalniają system?

Choć same pliki logów rzadko spowalniają system, możesz je „zresetować” zmieniając ich nazwy, tak jak opisano powyżej. Pamiętaj jednak, że utracisz wtedy historię.

Następnym razem, gdy Windows Update zastrajkuje, otwórz `CBS.log` i poszukaj frazy `ERROR`. To pierwszy krok do samodzielnego rozwiązania problemu!