Can you safely delete files in the %windir%\Installer directory?

Can you safely delete files in the %windir%\Installer directory?

  • Comments 87
  • Likes

Along the same lines as removing items from the Windows component store to save space, we have recently seen a couple of questions come in about the Windows\Installer directory. This is a hidden system directory; it is used by the Windows Installer service to cache installer data files for various applications. Over time, this directory will grow and can eventually take up an amount of space that might cause pressure on thinly provisioned storage, such as virtual hard disks.

So, the question usually asked is: Can I safely remove the files in this directory? The answer is flatly: No. So let's talk about why this is a bad idea.

First, it is not supported. If you remove files from this directory and have issues, you may need to reinstall the application to get back to a good state. Therefore, that would suck for both you and the engineer that needs to deliver that message.

Second is the overall idea that you really should not remove items in the Windows directory. We build and test our software based on the existence of specific files and directories. When those files and directories dont exist, bad things can and will happen. However, that is a generalization that usually upsets many people so let's be more specific. This particular directories job is to act as a cache location for Windows installer based applications. It holds stripped down versions of the Windows installer data files. During application install, update of the application or application removal, this directory is used by the application to confirm the existence of previously installed items to determine the next steps the installer needs to take. The files are different from machine to machine, so if you expect to delete the files in the directory and then copy them over from another machine, that would be incorrect. Removing items from here could cause you to have application crashes, or worse, require the reinstallation and patching of the application.

The proper way to alleviate space pressure in this directory is to uninstall any unneeded applications.

I hope that this makes sense and you can see why removing files from this directory can cause you unneeded pain. Overall, this is similar to the advice I have given in the past when it comes to removing items from the component store...just don't do it. Plan your future space requirements based on your operating system and application needs and you can alleviate many of these types of issues before they occur.




  • Just to add, the proper way to reduce the space consumed by this directory is obviously to remove unnecessary applications.

  • Good call Pronichkin, I've added that to the blog.


  • and removing older updates! But it still happens that files are left after removing software.

    Why can't you provide a simple software which checks if the MSP/MSI is still referenced or not? This software: only works for 32Bit Windows, the results are wrong for 64Bit Windows.

    I hate this folder, it is 14GB on my system :( WinSxS is only the half (7GB).

    Microsoft Installer is one of the worst things ever made. Slow, uses too much space in this folder and often causes failures.

  • Tell me how you really feel Andre :)

  • I simply hate the Windows installer. Installing Sp1 for VS2010 takes so much time. its time for a new format which also supports offline servicing like MSU updates. Installer is from Office 97 time frame.

  • For the record, I have seen situations where the Installer directory contains multiple (identical) copies of very large files; if I remember correctly, each time a particular installation failed it left behind an additional copy.  So there may be situations where the administrator has to delete files manually.

  • If only Microsoft re-engineered the servicing once again in Windows 8, users wouldn't constantly ask MS how to keep the disk eating OSes (Vista, 7) from eating away their HDDs and clean other system folders. Just bring back a servicing mechanism with a ****simpler design*** that:

    1.   Installs updates as fast as XP and doesn't thrash the disk during installation and logoff/logon.

    2.   Doesn't eat disk space over time and actively deletes older superseded components

    3.   Doesn't require slowing logoff and logon at all for "configuring updates".

    4.   Allows slipstreaming service packs

    5.   Doesn't create a super-complex directory structure with very long unique filenames under WinSxS and hard links all over the place. ReFS doesn't support hard links remember.

    These should be Microsoft's design goals for the next servicing experience. Meanwhile, good luck and bless those poor Windows 8 souls taking hours on their tablet.

  • @xpclient;

    At some point you're going to have to let WinXP die <G>.

    I understand your points above though and I will speak to the changes in Windows 8 servicing when the time comes.


  • "This particular directories job is to act as a cache location for Windows installer based applications. It holds stripped down versions of the Windows installer data files."

    What is the nature of these stripped down data files? What is removed? What does the removing?

    "During application install, update of the application or application removal, this directory is used by the application to confirm the existence of previously installed items to determine the next steps the installer needs to take."

    How does an application know what data files to reference in the Installer directory?

    Btw, is this really you?

  • @Drew;

    Windows Installer service takes care of the creation and maintenance of the folder, the cached files are stripped down stubs of information the installer (and developer of the application) have determined are needed in the even of a change.  The applications developer knows what they wish to leave cached and coorespondingly call into the cache when they need to make changes to the application.

    And yes, sadly thats me barely beating a dog in a marathon.  I assume you got that from Ned's blog :)


  • Thanks Joseph.

    Yeh, i did get the photo from Ned's blog. Don't be so modest, you ran a marathon! Can you tell us what your time was?

    Changing topic. Here is the link to the latest DirectX End-User Runtimes (June 2010) Two problems:

    1. Date Published is in locale specific format. Let me tell you how i really feel <G> about locale specific date formatting; it sucks! Please, can this field be changed to the ISO *international* date format: YYYY-MM-DD?

    2. As an example, is this update included in the latest service pack (obviously SP1 in this case)? Date Published indicates yes (4/18/2011 vs. 3/15/2011). Name (June 2010) indicates no. The Quick Details section is missing an obvious piece of info; 'Superseeded by: <Hotfix | Update | SvcPack>'. The first thing i'm interested in knowing about an update is; Is this in the latest SvcPack - yes or no? and/or Has this update been superseeded by another update, and if yes, what is it? Maybe i'm going about it in the wrong way?

  • @Drew;

    Thanks.  I finished in 4:13 or something like that, it was my first marathon and I definitely hit the proverbial wall.  I really didnt want to lose to that dog at the end <G>

    As for the other two items, I'm glad you brought this up because honestly, I've never even thought about the date as it is now.  I guess because it works for me, its never been a problem but that is short sighted.  So, I'll bring this up.

    As for the second point, I'll have to see what work would go into getting KBs published with more information but we typically do have something in updates that will say, "this fix is included in service pack XX".  So, I'll have to do some more thinking here and see what would make the most sense in regards to getting the information you need in a consumable fashion.

    But to clarify something else, never use dates to determine applicability.  Use file versions. Dates have been used incorrectly in servicing for years (since NT) and its always been a pet peeve of mine.  So when you're trying to determine if something applies to something else, look at the versions of the files you have vs. the files you want to apply.  If the file to be applied is greater, thats all that matters.  You can use Service Pack version numbers to help with this kind of stuff to an extent.

    For service packs specifically, its best to just check the files included in the service pack articles.  For Windows 7 SP1 that information is located here:


  • "So, I'll bring this up."

    Thanks. The problem with using the m/d/y format is the ambiguity of it, not so much the mental translation into the big-endian-like ISO format. Users with non-m/d/y locales must be constantly seeing dates in various contexts and having to ask themselves if the date is being formatted to their locale, or not. Then there are the inconsistencies found within Windows. Ex: Xcopy /D:m-d-y and Robocopy /min|maxlad:YYYY-MM-DD. I vaguely recall that version numbers were added to the DriverVer key in inf files because of mistakes using the m/d/y date format by non-US programmers. Easy to criticize but what seems a bit odd is why a software company would not *prefer* an easily sortable format like y-m-d.

    As for presentation, i'd be happy just to see YYYY-MM-DD printed in grey, directly below the publishing date, and, just beneath 'KB Articles:'; Superseeded by: <KB####### (<Update Name>) | Nothing>

    "So when you're trying to determine if something applies to something else, look at the versions of the files you have vs. the files you want to apply.  If the file to be applied is greater, thats all that matters."

    Ok, but that will require a little more investigation than just referring to the date, but point taken. I guess a point to note is that an update released just prior to a service pack might not be included in the SP yet have an earlier date than the SP published date. Perhaps instead of or in addition to the published date, the date of most-recent-update-included should be printed on the download page? But that is probably to ignore what you said about ignoring dates and only going on version numbers. Regardless, if version numbers are what should be referred to in determining update applicability, that might be making the case for including something like the filever command, inbox.

    One more bit of info that might be good to include in KB Support and download pages are references to hotfixes and updates to the update in question. Two good examples:

    1. Windows Installer 4.5 Hotfix KB958655 Referred to on the Visual Studio Administrator Guide page @ but not referred to on either the KB article or download page for WI 4.5.

    2. Platform Update Supplement for Windows Vista and for Windows Server 2008 Not mentioned on the 'Description of the Windows Graphics, Imaging, and XPS Library' KB page, equivalent download page, or in the 'Description of the Platform Update for Windows Server 2008 and the Platform Update for Windows Vista' page @

    Any sort of non-replacing update to an update/hotfix should be referenced in a revision to the 'parent' update page.

  • All good feedback Drew, thanks!

  • Thanks Joseph.

    The following fields line up neatly with mono-spaced font <G>.

    Published date: <Long format date>

    Timestamp date: YYYY-MM-DD

    Invalidated by: Service Pack # | Cumulative Security Update for IE ...

    Superseeded by: KB#######, KB_later_

    In the Win7 SP1 documentation page you gave the link to, there is a document download called 'Notable Changes in Windows 7 and Windows Server 2008 R2 Service Pack 1.doc'. What do you think of the idea of having a web page for each major OS release (7_x86, 7_x64, WS08R2 etc), called something like 'Notable Updates to Windows <OSIdentifier>'? Aimed primarily at image builders and admins, it would list all the 'milestone' updates for each release, post-RTM. Obvious stuff like service packs, IE updates, update rollups, platform updates, but also updates you would want installed before installing any apps, or using outside of a high-security environment. Things like the latest timezone update, appcompat update, and highly desirable security updates, such as the latest ActiveX killbits, or the .lnk exploit mentioned in the 2nd paragraph @ Also included would be hardware related updates like that for Advanced Format Disks (4KB sectors), or CPU related updates that affect performance. So the general idea is to advise on what the minimum set of recommended updates are to have installed before making a master image, or installing any apps, or connecting to Windows Update for the first time, or adding to a production environment. Any merit?