Auto generated cab files fill system disk after patch

Hi

After patching multiple environments that belong to our customers we have have experienced some problems with the CAB file logs in C:\windows\logs\CBS increases in size to about 2-3 GB. This causes cabxxxxxx files to be auto generated in C.\windows\temp. This keeps on going until the disk goes full. This happens only on 2008 R2 servers.

I have a workaround that fixes this, but i want to find a fix that stops this completely. Has anyone experienced this or have any tips?

Edit:

Thanks all. Tho we dont know the root problem yet i have created a analysis that should root out the problem. I am also thinking og creating a task policy which will automatically fix it.

I am running this relevance code. If someone has some tips on making it better i would be happy to get them.

(sum of sizes of files of folder “c:\windows\logs\cbs” > 15000000000 or free space of drive “C:” < 5000000000 and exists file whose (name of it contains “cab”) of folder “C:\windows\temp”)

The cab files are created to archive log files in C:\windows\logs\CBS folder. There is usually a .log file in the same folder, you may want to open it up and see what logs are filling it up.

2 Likes

Ours is doing the same thing. Something that came out around the end of December to the first week of January seems to be filling these up.

Once the \windows\logs\cbs\cbs.log reaches 2 GB or so, the makecab command that Microsoft uses to periodically archive the file fails. Repeatedly. And every time it fails, it adds its incomplete archive to \windows\temp.

Only resolution I’ve seen is to delete the cbs.log.

I don’t know whether the cause is a particular patch, or whether it’s an accumulation of running many in quick succession that increases the cbs.log size beyond the threshold that makecab can handle, but I’ve been able to reproduce the makecab failure on arbitrary files of sufficient size.

…and I’ve seen this on Windows 7 Enterprise x64 as well as 2008 R2.

See this post: Delete files automatically - CAB files and CBS log issues

This is really a Microsoft issue, and less so a BigFix issue, though BigFix can be used to help solve the problem.

As far as I know @JasonWalker has the root cause, but you can research this issue online generally on Microsoft forums and related sites.

You could probably take the current CBS.log file, use 7zip to compress / archive it, then delete it so it can start fresh.

Then delete the cluttering files that are eating up space.

Our problem started at the exact same time!

I will probably and eventually be posting a full TechNote on this Microsoft Issue. Would be nice to have a fixlet to detect on and remediate condition.

2 Likes

an analysis as well. I always start with an analysis and go from there.

Slightly related: https://bigfix.me/analysis/details/2994541

Once I figure out what the source of the problem is.

@BigFixNinja Did you get anywhere with the source of this issue?

Yes , this is confirmed to be a Microsoft problem outside of BigFix. The only thing one can do is to detect and remediate against it. I am working on a TechNote for it.

I created this analysis to see what was going on in my environment. Put it together fairly quick, but should at least show what you need to see.

Check CBS.LOG File Size.bes (1.6 KB)

1 Like

On my systems, it is often not the CBS.LOG itself, but one of the CbsPersist_[date/timestamp].log files that grows too large.

1 Like

Sorry for the delay, here is the TechNote:

http://www-01.ibm.com/support/docview.wss?uid=swg21979836

I can build out the TechNote further with addition information and .bes scripts as I glean them from the community here:

Thanks for the update. I have a task to clean this up that I’ll try to post later in the week.

I would note though, that I’ve seen this on systems that are airgapped and have no access to Windows Update, so I’m pretty sure that the causes are not limited to “two patches running at the same time”.

1 Like

I finally got around to uploading this to bigfix.me

https://www.bigfix.me/fixlet/details/11930

3 Likes