Windows Installer self-repair can cause problems for both developers, system administrators and end users. Finding the solution can be difficult if you have limited MSI experience.
This is a Q&A-style answer intended as a check list for solving self-repair problems. Here are a few common problem scenarios:
Repeated Windows Installer self-repair might occur whenever you launch an application on your workstation. How can this be fixed, or how can components be disabled so it never occurs again?
A WiX installer may be deployed and you see repeated Windows installer self-repair whenever you try to launch the application.
When enabling or installing an MS Office addin, you experience continuous Windows Installer self-repair on application launch of one or more MS Office applications.
When working on legacy solutions in VB6 or VBA, self-repair kicks in for an unrelated product when you launch the main developer IDE.
When opening a form in Outlook, Excel or Word or similar applications, self-repair kicks off for an unrelated product from another vendor.
Keywords: Windows Installer launches unexpectedly. MSI displays unexpectedly. Windows Installer appears every time. Opening Application Starts Windows Installer. Windows Installer self healing. How does a package self-heal. MSI self-heal best practice. Windows Installer repair. Self-Repair. Disable Windows Installer. Windows Installer repeatedly runs. Application Shortcut launches installer instead. Windows Installer appears unexpectedly.
Self-Repair, Simple & Short Explanation: Why does the MSI installer reconfigure if I delete a file?
Concrete Design Advice for your WiX / MSI File
I keep trying to write about repeating MSI self-repair for developers, but end up with too much detail. Here is my last attempt: concrete design advice for what not to do in your WiX / MSI file.
The answer below provides a checklist for solving any self-repair scenarios - from any vendor or source, not just your own. Check the answer linked above for your own MSI package design concerns.
The "Short Version" - Self-Repair Checklist
To permanently and reliably fix self-repair problems for everyone, developers and setup developers must be involved since the real fix must happen at the vendor level.
If you are in a corporate environment, poor-quality application re-packaging can also cause self-repair problems, and you should involve your application packagers to determine if the problem is from the vendor or not.
System administrators must know what they are looking at, and when no fix is available, use various workarounds to deal with the problem in the wild. Even end users can try some easy workarounds themselves (see section 5).
The essence of self-repair problems:
Most self-repair issues are COM-related, and there are two general fixes for vendors and developers: 1) use the properly deployed, shared COM libraries generally deployed via merge modules, or 2) use registration-less COM to "shield" your application from self-repair and compatibility issues.
Your setup developer can implement the merge module fix, developers must test. Merge modules are standardized, shared deployment libraries for shared files.
Registration-less COM only works with developer involvement in my experience. This option is particularly relevant if the developer needs to use a particular version of a COM file (for whatever reason). Details in section 5.4 below.
Apart from COM, you can also cause self-repair problems by having your setup developer register file- and MIME-associations and command verbs in your MSI setup. Use sparingly, and ensure your file-/MIME associations are unique.
Finally you can cause self-repair by any file- or registry conflict between two installed MSI files. They "share a resource by mistake" and will treat it as its own - battling it out until the conflict is resolved.
Some self-repair problems are not caused by errors in the vendor application or setup at all, but by external factors in the computer environment in question, such as interference from tinkering users, scripts, viruses, anti-viruses or security software. See section 3 for more details.
Quick Options For Dealing With Problem Applications
Perhaps jump straight to section 5 for the list of suggested fixes and workarounds if you are sure the self-repair you see is caused by MSI alone (and not by other, external causes as described in the first few sections below).
Most of these proposed "solutions" in section 5 are really mostly system administrator tricks that don't fix the underlying problem - as stated above the real fix has to come from the vendor. The exception is "5.4: registration-less COM", which can actually help developers "shield" their applications from self-repair problems.
If you don't have admin rights on your box you are advised to try "solutions" 5.2, 5.3 or 5.1 (5.1 will generally require admin rights to try, but it is non-complicated). These are "quick workarounds", the others are more involved. If these workarounds don't work, please ask your admin to read the other suggestions.
Understanding Windows Installer Self-Repair
I have written at length about this issue before, but it focused too much on understanding the problem rather than actually finding an acceptable fix for it. You can read the full explanation of self-repair problems here: How can I determine what causes repeated Windows Installer self-repair?.
Fixing Windows Installer Self-Repair Issues
To actually fix repeated and endless self-repair, you can try the suggestions below in section 5 - in increasing order of complexity and difficulty. Before doing so, you should verify what the real source of the self-repair problem really is. It might not be caused by MSI files, but by other, external causes (such as scripts or users deleting files or anti-virus blocking files).
If the problem is indeed MSI-related, you can try to disable advertised shortcuts and COM addins, use registration-less COM, get help from the application vendor, uninstall offending applications, virtualize packages or full on hack the cached MSI database and registry (not recommended, and only really possible with expert help). It all depends on your scenario. If external causes such as scripts are at fault, you must eliminate this interference. See details below - just follow the check-list.
The first steps for problem solving are to identify that the problem really exists in the wild on your platform, and then to determine what application(s) trigger the self-repair in the first place:
1. Verify that the problem really exists in your environment.
It is generally always possible to figure out what is going on to cause the problematic self-repair, and there are several viable workarounds that can be utilized to deal with the problem. It is, however, not always possible to find a good, permanent fix (without vendor help - as described below).
Accordingly, if you are a system administrator trying to find a fix for your self-repair issue, perhaps make sure the problem is seen on more than one computer - especially if the problem is seen on a developer-, QA- or even a test computer.
If you only see self-repair problems on one computer, an alternative might be to rebuild the problem computer. Effectively eliminating rather than "solving" the problem. There is a relatively high risk that you might see the problem again though. If you ask me, don't rebuild, it is no solution - but what tends to be done in the real world I guess.
Be aware that an AD-advertised MSI install that is slow to install and keeps getting aborted by users can "look like" a self-repair issue for desktop support, but this is expected MSI behavior. Allow the install to complete once (it is possible to change the installer progress bar to disable the cancel button - something like msiexec.exe /I "MyApp.msi" /QB-! for progress bar only with no cancel button and no modal dialog at the end).
2. Identify the culprit(s) for the self-repair.
It is possible for a single application to cause the problem on its own, but typically there are at least two applications that conflict (they share some resource by mistake).
The trigger for the self-repair is generally possible to find in your event viewer on the system where the self-repair took place. Follow these steps to open the event viewer:
Right click "My Computer"
Click Manage
Click continue if you get an UAC prompt
Go to the Event Viewer section, and check the Windows Logs
Identify the offending application in the Windows Event Log by looking in the "Application section" of the event log and you should find warnings from the event source "MsiInstaller" with IDs 1001 and 1004.
You can find a lot more details on how to do this in the more elaborate answer here: How can I determine what causes repeated Windows Installer self-repair?. Look in the "Finding the trigger or culprit for the self-repair" section.
You can also try the advice from independent deployment specialist, MSI-expert and MVP Stefan Krüger. He has an article about the same self-repair issue. And he crucially discusses the actual event log entries and what they mean. Please read about the actual debugging procedure there.
3. Verify that external non-MSI causes are not causing the problem
Anything that deletes files or registry settings, manually or automatically, can trigger MSI self-repair. Especially if you are messing around deleting stuff in the user profile or in the HKCU section of the registry.
In most cases such triggers will only cause a single self-repair to run and then the problem is fixed (this is how self-repair is supposed to work and help users). Allow self-repair to run once and then launch the application again to test if the problem is gone. It should be, and your application should launch correctly from now on.
Special case: Ironically you can sometimes fix a broken application by renaming its HKCU application key (in the user section of the registry) to actually force self-repair to run and install the application's default data in the user profile - if that data was accidentally deleted (this type of fix generally does not work on terminal servers).
If the same file or registry entry is deleted again by automated means and self-repair results, you must eliminate or update the automatic process that is causing it and your problem is solved and you can stop reading. If you manually deleted the file again yourself, then you may suffer from bad memory :-).
In summary cleanup scripts, logon scripts, cleanup applications or tinkering, overactive users can all cause this kind of self-repair.
Finally viruses and also anti-virus software (and other security software) can block access to files and trigger self-repair that will never succeed.
For an infected computer, just rebuild the computer. It will save you time overall.
For anti-virus / security software problems, bring out your security guys to solve it. They may need to contact the vendor in some cases (particularly for false positives).
Whether virus or anti-virus related, check the offending file on http://www.virustotal.com to verify whether it is actually a virus or just a false positive (which can be an even bigger problem for self-repair).
Personally I have seen several anti-virus / security software related self-repair problems, but no real virus-related problems (so far). I guess viruses normally infect core system files rather than application files, and core system files are not to be deployed by MSI files (shared system files might be included in MSI files, but not core system files).
4. Contact the vendor(s) (or your own packaging department).
Once you have verified that the self-repair problem is MSI-based and it is not your own software, the first thing to try is to contact the application vendor(s) and see if they have an updated installer to eliminate the problem.
It is important to try this option since all other options are "workarounds" and not real fixes. The problem can only be completely resolved permanently by changes in the vendor installer and possibly the application executable itself.
Fix 1: The fix can be as simple as having the vendor remove privately installed but globally registered COM files with the appropriate, shared "merge module" to install the run-time correctly for everyone. These should install COM files properly to shared locations where they can be globally registered without side effect. Ready for everyone's use.
Fix 2: If the vendor claims this isn't possible - then they should be able to provide a proper registration-less COM installation with properly isolated COM files installed to the main application folder. They should also take care of deploying any security updates whenever they would come along.
Important!: If the vendor either uses the correct, shared merge module to deploy files or provides an isolated installation using registration-less COM, then the problem should be solved permanently for everyone.
The problem can also be caused by other issues, but very often COM is the culprit. Sometimes a cleanup of their MSI installer can resolve other, more obscure conflicts. If you know a good application packager, he/she should be able to quickly identify conflicts (and provide feedback for the vendor).
Note that it is also possible that the self-repair is caused by erroneous (in-house) repackaging of vendor software. In that case you can fix your own packages via updates delivered by your own packaging / deployment department (and they should definitely be able to achieve this for most cases). This is in fact a very common issue.
5. Select a "workaround" or fix to deal with the conflict situation.
If the vendor(s) won't provide a fixed installer package, you need to find a "workaround" to deal with the situation. There are several options, and some "quick workarounds" should be tried before you delve into too much complexity. Here are some problem solving suggestions in order of increasing levels of difficulty and complexity:
5.1: Just uninstall the culprit(s).
The absolute simplest fix is to figure out what application(s) trigger(s) the self-repair and just uninstall it, if that is an acceptable solution for your environment (it rarely is).
This can be acceptable if there are two (or more) applications in conflict and one of them is rarely used or "optional".
You can run the problem application on a virtual machine instead (see section 5.5). This would be my preferred "fix" for a very "misbehaving" application. All problems should disappear without any real debugging (which is costly).
Plain uninstall is an option that is at least worth considering - some software can be very problematic in more ways than one, and should simply be rejected for use. Be sure to let the vendor know that the software was rejected as well. It might be the only way to make them take the problem seriously.
5.2: Remove Advertised Shortcuts.
The first Windows Installer workaround to try is to remove "advertised shortcuts" (essentially a special type of shortcut that points to an Windows Installer application feature, and not directly to an executable or file). Read the linked article from Symantec for details on advertised shortcuts.
Note that shortcuts can be created "anywhere" including in special folders such as the "Startup" folder. This particular location means a self-repair can be triggered by itself on system startup (without user interaction).
Use an MSI viewer tool and open the system-cached MSI and inspect its Shortcut table to find all shortcuts. In order to find a list of all cached packages you can try this answer: How can I find the product GUID of an installed MSI setup? (open the package path specified in "LocalPackage").
You then re-create a regular shortcut that points directly to the executable in question. This will "bypass" the most common trigger of self-repair (the advertised shortcut). In some cases this avoids the whole self-repair issue. It is worth a try.
Be aware that even if this appears to work straight away, self-repair might still re-appear whilst you work inside the application (for example when you open a particular form). You need to "pilot" this fix with some users who actually use the application actively to make sure it is a good enough workaround for your environment.
You have also merely eliminated the symptom of the problem, the registry or file conflict that caused it has merely been "bypassed" or "silenced" - it still exists, but this may be good enough if the applications exhibit no problems during operation.
There is in fact a way to disable all advertised shortcuts on installation of any MSI package. You set the property DISABLEADVTSHORTCUTS (in one of the ways described in the link), and then all shortcuts will be created as regular shortcuts and they will not trigger self-repair. There are at least two problems:
1) The package could be designed to use self-repair to install userprofile files or HKCU settings. In this case this data will then never be added to the system as intended since self-repair will never run, and the install is effectively incomplete.
2) There is no guarantee that self-repair won't still occur - since it can be triggered by other advertised entry points such as COM invocation, file and MIME associations and command verbs.
5.3: Disable COM addins (if possible).
If your problem is related to the loading of an add-in (for Outlook, Excel, Word or other apps like AutoCAD or similar), then there are no shortcuts to tweak - the addin is loaded on launch of its "host application".
The easiest to try is to disable any addins you don't need in the addins dialog of the application in question (often Outlook, Excel or Word or similar) and see if this makes the problem go away. In some cases you are just disabling COM addins that users never used in the first place, and the problem has been eliminated.
And, rather obviously, also try to disable addins that you actually need as well, in order to check if the problem can be related to its loading. If the addin is the culprit, you should continue down the check list to the next proposed solutions (next bullet points).
I should re-iterate that the preferred solution would be a fix from the vendor (most often it would involve making the addin properly use the latest, shared ActiveX/OCX controls in question - other addins could still trigger the problem though, if they are also badly designed. You could end up dealing with multiple vendors - usually blaming each other).
In fairness to the vendors, the problem can also be caused by bad corporate application repackaging - if you are on a corporate machine. Then you must deal with the packaging department for a fix.
5.4: Try registration-less COM
Arguably this solution is more complicated than virtualization (which is described in the next bullet point), but I put it here since it might be a preferred option for some people.
Registration-less COM is something I have rarely used, but it is said to be a viable solution: Generate manifest files for registration-free COM. This essentially bypasses the registry and activates private copies of the COM files controlled by manifest file(s) placed next to the application executable(s) - effectively shielding the application from COM registry interference (in theory). "Everything happens in the same folder".
Your in-house packaging department might be able to use this to deal with "difficult vendor packages" to "isolate" their problems. However, I am not convinced registration-less COM will work properly without a few additional application tweaks contributed by the original solution developer, but I lack the empirical data to back it up. If it is an in-house app with source available, give it a test spin (and let us know).
My main problem with this approach, is that it opens up potential security holes (private copies of COM files that will never be patched by Microsoft), if you don't make sure the isolated components are updated yourself. Updates would likely cause lots of manifest-rewrite work as well (but are these old COM files updated at all anymore anyway?)
Note that registration-less COM, at least in theory, can be used for all COM related conflicts, whether they are VB6 executables, VC++ applications that use COM, etc... I am honestly not sure if it works properly for (office) COM addins (dlls) and VBA forms.
Here is what appears to be one of the better MSDN articles on registration-less COM): https://msdn.microsoft.com/en-us/library/ms973913.aspx (there is even a downloadable MSI with the samples - which ironically seems to trigger an error for me on launch).
Personally I would probably rather try a virtual package using APP-V rather than trying to use registration-less COM (see next bullet point).
It should be re-iterated that rather than "shielding" your own application - the correct vendor fix is to stop deploying private copies of shared COM files that are erroneously registered system-wide, and start installing them as intended using the appropriate merge module for deployment.
5.5: Virtualization (APP-V, Virtual Machine, etc...).
Apart from uninstalling or disabling components, the simplest fix is arguably to use virtualization to "isolate" the applications that conflict. If you still want the applications on your main SOE (Standard Operating Environment), you could try to use a virtual deployment package (APP-V). This is an application that is basically installed on demand (on launch) and runs "sandboxed" or isolated from other applications on the system.
You can also use a virtual machine via systems such as VMWare or Microsoft Virtual PC to run the problematic application(s) in their own operating system. Often people have admin rights when using virtual machines, but don't on their main SOE system (main workstation). Many developer applications are more effective to use with admin rights, so this solution might be particularly useful when dealing with development teams and their requirements.
5.6: Windows Installer tweaking - (Experts only!).
If the problem is very serious for your desktop environment and none of the options above work, you can try to fix the problem at a Windows Installer level. It might be worth it if the addin (or whatever other software) is crucial to have available on the company's main PC environment.
Essentially what you need to do is remove offending entries from the system cached MSI and/or the registry (disable advertised entry points such as advertised shortcuts, COM registration, file associations, MIME associations or command verbs, etc...).
This is very involved and not good practice to do, and there are some side-effects (for uninstall, resiliency, etc...), but it is the only "last resort" that I know about.
In these cases you would be advised to contact a deployment / Windows Installer expert and have them analyze whether a "fix" is possible. It can work, but don't expect miracles.
If you insist on debugging yourself, you need to get hold of a tool to open cached MSI files on the system (such as Orca, Installshield, Advanced Installer or similar) and you need to "hack" the database - not recommended.
5.7: Windows Installer zapping - (Not safe!).
I am including this "option" for completeness and "historical purposes" if you like. It was never a good option, and is now very unsafe on newer versions of Windows.
MsiZap.exe was a Microsoft SDK tool meant as a last-resort tool for developers to clean out failed MSI installs or uninstalls, it was never intended for widespread use. It allowed the complete "dirty unregistration" of any MSI package. MsiZap.exe is now deprecated, unsupported and unsafe to use. Use only on throwaway virtuals, if at all.
Back in the day a common "system administrator trick" was to use MsiZap.exe to "zap" a whole Windows Installer package from the system. Besides leaving your system incurably dirty, it also removed all self-repair problems for that application.
The junk that is left behind after running MsiZap.exe includes essentially everything (except the actual MSI database registration). All files, all registry entries (including COM), SharedDll ref counters (which really screw up things on reinstall), services, anything really. You will never be able to uninstall properly. In most cases you will fail to install upgraded versions of the same application without side effects. Many people actually see more self-repair problems afterwards when trying to install on top of the dirty state.
Rob Mensching, creator of WiX, Orca and all things Windows Installer has a blog post on the perils of MsiZap. MSDN describes another bad side effect: All program update information is removed when you use the Msizap.exe tool to uninstall a program from a Windows-based computer
6. Summary & conclusion
Step 4 - contacting the vendor for a fix - is the only "real fix" in my opinion.
All other proposals try to deal with the problems that result from vendor errors, rather than provide a lasting solution.
The real-world problem is that many vendors tend to blame each other, so you might be out of luck. And some vendors who do it right, do suffer from the design errors of others.
Proposals 5.1, 5.2, 5.3 are non-complicated "workarounds".
Should be safe to try for everyone.
Proposals 5.2 and 5.3 should be possible to try even without admin rights.
Proposal 5.4 - registration-less COM - is a rather involved, potential "fix".
Developer involvement might be required to find all dependent files to "isolate".
In my experience this is the kind of project that ends up taking days to try out (even with expert help) - without a real guarantee that it will eventually work.
I hear conflicting things from experts, some have succeeded, some say it fails. The people with access to the solution source seem to succeed.
Personally i don't like it for the potential security holes it opens up, and any new file versions to deploy could mean a new round of manifest re-authoring (I believe).
However the COM files in question are so old now that it is rather unlikely that they will see any security updates made to them anyway. I suppose these COM objects are mostly used for .NET interop nowadays.
Proposal 5.5 - virtualization - is a common option these days and should probably be tried before 5.4 if available in the environment. As the saying goes, "virtualize, seriously".
I honestly don't know (lack experience) if virtualization is viable for (office) addins. Please update if you can confirm.
Executables can definitely be virtualized.
Proposal 5.6 - "cached MSI tweaking" - is a "hack" that can work "good enough" when done right by deployment specialists.
There are some "side effects", particularly for uninstall - and also for "resiliency", but these should be manageable if done right.
It is the "real world" - nothing is "clean".
And proposal 5.7 - "zapping MSI" - is an unsafe, deprecated "legacy hack".
There are several side effects due to the system's "dirty state".
Total corruption of the MSI database has been reported after running MsiZap.exe.
There must be problem inside your package.
To find issue.
Clear eventlog - application.
Run your application as user with AdminRigths
Application should run after self-repair. You can run twice, if self repair will not appear,after when you run second time, it's meant that there is problem with component that want to create entry inside MachinePart like HKLM or Programfiles or Windows folder.
Open your eventlog and look for entry with source MSIInstaller.
Entry with warning will give you information what feature and component will cause self repair.
If you can show us here log from that warinig we can tell you more about your problem, but in general message inside eventviewer is clear and says what resource is missing.
Since it happens every time you launch your app (and I assume that you allow the repair to run to completion) the most likely cause is that the app removes something that is "protected" by Windows Installer, such a registry entry or a file. The shortcut initiates the repair mechanism to reinstall the missing item, and the MsiInstaller entry will tell you what it is.
In general, repairs are a good thing because they allow the user to repair the installed product if it's damaged. If, by design, there are resources that are installed but not required to be repaired then set the Component Id to null in your WiX, because that is the documented way to prevent repair of certain files, see ComponentId remarks here:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa368007(v=vs.85).aspx
I am to migrate a Websphere machine (including the applications which run on it) to a new machine. They wanted a clean install of the OS and WebSphere, so I did that. I also took a full file backup of all of the applications they had on the old server. The problem is that to re-install them on the new server, the WebSphere dialog asks me for the JAR/EAR/WAR file, which I don't have.
Is there any reasonably easy way to simply extract the backup of the WebSphere application files I have taken from the old maching, and simply configure the new machine to use them? WAR, etc. is a nice feature to have, but to be forced to use it seems silly.
Edit: The existing WebSphere server is still up and running in production.
Edit: The old server is WAS 3.5, which means it doesn't even have an export function, sadly. Also, the directory where it actually runs the content from has a completely different structure (consisting of like a a %/Web and %/Servlet, where % is the context path of the application). In the "Install" section, it doesn't even mention EAR or WAR, only JAR. I am currently thinking that perhaps the best thing to do might be to just copy the directory over to another WAS 3.5 system and then upgrade that system (and hope it converts the folder structure and updated the config as part of the upgrade).
Edit: The closest thing I have found to a solution so far is this link:
http://www.javazoom.net/services/newsletter/was4.html (though I am not sure if that tool is available or relevant for WAS 7.x).
This has to be a problem other people have run into before, but I can't find a solution anywhere on the WEB.
Thank you!
Here do they have sample Jacl scripts one can use to export/import appserver's configuration. So that is what you can start with. If your new bow uses the same version of WAS (and the same topology if it is not a standalone box) as the old one, it might be a (relatively) safe process.
Migration between different versions of Websphere might be somewhat more tricky, but I'm sure IBM published at least one redbook on that topic.
If you still have the old server running, than just export the apps and you have the war/ear files. However, If you don't know the configuration for the apps, you are screwed. However, I am sure IBM has tools that you can use. Some of the paid tools look even nice and user friendly (at least according to their sales demos). I can't tell you what you need, since I don't know what documentation you have for your apps. But as it looks like there is not much there, otherwise you would just install the application the same way they were installed on your old server and use the binaries (war, ear, jar) that are archived somewhere.