Two days ago one of my coworker called me, because he couldn’t start one of our proprietary applications. I got to him prepared to “reinstall” the program. I deleted the program folder and tried to paste working one from my backup and BAM!, no sufficient disk space box appeared. I thought “WTF?”.
I quickly returned to My Computer and noticed that there were 0 (sic!) bytes free on C drive. I knew that this would be a very interesting case to investigate, so I switched the laptop with spare one and took it to my office. 🙂
The first thing I did was to run TreeSize (you can find it in Tools) which gave me this nice overview of disk usage:
As you can see C:WindowsTemp takes up 173,7 GB of space! I decided to check that folder and saw this:
The folder was filled with hundreds of cab_ files!
From the dates I deducted that, on average, almost every hour 5 files were created. This was happening every working day, for the last nine months! No wonder they grew up so large.
I decided to check what what was creating them. I deleted all unused files from Temp (for nicer view 🙂 ) and set up Procmon with filter set to “Path begins with C:WindowsTempc”. All I had to do was to wait for my prey 🙂
Luckily I didn’t have to wait for long, as first files were created in 5 minutes.
I checked Procmon and got:
It turned out that a simple compressing program was causing all the trouble. But why was that?
You can see that in the “Command Line:” box we have a file supplied as a parameter to the program. So lets check it.
When I got to C:WindowsLogsCBS I stumped upon a CBS.log, a couple of CBSPersist_%date%.cab and some CBSPersist_%date%.txt. (Sorry for no screen shots but I forgot to make them, so you’ll have to believe me 🙂 ). All the .cab and .txt files looked like old logs, so why not all of them are .cabs? I checked the .txt with the earliest modification date and I got my answer… It was 5GB in size! So now let me give you a little background information about what is happening here.
How does makecab work?
Makecab creates a compressed cab archive from selected file. To do this it creates cab_%numbers% file in Temp folder (if you run it from normal account it uses user’s temp folder). After everything is completed all the files are deleted. And why it didn’t happen here? Because the txt file it tried to compress was too big for it to handle:
Here you have shown what happened when I tried to manually compress the txt file. The program exited before deleting the temporary files.
But why it grew up so large? To find the cause, let’s check what program started makecab in the first place.
To do this we will use Parent PID from makecab’s procmon event properties, and Task Manager with shown PID column:
Now we have the bad guy! But what are his motives?
By using Procmon, Procexp and some google-fu I learned that TrustedInstaller is used by Windows Update to perform updates, which explains periodicity of file creation. When WU check for updates, TrustedInstaller writes a lot of information in CBS.log file. TI is also responsible for starting the process of compressing the log when it grows too large (50-500MB). It does it by renaming the original log to CBSPersist_%currentdate%.txt (below you have the renaming process captured in Procmon), and then calling makecab program with proper parameters.
By looking at the modification dates on .txt files I noticed that the problematic file must have grown that large in only 4 days (last .cab had modification date set to 10.10.14r and .txt had 14.10.14r.). Why TrustedInstaller didn’t prevent it? Well, the only reasonable explanation for me is that WU wasn’t checking for updates during that time so there was no log size control.
And here things got interesting… When WU won’t check for updates? Only when there are ones waiting for restart, to install themselves! Sadly System Log was set to overwrite old log entries rather than archive, so I don’t have any proof of my diagnose, but I think that after installing updates no one restarted the laptop for 4 days. It was the first week we had this laptop in our production environment, so surely he had a lot of information to write there. One thing that supports it is that on my home system I saw a 0.5GB CBS.log file and it was only one day old 🙂
I think that this fully solves the problem and explains everything in detail 🙂
Thanks for reading, and remember to restart your computer once in a while 🙂 To the next time!
