Uninstalling an MSI file from the command line without using msiexec

msiexec is command prompt software that installs an MSI program. But I have found that you can install an MSI file from the command line by just typing in the name of the MSI file on the command line.

But in order to uninstall the MSI file, it seems you have to call the msiexec program and give it a /x or /uninstall.

How can I uninstall an MSI from the command line without using the msiexec routine?

Express Options:

Uninstall by Product GUID: (find product GUID) - section 3 below for logging. There is also: MSI logging in depth here:

msiexec.exe /x {11111111-1111-1111-1111-11111111111X}

Uninstall by MSI file:

msiexec.exe /x "c:\filename.msi"

Express Interactive:

Right click MSI file in Windows Explorer and select "Uninstall".

There are many ways to uninstall an MSI package. The below is intended as a "reference":

In summary you can uninstall via: msiexec.exe, ARP, WMI, PowerShell, Deployment Systems such as SCCM, VBScript / COM Automation, DTF, or via hidden Windows cache folder, and a few other options presented below.

The first few paragraphs provide important MSI tidbits, then there are 14 sections with different ways to uninstall an MSI file. Puh.

"Babble, Babble - Over": Sections 1, 2 and 3 are the normal uninstall approaches (and hence recommended). Personally I use option 3 or 5 from section 3 (both options with logging, but option 5 runs silently as well). If you are very busy, skip all the babble and go for one of these - it will get the job done.

If you have problems uninstalling altogether and are looking for an alternative to the deprecated MsiZap.exe and / or Windows Installer CleanUp Utility (MSICUU2.exe), you can try the new FixIt tool from Microsoft (or the international page). May apparently work for other install issues as well.

Newer list of cleanup approaches: Cleaning out broken MSI uninstalls.

If you think MSI and Windows Installer is more trouble than it's worth, you might want to read about the corporate benefits of using MSI files.

Installscript MSI setups generally come wrapped in a setup.exe file. To read more about the parameters to use for uninstalling such setups please see these links: setup.exe pdf reference sheet, Setup.exe and Update.exe Command-Line Parameters.

Some MSI files are installed as part of bundles via mechanism such as Burn (WiX Toolkit) or InstallShield Suite projects. This can make uninstall slightly different from what is seen below. Here is an example for InstallShield Suite projects.

Be aware that running uninstall silently or interactively can cause different results (!). For a rather lengthy description of why this is the case, please read this post: Uninstall from Control Panel is different from Remove from .msi

If you are unexpectedly asked for the original installation media when trying to uninstall, please read this answer: Why does MSI require the original .msi file to proceed with an uninstall? and perhaps also section 12 below for some important technical details.

If you got CCleaner or similar cleanup tools installed, perhaps jump to section 11.

If uninstall is failing entirely (not possible to run), see sections 12 & 13 below for a potential way to "undo" the installation using system restore and / or cleanup tools.

1 - Using the original MSI

• If you have access to the original MSI used for the installation, you can simply right click it in Windows Explorer and select Uninstall.
• You can also uninstall via command line as explained in section 3.

2 - Using the old ARP Applet OR new Windows 8/10 Settings Interface

• Just got to mention the normal approach(es) though it is obvious

• ARP = Add / Remove Programs Applet (appwiz.cpl)

• Windows 10 Settings Interface => New shell for same operation

• ARP:

  • Go start → run → appwiz.cpl → ENTER in order to open the add/remove programs applet (or click add/ remove programs in the control panel)
  • Click "Remove" for the product you want to uninstall

• Settings Interface (Windows 8 / 10):

  • Use the new Settings GUI in Windows 8 / 10
    • Windows Key + Tap I => Apps & Features. Select entry and uninstall.
  • Direct shortcut:
    • Windows Key + Tap R => Type: ms-settings:appsfeatures and press Enter
  • Some reports of errors when invoking uninstall this way. Please add comments below if seen.
    • Try this answer as well
    • General hint: try disabling anti-virus and try again.

