Self-Repair, Simple & Short Explanation: Why does the MSI installer reconfigure if I delete a file?
Alternative Answer Available
UPDATE:
There is a shorter, more "solution focused" answer available, perhaps try it first. This answer focuses on "understanding self-repair" rather than explaining the steps to take to eliminate the problem. You might want to read the first section of this answer as well.
Unexpected Windows Installer self-repair issues - Quick Fix?
This "article" has gotten large and somewhat unreadable. Here is a newly written preamble - the short "workaround version" for fixing unexpected self-repair (often found in VB6, Visual Studio, MS Office, MS Outlook, AutoCAD, etc...)
- If you experience unexpected self-repair, the first thing you can try is to manually create a desktop shortcut directly to the application executable you are launching when the problem occurs. This bypasses the most common trigger of self-repair, "the advertised shortcut". If this works your problem is "solved" (or avoided). Here is a quick, fleshed-out explanation
- If the problem still occurs, or your problem is related to the loading of an MS Office, MS Outlook add-in or similar (that you can't launch via a shortcut), then you most likely have a COM registration conflict on your system, and the fix is much more involved. The easiest to try is to disable any addins you don't need in the addins dialog of the application in question and see if this makes the problem go away
- If you still see problems, then you most often need to debug a genuine COM registration conflict (or conflicting file/MIME associations, or command verbs). This normally involves (at least) two conflicting applications on your system that "fight it out" updating the registry on each launch after the other application has run (always launching one of the apps will not trigger the self-repair - the conflict surfaces when you alternate between applications). It is also possible that permission problems cause the same application to fail to update the system and it keeps trying endlessly by repeatedly running self-repair. And there are further possibilities, more details below
- The "real fix" is to contact both application vendors and ask them for a fix for the problem (since a fix often requires a fix of both vendor MSIs), but in my experience this is rarely successful. Do try it out though - since this is the way to help everyone with a long-standing annoyance! I have personally provided a setup with fixes for a bank deployment and was very happy to have the problem solved in my package
- To debug yourself, you need to get hold of a tool to open cached MSI files on the system and you need to "hack" the database - a very involved task requiring expert skills, you would be advised to seek an installation expert for help if the problem is very serious for your desktop environment. It can work, but don't expect miracles.
- Please see the section below called "Finding the trigger or culprit for the self-repair" for more details on obtaining a tool to view and modify MSI files
The rest of the "article" describes self-repair problems in depth. There are many other potential causes of self-repair than what is described in this "short" section.
Overall Problem: Developer debugging and self-repair
Windows Installer is a deployment technology, its job is to install the specified files and registry settings and keep them in the specified install locations and to ensure they are the right versions - self-repair or resiliency is a mechanism to that end. Its operation conflicts with a developers need to exchange files on the fly for debugging, development and testing.
Accordingly, many self-repairs (resiliency) are triggered simply by developers trying to debug their installed application and hot-swapping files on the fly. See section 2 in "Some typical self-repair problem scenarios" below for how to handle this. In other cases there are genuine design errors in the MSI that must be corrected or system administration pitfalls that lead into self-repair - and at times the error source can be hard to find.
I have written about the issue of self-repair in an answer on serverfault.com. Slightly different words intended for system administrators, and reading it now it might be a more accessible explanation than this long one (intended for developers). There is also another, shorter answer here on stackoverflow: Why does the MSI installer reconfigure if I delete a file? (this is probably the shortest one and easiest to understand). And finally I found a very nice article on self-repair by Vadim Rapp: How to fix Windows Installer Efforts to Self-Repair. This article is well worth a read.
No self-repair will occur if Windows Installer determines that the product being launched is properly installed. When self-repair occurs something needs to be changed on the system for the application to run properly.
The Primary Causes of Self-Repair
The details are presented below in the section "Some typical self-repair problem scenarios", but as a quick, foreshadowing list - the primary causes are:
1. Badly packaged corporate MSI files or MSI design flaws from the vendor (the MSI package itself is badly designed and triggers self-repair unexpectedly for a variety of reasons)
- Excessive or erroneous use of per-user files or per-user registry keys often with erroneous key paths set into the user profile (instead of HKCU). See section 5 below for more details (and a color illustration of such a situation)
- Package interference from erroneous COM server registration (particularly VB6 COM files or VBA files and libraries from products such as AutoCAD from Autodesk, and similar products).
- Two MSI packages register the same COM file (ActiveX/OCX) from two different locations and "self-repair fight" on each application launch to keep their version correctly registered.
- The last application to launch puts the registry right for itself, and it lasts until the other application is launched and does the same. Once you alternate between applications the problem occurs. See section 7 below for a lot more VB / COM self-repair detail
- A component key path is set to an empty folder that Windows installer removes on self-repair (triggering an endless loop of removal and subsequent self-repair)
- ACL lockdown permission problems (logged on user can not access key file and Windows Installer triggers repair repeatedly). This can also be caused by ACL changes done externally, but is often done by the MSI itself
- Here is a serverfault.com work-in-progress describing common MSI design flaws
2. Files or registry keys are deleted by interference from external causes ranging from (logon) scripts to standard OS features, viruses, security software, etc...
- Temporary files are deleted automatically by Windows after being erroneously installed to the temp folder by an MSI package
- Interference from bad logon- and trigger happy cleanup scripts and cleanup applications
- Antivirus applications blocking or deleting files or registry keys so that Windows Installer can no longer detect or access them
- Computer viruses changing or deleting files and registry settings
- Overactive computer tinkerers and users delete files and settings they don't understand
3. Windows design changes, flaws or restrictions that causes flawed or problematic deployment
- An AD-advertised MSI package fails to install (might be cancelled since it takes too long to install) and keeps bugging people. This is strictly speaking not self-repair but an advertised install that is aborted, but the result is the same: endless reinstall
- Terminal server complications. Self-repair is generally disabled altogether on terminal servers. This does not normally cause self-repair problems, but application installs without the required per-user files or registry keys that can be added via benign use of self-repair (read below). The user files and user registry keys are then just missing and problems result
- UAC interference, certificate validation failure and other problems resulting from Windows design changes. For every version of Windows security features like these are added and normally end up adding new obstacles for reliable deployment
- Even certain Windows Updates (updates, security updates, hotfixes, etc...) can make drastic changes to how security is enforced for MSI packages, and hence cause extremely problematic behavior
- Though this relates to MSI creation, and not primarily their end-user use, the Windows Update KB3004394 which updates the way Windows checks for revoked root certificates, breaks older version of Installshield's command line build (for setups that were digitally signed). Largely a resolved issue by now, but an illustration of how Microsoft keeps changing core MSI functionality
- In a similar manner Installshield crashed for many users after installing Microsoft update MS14-037 “Security update for Internet Explorer versions 6, 7, 8, 9, 10, and 11” (KB2962872)
- An extremely problematic change in Windows Installer base functionality occurred after installing kb2918614 (Vista). Suddenly administrator credentials were required for a simple MSI repair operation. This defeated a core benefit of MSI altogether: the abili
