The Patch Cache and Freeing Space

The Patch Cache and Freeing Space

Rate This
  • Comments 16

When you install a patch using Windows Installer, the .msp file is cached in the %WINDIR%\Installer directory. This accounts for some of the space required by Visual Studio 2005 Service Pack 1. A single patch is cached only once regardless to how many products the patch applies.

Starting with Windows Installer 3.0, any patches that contain the MsiPatchSequence table cause the Windows Installer service to cache any of the original files being replaced into the baseline cache. Any files being replaced in the latest minor upgrade by small update patches with this table are also cached. It is this baseline cache that consumes a lot of drive space on the system drive after installing VS 2005 SP1. The baseline cache facilitates patch uninstall by storing the original files so that they can be copied back to the target locations. Files in existing patches do not need to be cached because they are contained within the cached .msp files. For this reason and because Windows Installer will require these patches during repair and future patch scenarios, the .msp files should not be deleted except by uninstalling the patch from each product to which it's applied. The baseline cache also improves performance when using binary deltas.

Baseline caches are created separately for per-user unmanaged installations, and for both per-user managed and per-machine installations. If you enable Windows Explorer to display system files or type dir /a:s under %WINDIR%\Installer you'll find a directory structure like the following:

  • %WINDIR%\Installer
    • $PatchCache$
      • UnManaged
        • {UserSID}
          • {Squished ProductCode}
            • {ProductVersion}
      • Managed
        • {Squished ProductCode}
          • {ProductVersion}

Be careful doing any modifications under %WINDIR%\Installer. Like registry changes, making mistakes here could cause problems that may require the difficult task of rebuilding the Windows Installer cache or even reinstalling Windows.

To free up space, you can remove the baseline cache for Visual Studio 2005 under %WINDIR%\Installer\$PatchCache$\Managed by deleting the directory with the squished GUID representing the ProductCode for whichever Visual Studio 2005 products you have installed. The squished GUID is a transformed ProductCode. Attached you'll find a list of product names, product codes, product languages, product editions, and squished GUIDs for Visual Studio 2005 and the .NET Framework 2.0.

Again, be aware that by removing the baseline cache for a product, future repair, patch install, and patch uninstall scenarios may require your original installation media. If you have the drive space it is recommended that you keep the baseline caches available.

Attachment: Squished Product Codes.csv
Leave a Comment
  • Please add 6 and 1 and type the answer here:
  • Post
  • I thought I'd toss out a well-known but often overlooked house cleaning tip.  MsiZap G! is helpful for clearing out Windows Installer resources that are no longer being referenced.  For whatever reason, Windows Installer doesn't have the best garbage collection after an uninstall or rollback.

  • Take care when using msizap, though. "G!" is safe, but exploring other switches without understanding their ramifications could mean you cannot patch products anymore because product registration is missing (essentially making it appear to Windows Installer that your product is not there). Treat this like editing the registry.

  • If Visual Studio 2005 Service Pack 1 fails to install, you might find additional .msp files under %WINDIR%\Installer

  • Thanks for the information -  I just ran MsiZap G! and cleaned up 14 gigs of space from my C drive!

    There were a lot of files in my C:\windows\installer folder - the end result of installing 100's of programs over the last two and a half years.  Nice to know I can safely clean the installer folder since it was so large in size and because it's only going to keep growing in size as I'm continually installing and unistalling software and I am never ever going to do a clean reinstall of windows.

  • Microsoft Visual Studio 2008 , now available for MSDN subscribers and Express editions freely available

  • Windows Installer is an engine for performing transactional installations. When installing a product

  • I know this is an old blog, but I thought I would ask.  

    Can you use mklink on Win7 to move either the $PatchCache$ directory or the SoftwareDistribution\Download directory to another drive.  I have Win7 x64 on a SSD (64 GB and it is full enough that I can't install OS patches anymore).  I have trimmed it down as much as I can.  I have VS2k8 and VS2k10 installed.  I noticed that the $PatchCache$ has 3.8 GB directory called Managed.  Is any of this safe to delete, I kind of see mixed responses on the different blogs.

  • @Brian, there's more to it than that. You're on the right track though, but it's not supported. You can delete anything under $PatchCache$ but understand that uninstalling patches will prompt for source, and binary delta patches won't install without prompting for source. Just never delete anything in the parent directory: %WINDIR%\Installer. I have some other blog entries about what happens when you do (i.e., not good: usually means having to rebuild your machine).

  • So I can safely wipe %windir%\installer\$PatchCache$ clean? It would be the same thing as having used MaxPatchCacheSize 0 all the time?

    What about the .msi and .msp files in the root of %windir%\installer? Can I safely delete them? Are they referenced in the registry? What's the difference between the files in the root of %windir%\installer and the files in the %windir%\installer\{guid} dirs? Can you provide a batch script to clean all of %windir%\installer? Would that mean I couldn't uninstall programs?

  • @John, you can delete %windir%\installer\$patchcache$. This may cause you to get source prompts for binary delta patches as well as during patch uninstall, but is otherwise okay. You must not delete any files directly under %windir%\installer, though. This will prevent you from repairing, patching, or even uninstalling products that use those files no matter what the type.

  • Can I compress the Installer folder?

  • @Jeff Sanders, the word from the Windows Installer team is: no, you cannot compress it. This is not supported. Besides, if you've already deleted the $PatchCache$ subdirectory, you'll get little more compress from the Installer directory since files in cabinets are already compressed (maybe not the best compression possible depending on the product/patch authoring, but there'd likely be little entropy to make futher compression worth it).

  • @Jeff Sanders, new SSD drivers revitalizes old compression discussions.

    In my opinion, there is no issues in using NTFS compression a current Windows installation disk and all it's folders in it. In my case, using NTFS compression on C:\Windows\Installer\$PatchCache$, reduced the disk space from 4.31 GB to 2.62, allowing me to use more efficiently 1,69 Gbyte.

    Take present that that directory generally will be used rarely, so the overhead is minimum.

  • C:\Windows and C:\Windows\Insaller folders are full of useless information how to rollback KB fixes. No one bother to roll back patches successfully applied a year before and didn't led to any troubles. But on my machine all this useless msi's and folders occupy 8GB of space. Is it normal? No really say your opinion about this massive space hog. I am curious what you are thinking about preserving the roll back info for the Microsoft Office patch installed through Windows Update in 2010, should it occupy 350MB?

  • Unfortunately, the way that Windows Installer is designed pulls in the MSI and all applied patches (even if not currently applicable) into view when even repairing the product (which includes installing future patches), so anything in the Installer cache given the current design is not useless.

Page 1 of 2 (16 items) 12