Component-Based Servicing em um parágrafo
CBS significa Component-Based Servicing: a maquinaria por trás do Windows Update, dos recursos opcionais e das reparações do DISM. Ele prepara componentes da loja WinSxS, aplica pacotes em transações pertencentes ao TrustedInstaller e reverte tudo se um passo falha; cada um desses passos vai para o CBS.log, linha por linha, com carimbos de tempo e códigos de erro. O Verificador de Arquivos do Sistema também escreve aqui — as linhas [SR] deixadas por sfc /scannow se pescam com findstr /c:"[SR]" quando alguém quer os detalhes. Uma máquina saudável acumula dezenas de megabytes desse diário em meses; não há o que limpar porque não há nada quebrado.
O log é, portanto, um instrumento de diagnóstico, não lixo. Ele existe justamente para o dia em que algo quebra: quando uma atualização falha aos 87% ou uma instalação de recurso não consolida, o erro de verdade — não o genérico que o Configurações mostra — está anotado aqui.
O que o incha até os gigabytes
O crescimento na escala de gigabyte tem uma causa dominante: um loop de tentativas. Uma atualização falha no mesmo passo, o Windows agenda uma nova tentativa, ela falha do mesmo jeito, e cada tentativa escreve milhares de linhas. Gatilhos típicos são corrupção da loja de componentes (a família 0x80073712 e 0x800f081f), um pacote pendente que nunca consolida, ou erros de disco que cortam a transação do TrustedInstaller no meio. Uma máquina presa assim pode somar centenas de megabytes por dia — e aí o log já não é o problema, é o contador de sintomas.
Se o seu CBS.log está gigante, resista ao impulso de apagar e seguir em frente. O arquivo pertence ao TrustedInstaller e um delete comum quica de qualquer forma; renomeá-lo exige tomar posse antes, e quando você terminar terá destruído exatamente o registro que nomeia o pacote que falha e o código de erro.
- CBS.log cresce dezenas de megabytes por dia ou mais
- a mesma KB falha repetidamente no histórico de atualizações
- TrustedInstaller consome CPU por horas após cada boot
- DISM /CheckHealth ou /ScanHealth acusa dano na loja de componentes
- erros como 0x80073712 ou 0x800f081f se repetem no log
- a máquina demora demais em "Trabalhando nas atualizações"
Tratar o loop, não o arquivo
A sequência que funciona: DISM /Online /Cleanup-Image /RestoreHealth para reparar a loja de componentes, depois sfc /scannow, depois reinício e uma nova tentativa de atualização — nessa ordem, porque o DISM conserta aquilo sobre o que o SFC se apoia. Depois confira o histórico: se uma KB específica vive falhando, pause as atualizações e espere o próximo pacote cumulativo em vez de deixar o loop moendo. Morto o loop, o CBS.log volta às suas dezenas de megabytes e fica lá.
Ferramentas que anunciam "reduzir o CBS.log" tratam o recibo, não a compra. Apagar o log não muda nada sobre por que as atualizações falham; só elimina as provas. Renomeie só em casos extremos — um log de vários gigabytes num disco pequeno, já consertado o loop — e só então, com permissões de TrustedInstaller, sabendo que está apagando o diário.
Perguntas e respostas
Posso apagar o CBS.log?
O Windows continua funcionando — o arquivo se regenera —, mas você perde o registro de por que as atualizações falham, e para apagar precisa das permissões do TrustedInstaller de qualquer jeito. Conserte primeiro o loop de manutenção: o log fica pequeno sozinho.
Por que o CBS.log ocupa vários gigabytes?
Quase sempre porque uma atualização ou reparo falha e repete sem parar, e cada tentativa escreve milhares de linhas. DISM /RestoreHealth seguido de sfc /scannow geralmente corta o loop.
Veja exatamente o que está incluído antes de comprar.
O teste único de 30 minutos cobre os recursos básicos. Os recursos marcados PRO ficam bloqueados até a ativação de uma licença paga.
Continue lendo
Fale com a gente: [email protected]