3 - Using msiexec.exe command line (directly or via a batch file)

• You can uninstall via the command prompt (cmd.exe), batch file or or even from within an executable as a shell operation.
• You do this by passing the product GUID (check below for how to find this GUID) or the path to the original MSI file, if available, to msiexec.exe.
• For all the command lines below you can add /qn to make the uninstall run in silent mode. This is how an uninstall runs when triggered from the add/remove applet.

Option 3.1: Basic interactive uninstall (access to original MSI file):

msiexec.exe /x "c:\filename.msi"

Option 3.2: Basic interactive uninstall via product GUID (no access to original MSI file - here is how to find the product GUID - same link as below):

msiexec.exe /x {11111111-1111-1111-1111-11111111111X}

Option 3.3: Interactive uninstall with verbose log file:

msiexec.exe /x "c:\filename.msi" /L*V "C:\msilog.log"
msiexec.exe /x {11111111-1111-1111-1111-11111111111X} /L*V "C:\msilog.log"

Option 3.4: Interactive uninstall with flushed, verbose log file (verbose, flush to log option - write log continuously, can be very slow):

msiexec.exe /x "c:\filename.msi" /L*V! "C:\msilog.log"
msiexec.exe /x {11111111-1111-1111-1111-11111111111X} /L*V! "C:\msilog.log"

• The flush to log option makes the uninstall slow because the log file is written continuously instead of in batches. This ensures no log-buffer is lost if the setup crashes.

• In other words, enable this option if your setup is crashing and there is no helpful information in your verbose log file. Remove the exclamation mark to turn off the flush to log option and the uninstall will be much quicker. You still get verbose logging, but as stated some log buffer could be lost.

Option 3.5 (recommended): Silent uninstall with verbose log file - suppress reboots (no flush to log - see previous option for what this means):

msiexec.exe /x "c:\filename.msi" /QN /L*V "C:\msilog.log" REBOOT=R
msiexec.exe /x {11111111-1111-1111-1111-11111111111X} /QN /L*V "C:\msilog.log" REBOOT=R

Quick Parameter Explanation (since I recommend this option):

/X = run uninstall sequence
/QN = run completely silently
/L*V "C:\msilog.log"= verbose logging at path specified
{11111111-1111-1111-1111-11111111111X} = product guid of app to uninstall
REBOOT=R = prevent unexpected reboot of computer

Again, how to find the product guid: How can I find the product GUID of an installed MSI setup? (for uninstall if you don't have the original MSI to specify in the uninstall command).

• Top tip: If you create a log file for your uninstall, you can locate problems in the log by searching for "value 3". This is particularly useful for verbose files, because they are so, well, verbose :-).

• How to find the product GUID for an installed MSI?

  • There are several ways, my recommended way is using Powershell: How can I find the product GUID of an installed MSI setup?
  • Several other ways described here (registry, local cache folder, etc...): Find GUID From MSI File

• More information on logging from installsite.org: How do I create a log file of my installation? - great overview of different options and also specifics of InstallShield logging.

• Msiexec (command-line options) - overview of the command line for msiexec.exe from MSDN. Here is the Technet version.

4 - Using the cached MSI database in the super hidden cache folder

