Qu'est-ce que CBS.log et pourquoi il gonfle jusqu'à plusieurs gigaoctets

Component-Based Servicing en un paragraphe

CBS signifie Component-Based Servicing : la machinerie derrière Windows Update, les fonctionnalités optionnelles et les réparations DISM. Elle prépare des composants depuis le magasin WinSxS, applique des paquets dans des transactions détenues par TrustedInstaller et annule tout si une étape échoue ; chacune de ces étapes s'écrit dans CBS.log, ligne par ligne, avec horodatage et codes d'erreur. Le Vérificateur des fichiers système écrit au même endroit — les lignes [SR] de sfc /scannow se pêchent avec findstr /c:"[SR]" quand on veut les détails. Une machine saine accumule des dizaines de mégaoctets de ce journal sur des mois ; il n'y a rien à nettoyer parce que rien ne va mal.

Le journal est donc un instrument de diagnostic, pas une ordure. Il existe précisément pour le jour où quelque chose casse : quand une mise à jour échoue à 87% ou qu'une installation refuse de se consolider, l'erreur réelle — pas le message générique de Paramètres — est notée ici.

Ce qui le fait gonfler jusqu'aux gigaoctets

La croissance à l'échelle du gigaoctet a une cause dominante : une boucle de tentatives. Une mise à jour échoue à la même étape, Windows programme une nouvelle tentative, elle échoue pareil, et chaque essai écrit des milliers de lignes. Les déclencheurs typiques sont un magasin de composants corrompu (la famille 0x80073712 et 0x800f081f), un paquet en attente qui ne se consolide jamais, ou des erreurs disque qui coupent la transaction de TrustedInstaller en plein milieu. Une machine coincée ainsi peut ajouter des centaines de Mo par jour — et alors le journal n'est plus le problème, c'est le compteur de symptômes.

Si votre CBS.log est énorme, résistez à l'envie de le supprimer et de passer à autre chose. Le fichier appartient à TrustedInstaller, une suppression simple rebondit de toute façon ; le renommer exige d'en prendre possession d'abord, et à ce moment-là vous aurez détruit l'unique enregistrement qui nomme le paquet fautif et son code d'erreur.

• CBS.log grossit de dizaines de Mo par jour ou plus
• la même KB échoue encore et encore dans l'historique
• TrustedInstaller consomme le CPU pendant des heures après chaque démarrage
• DISM /CheckHealth ou /ScanHealth signale une corruption du magasin
• des erreurs comme 0x80073712 ou 0x800f081f se répètent dans le journal
• la machine s'attarde suspicieusement sur « Installation des mises à jour »

Soigner la boucle, pas le fichier

La séquence qui fonctionne vraiment : DISM /Online /Cleanup-Image /RestoreHealth pour réparer le magasin de composants, puis sfc /scannow, puis redémarrage et nouvelle tentative de mise à jour — dans cet ordre, parce que DISM répare ce sur quoi SFC s'appuie. Vérifiez ensuite l'historique : si une KB précise échoue en boucle, mettez les mises à jour en pause et attendez le prochain paquet cumulatif au lieu de laisser la boucle broyer. La boucle morte, CBS.log retourne à ses dizaines de Mo et y reste.

Les nettoyeurs qui vantent la « réduction de CBS.log » soignent le reçu, pas l'achat. Supprimer le journal ne change rien à la raison pour laquelle les mises à jour échouent ; cela ne fait disparaître que les preuves. Renommez-le uniquement en cas extrême — un journal de plusieurs gigaoctets sur un petit disque, une fois la boucle réparée — et seulement alors, avec les droits TrustedInstaller, en sachant que vous effacez le journal de bord.

Questions et réponses

À lire ensuite