[SOLVED] Component-Based Servicing (cbs.log) causes all drive space to be consumed

Question

Because I've seen this question asked in many places and not answered, I thought I'd post my issue and resolution here.  I regard this as a Bug, but I'm not invested enough to deal with the support incident process.

I've had repeated instances where a Windows 7 x64 client runs out of hard drive space, and found that C:\Windows\TEMP is being consumed with hundreds of files with names following the pattern "cab_XXXX_X", generally 100 MB each, and these files are constantly generated until the system runs out of space.  Upon removing the files & rebooting, the files start being generated again.

I've found that this is caused by large Component-Based Servicing logs.  These are stored at C:\Windows\Logs\CBS.  The current log file is named "cbs.log".  When "cbs.log" reaches a certain size, a cleanup process renames the log to "CbsPersist_YYYYMMDDHHMMSS.log" and then attempts to compress it into a .cab file.

However, when the cbs.log reaches a size of 2 GB before that cleanup process compresses it, the file is to large to be handled by the makecab.exe utility.  The log file is renamed to CbsPersist_date_time.log, but when the makecab process attempts to compress it the process fails (but only after consuming some 100 MB under \Windows\Temp).  After this, the cleanup process runs repeatedly (approx every 20 minutes in my experience).  The process fails every time, and also consumes a new ~ 100 MB in \Windows\Temp before dying.  This is repeated until the system runs out of drive space.

This can be reproduced by trying to manually create the cab file -

 Directory of C:\CBS-BAK

08/26/2015  02:28 PM    <DIR>          .

08/26/2015  02:28 PM    <DIR>          ..

08/22/2015  09:12 PM     2,491,665,966 CbsPersist_20150823021618.log

C:\CBS-BAK>makecab CbsPersist_20150823021618.log

Cabinet Maker - Lossless Data Compression Tool

 86.19% - CbsPersist_20150823021618.log (1 of 1)

ERROR: (FCIAddFile)Data-size or file-count exceeded CAB format limits

C:\CBS-BAK>dir %TEMP%\cab*

 Volume in drive C is OSDisk

 Volume Serial Number is 44DE-0CDD

 Directory of C:\Users\USERNAME\AppData\Local\Temp

08/26/2015  02:31 PM       102,786,654 cab_4556_2

08/26/2015  02:28 PM                 0 cab_4556_3

08/26/2015  02:28 PM                 0 cab_4556_4

08/26/2015  02:28 PM                 0 cab_4556_5

08/26/2015  02:28 PM                 0 cab_4556_6

08/26/2015  02:28 PM        12,978,919 cab_5860_2

08/26/2015  02:27 PM                 0 cab_5860_3

08/26/2015  02:27 PM                 0 cab_5860_4

08/26/2015  02:27 PM                 0 cab_5860_5

08/26/2015  02:27 PM                 0 cab_5860_6

To resolve this -

Stop the Windows Modules Installer (TrustedInstaller) service

Delete or move the large Cbspersist_XX.log file out of \Windows\Logs\CBS.

Start the Windows Modules Installer (TrustedInstaller) service

Answer 1

Does it affect the NBC.log and ABC.log too?  I assume that TNT.log and FXX.log are unaffected since they are not regulated by the FCC.

Answer 2

I just looked at my C:\Windows\Logs\CBS folder and there are no compressed files in it whatsoever. I have a few persisted log files that 2+ and 3+ GB in size. So, it looks like Microsoft fixed the compression bug by turning off compression all together, is this an accurate assessment?

Answer 3

What OS are you running?  Does your \Windows\Temp folder contain the partial cab_XXXX_XX files that indicate the failing makecab process?

Answer 4

In trying to figure out why my Win7 install was suddenly going nuts on the disk, I traced a lot of activity to the CBS files.  Looking deeper, I noticed a few cab files for the older ones, with the first uncompressed log file being about 3 GB... presumably that's what's eating my disk activity. I'm going to either delete or split the files so they can be compressed correctly (there are a number of subsequent ones less than 2 GB) and see where that gets me.

Answer 5

Thanks a lot jwalker107.

I encounter this problem on several machines and your analysis, explanation and workaround answer perfectly to my needs.

Cheers,

Philippe