My install fails on uninstall because of a bug in my CustomAction. I've fixed the bug, but I now have a test machine with that product installed and I can't get it to uninstall (keeps rolling back and staying).
In the past (years ago), I used msizap.exe that comes with the Windows SDK. But it doesn't seem to come with it anymore. I installed it and can't find it. My only guess is that it's no longer relevant in Windows 10.
Anyway, is there a best way to forcibly remove the product so that Windows no longer thinks it's installed?
msizap.exe: You are correct, msizap.exe has been deprecated long ago.
Broken Uninstall Workarounds: This problem is very common. You can find a list of approaches for these kind of uninstall problems here.
The easiest and fastest is probably to just use the Microsoft FixIt tool to remove the package. This basically "unregisters it" by the looks of it, and is similar to msizap.exe in that regard.
If this is just a single machine you can hack the cached installation database using Orca (how to find cached msi path, powershell version, using Windows Explorer - point 2) - if it involves many machines you should make a patch. Please see details in link above.
Virtual Machines: It is obvious, but just to mention that you should check setups on virtual machines so you can just revert the virtual machine when you encounter "development and QA bugs" like these.
Custom Action Flag: You can also add a condition to each custom action so that you can disable the whole custom action from running by a custom command line sent to msiexec.exe.
If your flag is a property RUNCA="1", then you can disable it by setting this flag property to 0 via the command line - this is sort of a little inoculation for the package's uninstall feature breaking - you can disable custom actions from running at all during install / uninstall - it might even be useful for your tech-support guys and real-world installations:
msiexec.exe /x {PRODUCT-CODE} RUNCA=0
Related
I am having trouble uninstalling a package from Windows 7 that I myself have created with InstallShield.
Running remove program from control panel only got 1/2 way before it aborted and rolled back.
Funnily it reported the problem being one of my install steps, not one of the uninstall steps.
Frustrated I used the Windows Install Cleanup and the package is no longer listed under Remove programs.
However when I try to run the installer once more it reports that a previous version of the software must be uninstalled before it can proceed.
I was guessing that the Unique ID was still present in the registry but is not.
How exactly does windows determine that a previous version of the software is installed on my machine?
The best solution to an uninstall issue that prevents the product from being uninstalled is to debug the issue (often a custom action) and fix it or delete it, then rebuild the MSI with the same ProductCode. Then reinstall it with a command line:
msiexec /I [path to msi file] REINSTALL=ALL REINSTALLMODE=vomus
which updates the product in place and the re-cached fixed product will now uninstall. Otherwise (because you can't recreate the MSI) it is possible to go into the cached MSI in C:\Windows\installer and change the MSI manually with Orca, conditioning CAs not to run, for example. But you need to know what you're doing.
In other words and unfortunately, it would have been better to get the uninstall issue dealt with before resorting to the installer clean up utility, which I believe may no longer be supported because it doesn't completely clean up the system.
Your best approach now is to change your ProductCode, UpgradeCode and PackageCode because they'll be among the items on the system that Windows will use to see that your product is already installed. This stuff is in the registry, but it's obfuscated (rearranged guids) and scattered around.
My engineer send me 2 versions of installation software for evaluation (made with Installshield), which he said he has made no changes to the Restart settings, but just changes messages in dialog boxes.
However, when tested on Win 8 and Win 7
One version will restart Windows while Windows does not prompt there are applications with open files
One version will attempt to restart Windows, but then Windows will prompt there are applications with open files
I am not a programmer, but I would like to know what may be possible cause of this difference? And what is the setting which can cause the 2 different restart behavior.
Then I would like to know how can I test the installation software to make sure it is designed properly and make Windows attempts to restart properly such that it won't force a restart if there is any open files; after all, making users lose their work is very bad.
Thank you very much.
John
If your Installer installs any prerequisites, it may be possible that the reboot is required to install the prerequisite properly. So it is possible that the prerequisite would be installed when you wold have installed your product for the first time and it would have asked for the 'Restart'. And now as the prerequisite is installed, no need to reinstall it so 'Reboot' is not required.
If this is the case, you can go to'Application Data' > 'Redistributables' and edit the prerequisite. Here you can specify appropriate condition to handle the 'Restart' behavior.
If your application doesn't install prerequisite and it is your product that requires a reboot, please have a look at this answer. You can configure a property to handle the 'Restart' properly.
I'm trying to use this Visual Studio extension for 2013, which recreates the built-in installer functionality from Visual Studio 2008/2010: http://blogs.msdn.com/b/visualstudio/archive/2014/04/17/visual-studio-installer-projects-extension.aspx?CommentPosted=true&PageIndex=2#comments
It works, allowing me to edit the project as before. It has the install and uninstall commands when right-clicking the install project, too. It installs fine.
When I try to uninstall, though, I get the following error and then the uninstall rolls back:
Could not open key: HKEY_LOCAL_MACHINE32\SOFTWARE\Wow6432Node\Microsoft\
EAPSIMMethods\18\FastReauthContext. Verify that you have sufficient
access to that key, or contact your support personnel.
I am not doing anything with that registry key, and there don't seem to be any relevant results on google-- at least not in the normal top 5 pages. Does anyone know what causes this or how I can fix it?
While I am not able to uninstall, I am able to increment the version of the package and allow it to remove the previous install and install the new version (all at once) successfully.
I am using Windows 8.1 Pro 64 bit, the projects are compiled for <AnyCPU>, and the installer is configured for x86.
EDIT I am running Visual Studio as Admin. When uninstalling from the Control Panel, I am also clicking the 'allow' button in the UAC dialog window that pops up.
I know how to give myself access to a registry key (permissions). I want to know why this key is trying to be removed. I support this app on several machines and I don't want to have worry about remembering an uninstall hack in the future.
EDIT This only seems to be an issue for a 32x installer on a 64x OS or a Windows 8 issue. I was able to use the same 32x installer to successfully uninstall the app on a 32x Windows 7 machine.
This must be an environmental problem, that key doesn't have anything to do with installers. EAP-SIM is an authentication protocol for wireless networks. The FastReauthContext key almost surely was meant to avoid having to provide a username+password each time your machine reconnects to the network. Which makes the registry key content very sensitive of course, it can only be read by a service that runs with the System account.
So, something goofy going on with your networking setup. Verify that you can successfully reconnect to such a network. If you used a VPN before then make sure it is active again. Something like this. Update your question with anything that might be relevant to networking when you first installed the app.
I have had similar problem and what I found out this is caused by MSI attempting to delete whole "Software\Microsoft" section in the registry. Lucky you that it encounters this error and rolls everything back.
So the solution is the following:
Since you have installed your program whenever you try to uninstall it the system will run msi from cache that is usually located C:\Windows\Installer.
Find your package in the cache. Here is an article that may help you http://csi-windows.com/blog/all/27-csi-news-general/334-identifying-cached-msi-packages-in-cwindowsinstaller-without-opening-them
Open the package in Orca. You must do this as administrator.
Go to Registry table and find record with "Software\Microsoft" as a key. Most likely the Name column will contain either "-" or "*" value. This means that during uninstall MSI will try to delete whole "Software\Microsoft".
Either change the Name value to empty or "+" or try to change key to something like "Microsoft". The second option will cause that installer will not find the key to delete during uninstall, but it will skip this error and let you uninstall your program.
You installed an untested installer on your dev machine? Speaking from experience, don't do that! Snapshotted VM's are cheap and will save you from this sort of pain.
Visual Studio Deployment Projects (or VSI as it's now called ) is known for creating very poor quality installs. The combination of those two put you where you are today.
I would need to look at the full uninstall log and your MSI using ORCA to understand exactly what is going on. MSI Zap and a manual cleanup of resources is probably required at this point.
I have an application (Installed as a service) that has 5 different versions. For testing I need to have all 5 installed. Currently I have to uninstall the application and reinstall the required version.
The application has a single exe (in Program Files\App) along some an xml file containing it's settings. This is installed via an MSI file. Each version has the same file\service name and checks for previous versions before installing.
Any ideas on a way to run all five versions at the same time?
First of all, I assume you're a developer, not the QA person. The QA need to use either virtual machines, or just 5 separate PCs. What I'm describing is a dirty hack that might save you some time.
Install version #1 to C:\program files\YourApp_1
Launch services.msc, stop the service, change the startup type to manual.
Launch regedit.exe.
Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services key, find the key for your service, rename the service: change both the key name, the "DisplayName" value, and to simplify your life write something meaningful to the "Description" value, e.g. "MyApp 1.0 - this is the reference version".
If the installer checks some other keys before installing (it might be e.g. in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\YourApp), remove them. If you don't know those keys - use SysInternals ProcessMonitor to get them (set filter to instmsiw.exe or something, then launch the installer, wait for the "the prevoius version was found" message, alt-tab to the ProcessMonitor, stop logging, and read the log bottom-to-top)
Now install version #2 to C:\program files\YourApp_2, repeat the process.
At the end, to switch versions you'll only need to launch services.msc, stop the version that's currently running, start another one. Or use net start / net stop command line commands. Or whatever.
P.S. Warning Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall your operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk.
Though this is more of a Sever Fault type of question:
http://www.microsoft.com/windows/virtual-pc/
There's yer answer :-)
Use virtual machines for each of your 5 different versions.
VMWare player is free: http://www.vmware.com/products/player/
Use VirtualBox.
Create one test system, configure it, then clone it 5 times (you'll have to use vboxmanage), and install one version on each of them.
If it wasn't a service, I had suggested Sandboxie, but I doubt that Sandboxie can handle services.
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?
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.
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).