31

My Wix installer worked installing my program, but it's broken for uninstallation. A file is removed too early, and it's needed further down the line. The uninstaller fails and reverts its changes.

This means I can't remove the package from my machine, and hence can't install any further builds of my installer (a considerable inconvenience). How can I force removal of the package?

PhilDW
  • 20,260
  • 1
  • 18
  • 28
fredley
  • 32,953
  • 42
  • 145
  • 236
  • There are two main approaches: fix the package (either in place with a tool like orca, or via installation of a minor upgrade), or, for internal cases only, trying to remove traces and pretend it was never installed. Which are you looking to do? (If the latter, why weren't you using a virtual machine?) – Michael Urman Mar 14 '12 at 11:46
  • 2
    Before trying the below, maybe try to run [**Microsoft's own tool to solve installation / uninstallation problems**](https://support.microsoft.com/en-us/help/17588/fix-problems-that-block-programs-from-being-installed-or-removed). Try to download and run it, and see if this solves your problem first. The below should work, but is a little hacky. – Stein Åsmul Jun 09 '18 at 16:34
  • @SteinÅsmul has the correct answer. The accepted answer screwed up the uninstaller MSI, and when trying to ununinstall it it kept saying it was "Out of sync" with the original MSI in my development directory (?!?!?). This tool from MS zapped the entire installed thing. – Lavamantis Oct 17 '19 at 21:49
  • @SteinÅsmul I screwed up even more after using the tool. It might be caused by me canceling an incomplete uninstallation. It left some registry keys so subsequence uninstallations after normal installations did not remove the files and the shortcuts anymore. Luckily, a recent system restore point saved me. Anyone trying this tool must not cancel their uninstallation! – keithyip Jan 09 '20 at 04:16
  • Cleanup like this is always unsafe, and there are risks of corruption and errors. However, the other cleanup approaches are even more dangerous - generally. If you have done "half-cleanup" before by hacking the registry and such things, then the tool will almost certainly fail. – Stein Åsmul Jan 09 '20 at 10:32

7 Answers7

27

Update, Stein Åsmul: Injecting this newer list of cleanup approaches.

  1. Find your package in C:\Windows\Installer, where Windows keeps copies of installed MSI packages. The names are generated randomly, so you'll have to look at the creation dates of the files.

  2. Open the MSI file with Orca. (Unfortunately there is no simple download for the orca installer. You can get it by installing the "MSI Tools" of the Windows 10 SDK, and then searching for orca.msi in C:\Program Files (x86)\Windows Kits.)

  3. Delete the offending custom action from the CustomAction table

Now you should be able to uninstall the package.

UPDATE: You can find the actual cache MSI file using Powershell. That was for one package, you can also get for all packages (scroll down to first screenshot).

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
Wim Coenen
  • 66,094
  • 13
  • 157
  • 251
  • Wim, an editor suggested an amendment. Can you have a look at the edit history just to see if you want to make any changes or not? – Bill Woodger Jan 31 '14 at 10:08
  • I made the suggestion, just to clarify it will only work if you try and uninstall it by running the edited package rather than other means (such as Ctrl Panel / Programs and Features / Uninstall). Perhaps I should have just added the notice as a comment. – Joseph Woodward Jan 31 '14 at 10:34
  • @BigJoe: uninstalling via Programs and Features will actually use the msi file in c:\windows\installer – Wim Coenen Jan 31 '14 at 11:38
  • @WimCoenen I thought it would have but it did nothing in my case, however it uninstalled fine when I ran the MSI package I'd edited (which led me to update the answer to save anyone else trying it). I must have done something wrong, please excuse the edit and thanks for your answer! :) – Joseph Woodward Jan 31 '14 at 11:47
  • An important note here: be CAREFUL which database entries you delete. I managed to cause a BSOD on my machine when trying to uninstall an incorrectly modified MSI. After a reboot, I reran the MSI directly, which appeared to reinstall the product (though it was still 'installed' in the Program Features list), and then made the correct change to solve my original problem. – RJ Lohan May 07 '14 at 21:53
  • 1
    This will work for a few computers (your main dev box usually), but if you have deployed a package on a large scale to many computers (corporate deployment), the usual fix is to deploy a minor upgrade which hotfixes the installed product's uninstall sequence (in whatever way is necessary). – Stein Åsmul Mar 22 '18 at 13:09
  • Just pinging Wim, please see my temporary inline edit in your answer. Apologies for the messy format. – Stein Åsmul Jun 09 '18 at 21:08
8

This command usually works for me:

msiexec /fv installer.msi

It somewhat recaches the installer, so you can try again with a corrected one.

One time this command didn't work and I had to use Microsoft FixIt. It solved the problem (quite a shock for me).

nuoritoveri
  • 2,494
  • 1
  • 24
  • 28
  • This helped me - I had a failed installation of my package having .net 4 custom action on machine without .net 4. And I was not able to uninstall it as well. I've fixed msi and was able to run it with /fv switch, ufter that I was able to uninstall it as usual. – sarh Oct 24 '14 at 11:16
  • One thing that tripped me up is that I have my product code set to generate with every build, so I had to remember to get the product code of the cached package and use that when building my fixed installer. – Joel McBeth May 16 '18 at 14:56
7

Depending on the exact reason of the behavior you described, you might have at least a couple of options.

If the reason of the failure is a custom action which runs on uninstall, and this custom action is conditioned with some properties you can influence upon, you can try to pass the desired value via the command line:

msiexec /x {YOUR-PRODUCTCODE-HERE} RUNMYACTION=false

In this sample RUNMYACTION is a Windows Installer property which participates in a custom action condition, and if you pass false as its value, the action won't run.

Otherwise, you can fix the logic (or just disable the custom action explicitly) and build the new MSI package. Then upload it to that target machine, and run like this:

msiexec /i YourPackage.msi REINSTALL=ALL REINSTALLMODE=vomus

Here YourPackage.msi is a new fixed package, REINSTALL=ALL instructs the msiexec to re-install the product using this new package, and REINSTALLMODE=vomus (the v part of it) will re-cache the MSI package and you'll be able to remove it the normal way afterwards.

A side note: you should test your installation on a virtual machine in order not to risk your real one.

Yan Sklyarenko
  • 31,557
  • 24
  • 104
  • 139
4

FYI: In Windows 8.1 the installers have been moved here: C:\ProgramData\Package Cache\

darkrock76
  • 171
  • 1
  • 7
  • 1
    No, this is incorrect actually. There is a cache in `ProgramData`, but it is a cache for source files for **WiX-generated MSI files** ([**info towards the bottom here**](https://stackoverflow.com/a/48823086/129130)). The Windows Installer engine itself still caches at `%SystemRoot%\Installer`, but [there are some changes to how the caching is performed](https://stackoverflow.com/a/1189524/129130). – Stein Åsmul Jun 09 '18 at 16:54
0

I used this little tool also from Microsoft

https://support.microsoft.com/en-us/help/17588/fix-problems-that-block-programs-from-being-installed-or-removed

Basically this tool can be used to "repair issues including corrupted registry keys that block you from installing or removing programs"

What it fixes:

  1. Corrupted registry keys on 64-bit operating systems

  2. Corrupted registry keys that control the update data

  3. Problems that prevent new programs from being installed

  4. Problems that prevent existing programs from being completely uninstalled or updated

  5. Problems that block you from uninstalling a program through Add or Remove Programs (or Programs and Features) in Control Panel

It can be used for:

  • Windows 7
  • Windows 8
  • Windows 8.1
  • Windows 10
Teshte
  • 624
  • 1
  • 7
  • 26
0

If you are really desperate and all solutions above don't work try

msizap.exe

This will erase all that your installer put on a machine
LITTLE WARNING

Don't run msizap without knowing what options you want to run it with (for a list of options run msizap /? first).

CheGueVerra
  • 7,849
  • 4
  • 37
  • 49
-1

I usually just look for <Your Installer's Name>.msi or <Your Installer's Company Name> in the registry and delete some of the uninstall keys from some of the Products under the Windows installer trees and everything usually works fine and dandy afterwards, although this WOULD leave some stuff lying around like cached installers and possibly tons of other registry keys for each file installed, etc. but its ALWAYS worked for me when developing installers because honestly, who cares if one MSI is left over and cached somewhere? You're using the machine for development anyways, right?

Alexandru
  • 12,264
  • 17
  • 113
  • 208