• MSI strips out all cabs (older Windows versions) and caches each MSI installed in a super-hidden system folder at %SystemRoot%\Installer (you need to show hidden files to see it).
• NB: This supper-hidden folder is now being treated differently in Windows 7 onwards. MSI files are now cached full-size. Read the linked thread for more details - recommended read for anyone who finds this answer and fiddles with dangerous Windows settings.
• Avoid these huge cached files by using admin installations. On the topic of disk space: How can I get rid of huge cached MSI files (and other disk space cleanup tricks).
• All the MSI files here will have a random name (hex format) assigned, but you can get information about each MSI by showing the Windows Explorer status bar (View -> Status Bar) and then selecting an MSI. The summary stream from the MSI will be visible at the bottom of the Windows Explorer window. Or as Christopher Galpin points out, turn on the "Comments" column in Windows Explorer and select the MSI file (see this article for how to do this).
• Short answer on using Windows Explorer
• Once you find the right MSI, just right click it and go Uninstall.
• You can also use PowerShell to show the full path to the locally cached package along with the product name. This is the easiest option in my opinion.
• To fire up PowerShell: hold down the Windows key, tap R, release the Windows key, type in "powershell" and press OK. Then maximize the PowerShell window and run the command below:

  get-wmiobject Win32_Product | Format-Table Name, LocalPackage -AutoSize

• Also see this answer: How can I find the product GUID of an installed MSI setup?

5 - Using PowerShell

• There is a similar, but more comprehensive PowerShell script available on MSDN. It allows uninstall to be run on several machines.

• Entry added by Even Mien:

   $app = Get-WmiObject -Class Win32_Product -Filter "Name = 'YOUR_APP'"
   $app.Uninstall()
  

• This approach will work, but accessing the WMI class Win32_Product will trigger a software consistency check which is very slow and in special circumstances it can cause an MSI self-repair to be triggered. See this article: Powershell Uninstall Script - Have a real headache

• I have not tested this myself, but it appears $app.Uninstall() may run the UninstallString registered in the ARP applet's registry settings. This means it may run modify instead of uninstall in some cases.

• Check this topic for more details and ways to uninstall via Powershell: How can I uninstall an application using PowerShell?

6 - Using the .NET DTF Class Library (part of the WiX toolkit)

• This option is included for developers getting into deployment and MSI - it is not really practical as a "quick fix". It requires that you download the WiX toolkit - a free framework for creating MSI files compiled from XML source file(s).
• A quick blurb on WiX and its "history": Windows Installer and the creation of WiX. And here is WiX contrasted with other deployment tools (commercial) - (strengths and weaknesses - hopefully as objective as possible).
• DTF (Deployment Tools Foundation) is distributed as part of WiX as explained here: Is source-code for Deployment Tools Foundation available?.
• DTF is essentially a .NET wrapper for the Win32 Windows Installer API. It eliminates all need for COM Interop when working with Windows Installer via automation and is nothing short of a .NET jewel - perhaps the easiest-to-use .NET library I have ever seen. Highly recommended - great even for training students in C#.
• The following source from MSI expert Christopher Painter using C# and DTF. Microsoft.Deployment.WindowsInstaller is one of the DTF assemblies. See the other assemblies explained here on serverfault.com:

    using Microsoft.Deployment.WindowsInstaller;

    public static void Uninstall( string productCode)
    {
      Installer.ConfigureProduct(productCode, 0, InstallState.Absent, "REBOOT=\"R\"");
    }

• Anther alternative from Tom Blodget: Checking for successful uninstall
• More information on msiexec.exe versus automation on: serverfault.com.

7 - Using the Windows Installer Automation API

• Here is a community discussion of this option: Windows Installer Automation API community sample

• The API can be accessed via script automation and C++ API calls (my post on serverfault.com)

• The following source adapted from MSI expert Christopher Painter using VBScript:

   Set installer = CreateObject("WindowsInstaller.Installer")
   installer.InstallProduct "product.msi", "REMOVE=ALL REBOOT=ReallySuppress"
   Set installer = Nothing
  

• Here is another VBScript for uninstalling by GUID from Symantec: http://www.symantec.com/connect/downloads/uninstall-application-using-guid-registry

• Uninstall via upgrade code & ConfigureProduct.

8 - Using a Windows Installer major upgrade

• A Windows Installer major upgrade may happen as part of the installation of another MSI file.
• A major upgrade is authored by identifying related products in the MSI's "Upgrade table". These related setups are then handled as specified in the table. Generally that means they are uninstalled, but the main setup can also be aborted instead (typically used to detect higher versions of your own application present on the box).

