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

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

* Please try a lower page number.

* Please enter only numbers.

* Please try a lower page number.

* Please enter only numbers.

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.
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?

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

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.

Thanks a lot jwalker107.

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



OH MY GOD this is what's been going on.

The thing that gets me is that Windows hides the contents of c:\windows\temp\ by default. I could see the hard drive was full, but selecting all the folders in c:\ and checking the properties screen claimed the entire contents of the drive was nowhere near enough to fill it.

I finally installed a third party disk analyzer which revealed how massive c:\windows\temp\ had gotten, and reading articles about deleting things from there pointed me to here.

Upon trying to enter c:\windows\temp\ in order to remove all those cab_XXXX_X files, it made me grant myself permission to do so, and only THEN did the folder properties screen show that c:\windows\ was taking up most of the drive.

So now I've deleted the offending CbsPersist_YYYYMMDDHHMMSS.log file and all those cab_XXXX_X files and I have my hard drive back.

Microsoft really needs to fix this bug with a patch that will make the system delete those cab_XXXX_X files if they are more than a month old.

I had a 212gb cbs.log file filling my up C:\ drive today. Thanks to the fix here, it's now been blasted, but... WTF?
I've been having this issue on my new Windows 10 system updated to the latest release/patch level. I am able to stop the Windows Modules Installer service, but I cannot rem or ren the cbs.log from an elevated prompt window. It says "The process  cannot access the file because it is being used by another process". Any other ideas? I have over a 100GB cbs.log file!

Okay, finally got it. I also had to stop the Windows Modules Installer process from the Processes tab.

Glad you were able to work it out.  Otherwise I would have suggested downloading the Sysinternals suite from https://www.micrososft.com/sysinternals and using the "handle" tool to determine which process had the cbs.log file locked.

* Please try a lower page number.

* Please enter only numbers.

* Please try a lower page number.

* Please enter only numbers.


Discussion Info

Last updated August 4, 2020 Views 206,627 Applies to: