As hinted, the Install Clean-up Tool is essentially MSIZAP with a GUI. It's best to use it by:
1. Use the Conrol Panel Add/Remove programs to unistall applications, then 2. Run the Installer Clean-Up tool, and select any apps you believe should have been removed. (Add/Remove sometimes leaves pieces behihd, depending on how well written the app was.) 3. Check your file system - some pieces get left behind in the .\Program Files directory. Do NOT use the clean-up tool first in order to uninstall apps! That will do a great job of making the Add/Remove control panel applet unusable for that app. Back to the original "problem"... It's best to not touch folders within the .\Windows directory to try to reclaim disk space. (There is probably a .\Windows\temp folder, but I've never seen much in those folders.) Use something like WinTree, WinDirStat, etc to locate big files or folders. Some browser caches can get to be pretty big. If a machine has multiple users, some of those profiles (some of which are local caches of a roaming user) can approach Gbs in size. I've seen machines with several crash dump files in the root directory. (Some crash dump files also end up in an administrators local settings profile instead of the rood.) -- richard Ben Scott <[email protected]> wrote on 09/28/2009 01:05:59 PM: > On Mon, Sep 28, 2009 at 12:32 PM, Joseph Heaton <[email protected]> wrote: > > The c:\windows\installer folder. On the system I'm looking at it > is a hidden system folder. Does anyone know the function of this > folder, and whether or not the contents can be cleared? > > That folder is part of the -- wait for it -- Windows Installer. > (Also called "Microsoft Installer" or MSI.) The folder gets used to > store a number of things, including database information about > installed packages, cached patches for (re)installation, program icons > (stored as .EXE files), temporary files during install, and other > mysterious stuff. It typically uses opaque IDs rather than > human-readable names. It's your classic Microsoft big-ball-of-mud. > > You don't want to go "pruning" in there without specific direction. > If you remove a file related to a currently-installed package, then > future attempts at upgrading, repairing, or removing that package may > fail. For example, patches are cached so they can be re-applied or > reversed during future operations, and database info tells MSI exactly > what to do during an uninstall. > > However, it is also quite possible for stale files to accumulate in > there. Unfortunately, since it's a rather opaque data store, it's > hard to know what's needed and what isn't. > > The MSIZAP utility has a command, G, to "remove orphaned cached > Windows Installer data files". Exactly how it determines what an > orphan is, I don't know, but it's supposedly safe as long as you don't > use the "!" modifier to force things. I don't know if it's > comprehensive -- I don't know if "MSIZAP G" will find all possible > stale/orphan files. I suspect not. > > The other options in MSIZAP generally remove information from the > MSI store without actually touching package files on your system. In > other words, indiscriminate use of MSIZAP will just remove the > *record* of an install, not the install itself. You have been warned. > > The MSIZAP tool comes with the "Windows Installer Cleanup Utility". > You can get it from MSKB 290301. > > -- Ben > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