9 - Using Deployment Systems / Remote Administration Systems

• SCCM, CA Unicenter, IBM's Tivoli, Altiris Client Management Suite, and several others
• These tools feature advanced client PC management, and this includes the install and uninstall of MSI files
• These tools seem to use a combination of msiexec.exe, automation, WMI, etc... and even their own way of invoking installs and uninstalls.
• In my experience these tools feature a lot of "personality" and you need to adapt to their different ways of doing things.

10 - Using WMI - Windows Management Instrumentation

• Adding just for completeness. It is not recommended to use this approach since it is very slow
  • A software consistency check is triggered every time Win32_Product is called of each installation
  • The consistency check is incredibly slow, and it may also trigger a software repair. See this article: Powershell Uninstall Script - Have a real headache
  • Even worse, some people report their event logs filling up with MsiInstaller EventID 1035 entries - apparently caused by WMI queries to the Win32_Product class (personally I have never seen this).
• The WMICodeCreator.exe code creation tool can be used to experiment
  • Install can be invoked via Win32_Product.Install
  • Uninstall can be invoked via Win32_Product.Uninstall
• MSDN sample: Uninstall method of the Win32_Product class

11 - Using a third-party tool such as ccleaner or similar

• Several Windows applications feature their own interface for uninstalling not just MSI packages, but legacy installers too.
• I don't want to make any specific tool recommendations here (especially commercial ones), but the well known CCleaner features such an uninstall interface (and it has a free version). I should also add that this tool suffered a malware attack recently.
• I guess we should all remember that even harmless software can be injected with malware in their download locations (FTP attack).
  • I use virustotal.com to check my downloads, and also Sysinternals Process Explorer to check running processes after installation - along with regular security software (whichever is available).
  • A surprising amount of "gray area" software is usually found with this approach (toolbars, smileys, adware, etc...), along with several false positives (they can also cause problems as security software block their access or quarantines them making a lot of fuzz). And certainly real malware as well.
  • Some usage tips for Process Explorer can be found here - a series of tweets - this Process Explorer tool hooks up to VirusTotal.com to check all running processes interactively - all you need is a few configuration steps.
  • I should note that Process Explorer yields a file signature check, but no heuristics - as far as I understand (no check for suspicious operations, just a check with 60+ security suites for flagged files). You need a regular security tool for interactive, online heuristic protection.
  • For what it is worth, I think some security software border on causing more false-positive problems than malware does damage. Famous last words in the era of ransom-ware...
  • That is a large enough digression - I just don't want to see people download malware. Do your virustotal.com check at least.
• Uninstalling like this should work OK. I think these tools mess with too many things when you try their "cleanup features" though. Use with caution. If you only use the uninstall feature, you should be OK.

12 - Using a cleanup tool such as msizap or similar

• For completeness msizap.exe should be mentioned though it is deprecated, unsupported and outdated. It should not be used on any newer Windows versions
• This command line tool (msizap.exe) also had a GUI available (MSICUU2.exe). Both tools are deprectated.
• The intended use of these tools was to clean out failing uninstalls:
• Generally for the rare case when the cached MSI with the random name is erroneously missing and uninstall fails for this reason whilst asking for the original MSI. This is a rare problem, but I have seen it myself. Just a few potential causes: Moved to this answer.
  • Key words: system restore interference, bad cleanup apps, msiexec.exe crashing, power outage, security software interference, MSI development debugging blunders (identical package codes, etc...), user tinkering and hacking (what is in here? save space?), etc...
  • It could also be used to zap any MSI installation, though that is obviously not advisable.
  • More information: Why does MSI require the original .msi file to proceed with an uninstall?
• This newer support tool (this tool is now also deprecated) can be tried on recent Windows versions if you have defunct MSI packages needing uninstall.
• 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.
• If you have access to the original MSI that was actually used to install the product, you can use this to run the uninstall. It must be the exact MSI that was used, and not just a similar one.

