Che cos'è CBS.log e perché arriva a pesare gigabyte

Component-Based Servicing in un paragrafo

CBS sta per Component-Based Servicing — l'ingranaggio dietro Windows Update, le funzionalità opzionali e le riparazioni DISM. Prepara i componenti dall'archivio WinSxS, applica i pacchetti dentro transazioni di proprietà di TrustedInstaller e riporta tutto indietro se un passo fallisce; ognuno di quei passi finisce in CBS.log, riga per riga, con timestamp e codici d'errore. Lì finiscono anche i rapporti di System File Checker — le righe [SR] che sfc /scannow si lascia dietro si pescano con findstr /c:"[SR]" quando servono i dettagli. Una macchina sana accumula decine di megabyte di questo diario in mesi; non c'è niente da pulire perché niente è rotto.

Il log è quindi uno strumento diagnostico, non spazzatura. Esiste apposta per il giorno in cui qualcosa si rompe: quando un aggiornamento si blocca all'87% o l'installazione di una funzione non vuole proprio concludersi, CBS.log è dove viene registrato l'errore vero — non quello generico che ti mostra l'app Impostazioni.

Cosa lo gonfia fino ai gigabyte

La crescita su scala gigabyte ha una causa dominante: un ciclo di retry. Un aggiornamento fallisce sempre allo stesso passo, Windows programma un tentativo, il tentativo fallisce allo stesso modo e ogni passata scrive migliaia di righe. I detonatori tipici sono il danneggiamento dell'archivio dei componenti (la famiglia 0x80073712 e 0x800f081f), un pacchetto in sospeso che non riesce mai a fare commit oppure errori del disco che fanno fallire il lavoro di TrustedInstaller a metà transazione. Una macchina impantanata così può accumulare centinaia di megabyte al giorno — e a quel punto il log non è più il problema, è il contatore dei sintomi.

Se il tuo CBS.log è enorme, resisti alla tentazione di eliminarlo e voltare pagina. Il file è protetto dalla proprietà di TrustedInstaller, quindi un semplice delete rimbalza comunque; rinominarlo richiede prima di assumerne la proprietà, e quando hai finito hai distrutto proprio il record che nomina il pacchetto difettoso e il codice d'errore.

• CBS.log cresce di decine di megabyte al giorno o più
• lo stesso KB fallisce in continuazione nella cronologia degli aggiornamenti
• TrustedInstaller consuma CPU per ore dopo ogni avvio
• DISM /CheckHealth o /ScanHealth segnala danni all'archivio
• errori come 0x80073712 o 0x800f081f si ripetono nel log
• la macchina resta insolitamente a lungo su «Elaborazione degli aggiornamenti»

Curare il ciclo, non il file

La sequenza che funziona davvero: esegui DISM /Online /Cleanup-Image /RestoreHealth per riparare l'archivio dei componenti, poi sfc /scannow, poi riavvia e lascia riprovare Windows Update — in quest'ordine, perché DISM sistema ciò su cui SFC deve lavorare. Controlla dopo la cronologia degli aggiornamenti: se uno specifico KB continua a fallire, sospendi gli aggiornamenti e attendi il prossimo rilascio cumulativo invece di lasciare macinare il ciclo. Una volta morto il ciclo, CBS.log torna ai suoi normali decine di megabyte e ci resta.

Gli strumenti di pulizia che pubblicizzano lo «restremento di CBS.log» curano lo scontrino, non l'acquisto. Eliminare il log non cambia nulla sul perché gli aggiornamenti falliscono; toglie solo le prove. Rinominalo nei casi estremi — un log di svariati gigabyte su un disco piccolo, dopo aver sistemato il ciclo — e solo allora, con i permessi di TrustedInstaller, sapendo di cancellare il diario.

Domande e risposte

Da leggere dopo