What is blobs.bin and why does it grow?

Recently I have been asked a couple of questions about the \Windows\winsxs\ManifestCache\blobs.bin file and what it does. Specifically, the question I have been asked it why the file takes up the amount of space that it does, or in some cases, grows out of control.  In looking around on the web, I've seen various explanations for the file and some of the things that you can do to it when you get into this state.  I figured I would go over the options you have if you're running Windows 2008 and you have a blobs.bin file thats growing out of control.

First, let's define what "out of control" really means.  If you have a blobs.bin file that is taking up a few hundred MBs of space, you're not out of control.  If you've got a file thats several gigabytes in size you "may" be out of control depending on the circumstance.  If you're in the group that has one that is over 10GB, you're in the out of control group I am focused on speaking to.  So, what are your options when you hit this state and what does that file actually do.

The blobs.bin file is used as a caching mechanism for servicing operations that are set to happen against the system.  The file will naturally grow and shrink in size as various servicing actions take place against the machine and are satisfied.  Typically, if you reboot your system on a machine with a large file, you'll notice that update(s) may have been pended and rebooting satisfies the finalization of the operation and reduces the size of the file.  But, all in all, the file is there for caching. 

So, what causes the file to grow as large as it does?  Well, several things can do this.  Anything that is regularly querying the stack will cause the file to grow in size, things like WSUS, SCCM, Windows Update, Server Manager and some WMI calls can cause the file to recursively grow in size.  Tracking these things down can be fairly difficult but usually isolating a machine that is experiencing the problem can be a good start to figuring out whats happening and narrow down the potential offenders.

 Lastly, what can you do if you're in this situation?  You have several options:

1.  Upgrade to Windows 2008 R2.  I know that sounds like a sales pitch, but its not.  This particular issue doesnt happen in R2.

2.  Delete the file and reboot the system.  Yes, you can safely delete this file without any fear of it damaging anything on the server.  I've seen sites that said this file cant be deleted, they are wrong.  We'll recreate the file on boot.

3.  If deleting the file didnt resolve the growth issue, ACL the file to deny everyone from writing to it.  The stack will see a failure to write to this as a signal that it doesnt need caching and it will move on servicing files.

 Hope that helps...

 --Joseph

Comments

• Anonymous
  January 01, 2003
  You can use the takeown utility at a command prompt to delete the file if you need to.  Honestly though, those files are within the normal ranges so unless you're strapped for space, you can leave them alone.  One thing you might want to do is check to see if you have a lot of updates that were recently installed or are pending an install, then reboot the machine to see if anything in the blobs.bin just needs to be flushed out of the system.

• Anonymous
  January 01, 2003
  Nigel; Thanks for the comment.  I do think your comment about backup is valid to an extent, I'll figure out how that would play out in the future and see if there is something we can do to potentially stop a backup of the file in instances where the file is above a certain size.   Not sure what you mean by poor VSS service in Windows, but I think thats another issue altogether <G>.   While the file isnt crucial to the systems overall performance, I also dont want people to think that its something you should just delete for the fun of it.  If you had to reclaim space because this had grown out of control, then sure, delete it.  However, if you dont need to delete it, it should be left alone. --Joseph

• Anonymous
  January 01, 2003
  Maria; You can use the takeown utility to grant yourself access and properly remove the file. Command syntax is located here: technet.microsoft.com/.../cc753024(WS.10).aspx --Joseph

• Anonymous
  April 19, 2010
  Well this is one of those scenarios where ideally MS should be putting out a hotfix for Vista/Server 2008 to fix this issue like 7/R2 howsoever large an archtectural change this might be. Then again, 7/R2 itself are point releases which left Vista/2008 customers in the lurch. The whole servicing mechanism of Windows should again be redone in Windows 8 to eliminate the disk space and performance (heavy I/O and slow logon/logoff) issues.

• Anonymous
  August 08, 2010
  I have tried to delete this file (I have 2, one is 400Mb and the other is 3.4 Gb) on my notebook running Vista, I have even tried using the DOS window to delete it with an rm command, all to no avail, it seems I do not have the rights to delete it.  Anyone have any suggestions? - Thanks

• Anonymous
  August 12, 2010
  It would be useful if this file was excluded from the volume shadow control (including backup and restore) because if you say its benign and can be safely deleted - why is it backed up? Is this another case of Microsoft teams working in isolation and not providing a system but instead a group of programs?  This is just another example of the poor VSS Service that exists in Vista, Windows 7 and Windows 2008! However the article is a good explanation

• Anonymous
  January 27, 2011
  my file is 26.6 GB! but it won't let me delete it, as it says i don't have permission, can you help me with this? Thanks

• Anonymous
  April 19, 2011
  The .bin file on this machine is 34gb. The user is listed as the machine administrator but command prompt says that the user does not have access to both "net stop trusted installer" or the "takeown" function. The user is completely oblivious as to whether or not there is a full admin account or what its password is. Please help!

• Anonymous
  April 19, 2011
  Nevermind, just had to elevate cmd, thanks!