13 - Using system restore ("installation undo" - last resort IMHO)

• This is strictly speaking not a way to "uninstall" but to "undo" the last install, or several installs for that matter.
• Restoring via a restore point brings the system back to a previous installation state (you can find video demos of this on YouTube or a similar site).
• Note that the feature can be disabled entirely or partly - it is possible to disable permanently for the whole machine, or adhoc per install.
• 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 (bluescreen, reboots, instability, etc...).
• The longer you go back the more rework you will create for yourself, and the higher the risk will be. Most systems feature only a few restore points, and most of them stretch back just a month or two I believe.
• Be aware that system restore might affect Windows Updates that must then be re-applied - as well as many other system settings. Beyond pure annoyances, this can also cause security issues to resurface and you might want to run a specific security check on the target box(es) using Microsoft Baseline Security Analyzer or similar tools.
• 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 it 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.

14 - Windows Installer Functions (C++)

For completeness I guess we should mention the core of it all - the down-to-the-metal way: the Win32 Windows Installer API functions. These are likely the functions used by most, if not all of the other approaches listed above "under the hood". They are primarily used by applications or solutions dealing directly with MSI as a technology.

There is an answer on serverfault.com which may be of interest as a summary of the different programmatic approaches for uninstalling (COM Automation, .NET, Win32 installer functions).

Below you will find a C++ snippet showing how to uninstall Orca, 10.1.17134.12 by product code using a call to the MsiConfigureProductEx function. To uninstall another product replace the GUID specified for prodcode with the one for your product. To find the product code see this answer: How can I find the product GUID of an installed MSI setup?

The uninstall will happen in full GUI mode. To run in silent mode or some other GUI mode (reduced, basic, etc...), please see the: MsiSetInternalUI function.

#include "pch.h"

#define WIN32_LEAN_AND_MEAN //Minimize includes from Windows.h
#include <windows.h>
#include <msi.h> // Windows Installer
#include <tchar.h> 

#pragma comment(lib, "msi.lib") // To make code link

int main()
{
    const TCHAR noreboot[] = _T("REBOOT=ReallySuppress");
    const TCHAR prodcode[39] = _T("{D7B80ABC-1950-37B8-F851-C3783EED9C93}"); // Orca, 10.1.17134.12

    UINT res = MsiConfigureProductEx(prodcode, INSTALLLEVEL_DEFAULT, INSTALLSTATE_ABSENT, noreboot);

    return res; // Error Codes: https://msdn.microsoft.com/en-us/library/windows/desktop/aa376931(v=vs.85).aspx
}

The snippet was made and tested with the latest version of Visual Studio 2017 as of September 2018:

1. Create a new "Windows Console Application" from Visual C++ => Windows Desktop.

2. Copy and paste the above code into your main CPP file (replacing whatever is there).

3. That should be it to be able to run the code. Maybe set a breakpoint, build and run.

   • Beware of changes to the default templates in VS2017, and the weird errors that can result: There are too many errors for the IntelliSense engine to function correctly.
   • UPDATE September 2018: Templates have changed again. I no longer see the above issue.
   • The MSDN link in the code lists the possible error messages returned from msiexec.exe.

Short answer: you can't. Use MSIEXEC /x

Long answer: When you run the MSI file directly at the command line, all that's happening is that it runs MSIEXEC for you. This association is stored in the registry. You can see a list of associations by (in Windows Explorer) going to Tools / Folder Options / File Types.

For example, you can run a .DOC file from the command line, and WordPad or WinWord will open it for you.

If you look in the registry under HKEY_CLASSES_ROOT\.msi, you'll see that .MSI files are associated with the ProgID "Msi.Package". If you look in HKEY_CLASSES_ROOT\Msi.Package\shell\Open\command, you'll see the command line that Windows actually uses when you "run" a .MSI file.