Why does MSI require the original .msi file to proceed with an uninstall?

Question

As most of you probably noticed, when uninstalling an MSI package Windows will ask for the original .msi file. Why is that?

I can only see disadvantages to that:

• not resilient to network changes.
• not resilient to local disk changes.
• unexpected by users.
• typically requires users to leave their desk and start a crusade to get the correct CD.
• kind of proves installations are not self-contained.
• promotes the use of unsafe tools such as msizap.
• which in turn promotes the "next time I'll just use a zip file" mentality.

Could someone shed some light on this?

Linnette

Answer 1

Fix Broken Uninstall: You can try the newest FixIt Uninstall tool from Microsoft if you have problems uninstalling an MSI. And one more link: Uninstalling an MSI file from the command line without using msiexec (a plethora of different ways to uninstall an MSI).

---

UPDATE:

This new support tool (this tool is now also deprecated) can be tried on recent Windows versions if you have defunct MSI packages needing uninstall (rather than the outdated, deprecated, unsupported msizap.exe).

Some have suggested to use the tool linked to here by saschabeaumont: Uninstall without an MSI file. If you try it and it works, please be sure to let us know. Feedback in that answer indicates that it works (I don't have any stuck setups to test with as of now).

---

Why are you asked for the original installation media?:

• The original MSI is not needed for uninstall unless the MSI itself is badly designed - or the cached MSI is missing (see details below).
• All installed MSI files are cached in %SystemRoot%\Installer\*.* using a random hex name.
• The cached MSI file is used for any maintenance, repair and uninstall operations - and it is sufficient for uninstall in the vast majority of cases.
• In some cases this cached file can be missing, and then uninstall is not possible at all in some cases (some theories as to why this can happen - MSI design errors, anti-virus quarantining, system restore, tinkering, developer system in erroneous state from development work, etc...). See more info below - and links to force uninstall or unregistration of the product.
• The original source is only needed if files need to be copied to disk (for a maintenance install), or the MSI does an explicit request to resolve the original source via the standard action ResolveSource or via a custom action (which shouldn't be done in a properly authored package - I think the MS Office package contained this ResolveSource error back in the day, causing everyone to go looking for their installation CDs/DVDs).
• In previous editions of Windows this cached MSI was stripped of all cabs, and hence contained the installer structure only, and no files.
• Starting with Windows 7 (MSI version 5) the MSI files are now cached full size to avoid breaking the file signature which affects the UAC prompt on setup launch (a known Vista problem). This may cause a tremendous increase in disk space consumption (several gigabytes for some systems). Check this article and especially the discussion at the bottom for more intel.
• To prevent caching a huge MSI file, you can run an admin-install of the package before installing. This is how a company with proper deployment in a managed network would do things, and it will strip out the cab files and make a network install point with a small MSI file and files besides it. Note that this may yield a UAC prompt is some cases since the extracted MSI file is no longer signed - this must be tested with your SOE / desktop configuration.
• Read my answer in this thread for the full description of admin installs: What is the purpose of administrative installation initiated using msiexec /a? or this similar but perhaps more accessible answer: admin install and its uses
• In some rare cases the cached MSI (with the random name) can be erroneously missing, and uninstall will then ask for the original MSI in order to complete the uninstall. This does not happen often. It used to be the case that one could use MsiZap.exe to clean out such an install, but this tool is outdated, deprecated and unsupported. Don't use it - there are too many incompatibilities with newer Windows versions and you create new problems. Perhaps try this support tool instead (also deprecated). The only option I can suggest now is this answer from saschabeaumont. If you try this tool, please let us know if it works for you. If you want to figure out what could have caused the cached MSI to be missing, try to read section 12 here: Uninstalling an MSI file from the command line without using msiexec (in short potential causes range from interference with system restore, anti virus and cleanup scripts, to erronous manual tweaking, low disk space, power outages, developer box debugging errors, badly designed MSI files with duplicate package codes, failed patches, etc... Many theories, few certainties I am afraid).
• As a last resort you can try system restore (unless it has been disabled entirely or partly) to go back to a previous installation state and see if this solves your uninstall problem (you can find video demos of this on youtube or a similar site).
• Be aware that system restore might affect Windows Update that must then be re-applied - as well as many other system settings. I have seen new, unsolvable installation problems resulting from a system restore, but normally it works OK. Obviously don't use the feature for fun, it's a last resort and is best used for rollback of new drivers or setups that have just been installed and are found to cause immediate problems and such issues. The longer you go back the more rework you will create for yourself. A lot of self-evident stuff, but I guess it needs to be mentioned.
• Since I mentioned system restore I suppose I should mention the Last Known Good Configuration feature. This feature has nothing to do with uninstall or system restore, but is the last boot configuration that worked or resulted in a running system. It can be used to get your system running again if it bluescreens or halts during booting. This often happens after driver installs. This will do nothing to fix your failing uninstall though (or I would be very surprised).

Related answer:

• Uninstall without an MSI file

---

In addition to this answer, perhaps this article on various ways of uninstalling MSI packages is of interest. It is a rather popular article with a high number of views:

• Uninstalling an MSI file from the command line without using msiexec.

Magnesite

This is actually a much better answer than the accepted answer. The accepted answer from Oct 16 is filled with inaccurrancies. – Ng

One important point is not accurate: Not "newer versions" (Win7 released in 22th Oct 2009): Beginning with MSI 5.0 (>= Windows 7) the MSI is NOT stripped of cabs and entirely cached. The reason is told: because of signed MSI files (I don't agree, this is a good decision though.) This results in high and unnecessary disk space for all MSIs conatining the .cab files. So good practice is now and for the future to never design MSI files containing cabs, but putting the .cab file(s) outside. Especially with InstallShield this is quite weird, because they allow that only per-feature. – Hensel

For those needing a one-file setup the way to go is a selfextracting setup.exe bootstrapper (if not already using a full multiple-msi-capable bootstrapper like Burn, Setup factory or InstallShield/Suite type. – Hensel

Here is another discussion on this topic: csi-windows.com/toolkit/csicachedpackageassource – Snatch

The sentence "one .. point is not accurate" in my comment above is now outdated, because incorporated in the already very good answer. Thanks. – Hensel

Concerning the recommendation of admin installs I think it depends on personal flavors.. I see the mentioned points, but it is not my way except for inspecting a msi as said. I tend to send as few files over the network as possible for safety, speed and server/net loads. Fetching few fat .cab files over the net is way better than thousands of small single files. With a simple network link containing the original MSIs, you get at least the same advantages for caching purposes without the mentioned drawbacks- IMHO. Concerning the space issue I agree with the advantages. – Hensel

Philm: yes, good point, but it all depends like you say: high latency networks (wireless) should not download many small files. However, large cab files sometimes don't play well with anti virus software in my experience. For patching it is also better to be able to copy a couple of small files from the network image, than to have to download the whole cab. – Snatch

unless the MSI itself is badly designed which one may perceive as quite common. can it be that msi system is an error-prone design (for .msi creators)? – Saleswoman

Yes, many MSI files are poorly designed, but things are improving with the advent of Wix. You can find a work in progress describing common MSI design problems on serverfault.com. The same "thread" contains a description of corporate benefits of MSI. – Snatch

There is yet another support tool from MS, which is not deprecated: support.microsoft.com/en-us/help/17588/… I have successfully used it on a few occasions. – Semiliquid

Oh yes, thanks. I have it in my other answer here, but I forgot to add a direct link here (the link I have above indirectly links to it). Will add direct link. Thanks again. – Snatch

Answer 2

There are a few reasons for keeping the original msi:

• The uninstaller uses it to know what files and registry keys were installed and make sure they are all cleaned up.
• The msi may contain special uninstall actions that need to be performed.
• It allows you do to a 'repair' operation from the Add/Remove Programs menu, regardless of whether or not you saved the install file yourself.

The normal way of things is for Windows to keep the file cached for you, so you don't have to think about it. See your %WINDIR%\Installer\ folder. The only reason it would ask your for the original msi is if something is wrong with the saved file. This addresses most of your concerns, though it does raise a new one (disk-space).

Kanya

and what about using the registry itself to store the actions and keys added to enable uninstalls? That'd make more sense than storing the whole file. Repair dying when there's no msi is totally expected, but no uninstall is a no-no in my books. – Screwball

I don't work for MS: take it up with them ;) But storing that much info in the registry probably isn't a good idea, either. It's bloated enough as it is. – Kanya

Oh: but I agree that the system should be smart enough to still do some kind of 'basic' uninstall if the original file goes missing. But again, I don't work for MS. – Kanya

I believe the system should really store everything needed for #1 and #2. From a user point of view, #3 could require the original install, nobody will ever be surprised by that. And you're right for the installer folder... I guess I must reinstall my box now... Thanks. – Linnette

MSI files in %WINDIR%\Installer\ are "stripped out" versions of original installations so they don't take much of disk space. – Polynesian

Sorry, but this is not a correct answer. 1) file and Registry changes are stored in a dedicated MSI database section of the Registry. The original MSI file is not needed for this purpose. 2) At install-time, the MSI file is cached minus the CAB payload. Therefore, any kind of special uninstall custom actions will still be possible using the cached MSI file; CAB payload not necessary. – Ng

The way Windows operates with this caching has changed - MSI files are now cached full-size (MSI 5 onwards). Please read my updated answer above, and read the comments too. There are several good follow-ups. And read this Heath Stewart blog entry. – Snatch