Was ist die CBS.log – und warum wächst sie auf Gigabytes?

Component-Based Servicing in einem Absatz

CBS steht für Component-Based Servicing – den Wartungsstapel hinter Windows Update, optionalen Features und DISM-Reparaturen. Er stellt Komponenten aus dem WinSxS-Speicher bereit, wendet Pakete in Transaktionen an, die TrustedInstaller besitzt, und rollt alles zurück, wenn ein Schritt scheitert; jeder dieser Schritte landet Zeile für Zeile mit Zeitstempel und Fehlercode in der CBS.log. Auch der Systemdateiprüfter schreibt hierher – die [SR]-Zeilen von sfc /scannow fischt man sich bei Bedarf mit findstr /c:"[SR]" heraus. Eine gesunde Maschine sammelt über Monate zig Megabytes dieses Tagebuchs; es gibt nichts zu bereinigen, weil nichts kaputt ist.

Das Log ist also ein Diagnoseinstrument, kein Müll. Es existiert genau für den Tag, an dem etwas bricht: Wenn ein Update bei 87% abstürzt oder eine Feature-Installation sich nicht festsetzen will, steht der echte Fehler – nicht der generische aus der App „Einstellungen“ – hier drin.

Was sie auf Gigabytes aufbläht

Gigabytewachstum hat eine dominante Ursache: eine Wiederholungsschleife. Ein Update scheitert am selben Schritt, Windows setzt einen neuen Versuch an, der scheitert genauso, und jeder Versuch schreibt tausende Zeilen. Typische Auslöser sind ein beschädigter Komponentenspeicher (die Familie 0x80073712 und 0x800f081f), ein ausstehendes Paket, das sich nie festsetzen kann, oder Datenträgerfehler, die TrustedInstallers Arbeit mitten in der Transaktion abreißen lassen. Eine so festhängende Maschine kann pro Tag hunderte Megabytes hinzufügen – und dann ist das Log nicht mehr das Problem, sondern der Symptomzähler.

Ist Ihre CBS.log riesig, widerstehen Sie dem Drang, sie einfach zu löschen. Die Datei gehört TrustedInstaller, ein gewöhnlicher Löschversuch prallt ohnehin ab; zum Umbenennen brauchen Sie erst den Besitz – und bis dahin haben Sie genau die Aufzeichnung vernichtet, die das scheiternde Paket und den Fehlercode nennt.

Die CBS.log wächst um zig Megabytes pro Tag oder mehr
dieselbe KB scheitert im Updateverlauf immer wieder
TrustedInstaller frisst nach jedem Boot stundenlang CPU
DISM /CheckHealth oder /ScanHealth meldet Speicherschäden
Fehler wie 0x80073712 oder 0x800f081f wiederholen sich im Log
die Maschine hängt ungewöhnlich lange bei „Updates werden installiert“

Die Schleife heilen, nicht die Datei

Die Reihenfolge, die tatsächlich funktioniert: DISM /Online /Cleanup-Image /RestoreHealth zur Reparatur des Komponentenspeichers, danach sfc /scannow, dann Neustart und ein neuer Updateversuch – genau in dieser Ordnung, weil DISM das repariert, worauf SFC aufbaut. Prüfen Sie danach den Updateverlauf: Scheitert immer wieder dieselbe KB, pausieren Sie Updates und warten auf das nächste kumulative Paket, statt die Schleife weiter schleifen zu lassen. Ist die Schleife tot, kehrt die CBS.log zu ihren gewohnten zig Megabytes zurück und bleibt dort.

Aufräum-Tools, die das „Verkleinern der CBS.log“ anpreisen, behandeln den Beleg, nicht den Einkauf. Das Löschen des Logs ändert nichts daran, warum Updates scheitern; es beseitigt nur die Beweise. Benennen Sie sie nur in Extremfällen um – ein gigabytegroßes Log auf kleinem Laufwerk, nach behobener Schleife – und nur dann, mit TrustedInstaller-Berechtigungen, im Wissen, dass Sie das Tagebuch ausradieren.

Fragen und Antworten

Kann man CBS.log löschen?

Windows läuft weiter – die Datei entsteht neu –, aber Sie verlieren die Aufzeichnung, warum Updates scheitern, und brauchen fürs Löschen ohnehin TrustedInstaller-Rechte. Beheben Sie zuerst die Wartungsschleife; das Log bleibt dann von selbst klein.

Warum belegt die CBS.log mehrere Gigabytes?

Fast immer, weil ein Update oder eine Reparatur wiederholt scheitert und neu anläuft, und jeder Versuch tausende Zeilen schreibt. DISM /RestoreHealth gefolgt von sfc /scannow stoppt die Schleife meist.