How to fix Windows Installer Efforts to Self-Repair

One of the most frequently asked questions on EE in the "Windows Installer" zone is how to eliminate self-triggered installation of some product.  The problem occurs when, suddenly, whenever a certain application is launched, or even when a folder is opened in Windows Explorer, a Windows Installer dialog comes up and begins to reinstall this product, or even another product. Why is this happening, and how do we get rid of it?

What we see here is the feature of Windows Installer called "resiliency". When an MSI-based installation occurs, besides putting in place files and creating registry entries, it also creates certain internal structures in Windows, with information about the required components of the product. After that, whenever such component is activated by any application, Windows first checks to see if the component is intact. If not, it launches a self-repair process, which is what appears on the screen.

A little FAQ on the topic is in order.

Q1: Who decides what components are "required", and what is "intact"?
A1: The author of the installation package. Quite often, he simply follows the wizard in his MSI-authoring product without giving full consideration to what is really required, what is not, what should stay intact and what should not. "Intact" means that the specified file or registry key does exist. The contents of the file or the value of the registry key is allowed to change, so if it is changed, this does not make the installation "not intact".  But if it is deleted, then the installation becomes "not intact".

Q2: Why does Windows Installer repair product A if I launched product B?
A2: Very often, product A installs various hooks in the system, and they are used by all applications, including product B. For example, Adobe Reader installs certain extensions in Windows Explorer, which allows full-text searching in PDF files - i.e. you can search in Windows Explorer for all files containing a certain phrase, and Explorer will be able to find that phrase in PDF files - thanks to the extension installed by Adobe Reader. Another function of the extension is generating thumbnails of PDF files for Windows Explorer. This means that whenever you open a folder in Windows Explorer, Adobe Reader's extension gets activated.  And since Adobe Reader has been installed with resiliency, this means that whenever you open a folder, the system verifies if the Adobe Reader extension is intact. If it's not, then it will launch the self-repair process.

Q3: But why is it launched every time?
A3: Because it either fails to repair, or because it's trying to repair a file that the application itself later removes during its regular operation. Such files should not be included in resiliency, but nothing prevents the author from including them; and if the author’s InstallShield or Wise warns them that a certain component has no resiliency information (by highlighting components with no keypath), the author will often blindly comply and create keypaths, even when in fact they are not required.

Whenever this question is asked on EE, usually the author soon hears the following favorite suggestions:

1. Upgrade Windows Installer to the latest version
2. Repair Installer by running regsvr32 msi.dll
.
3. Use the Windows Installer Cleanup Utility and remove the product that is being repaired.


The correct approach to the problem is in finding exactly what triggers self-repair, and then either taking care of it, or manually removing resiliency information from the system.

Finding out what has triggered the self-repair is usually easy. Open the Application Event log and look for the event 1004 at the time the self-repair was triggered. It will say something like this:


which exactly pinpoints the problem. The next step is, naturally, to verify that myfile.exe exists in the place where it's expected. Sometimes the problem can be overcome by creating that file in that place, with nothing in it - Windows Installer does not store any check sum or anything that would actually verify the consistency of the file; the existence of the file name is the only thing it checks, so any file will do. Of course, this trick assumes that the file is not actually used by the application, but since many installations have numerous files that are never used - add-ons used by the developers, and such - there's a chance that this will work.

The resource mentioned in the event log record can also be registry entry. The remedy, naturally, is to open regedit and create the required key or value.

It is possible however that the application will remove this file or registry entry during its normal operation. Such was the case, for example, with one version of Microsoft Outlook.  This problem can be addressed by either adjusting the permissions on the file or registry key, so when the application tries to remove it, it receives "access denied". If we are lucky, this will not crash it. If this does not work, then the next step is to remove resiliency information from the system. To do that, there are two ways.

If the self-repair is being triggered when we launch a shortcut, we can see if the shortcut is advertised, and if it is, replace advertised shortcut with a regular shortcut to the executable that is being launched.  Usually this can be determined relatively easily; in especially hard cases, Microsoft/Sysinternals Process Monitor or Process Explorer will help to track down the executable being launched, and the command line.

How to tell an advertised shortcut from a regular one? Open its Properties, and if the Target field is greyed out, then it's advertised. To see an example, look at your own shortcut of Microsoft Word.
Here's one prominent example of thoughtless resiliency. The installation of product "Automate", made by NetworkAutomation, creates, among other things, a shortcut for their application under Start Menu/Programs/Startup - and makes it resilient. If the user does not want Automate starting automatically, and removes the shortcut from the Startup menu, then when he runs Automate next time, the system detects the missing shortcut, launches the self-repair process, and restores it. The remedy: either create a fake file automate.lnk under the StartUp menu, launching nothing, or replace their advertised shortcut that you use to launch the program, with a regular shortcut to the executable. Regular shortcuts do not trigger resiliency checking.

Besides the shortcut, a self-repair can be triggered by a file extension or by COM information in the registry. This is a more difficult problem, but it can also be dealt with - for further details on this, check my article "How to disable Installer self-repair for particular product" at http://www.vadimrapp.com/article3.htm . In a nutshell, you will have to find the ProgId in the registry, and remove its so called Darwin Descriptor, which appears as noise, but in fact is an encoded representation of the product feature.  This is how we would have to deal with the self-repair of a product hooked into Windows Explorer, like Adobe Reader which we mentioned above.

Sometimes, however, we won't find event 1004 in the event log, even though a self-repair was triggered, and there are no advertised shortcuts that we touched. An example of this is Microsoft Access, which can trigger the self-repair process even if we launch msaccess.exe. How is this possible? In all cases that we already discussed, the resiliency checking process had been initiated by the system that noticed resiliency information in the registry, but Access initiates self-checking by its own initiative - in which case the system does not create records in the event log. The only way to investigate what's wrong in that case is by looking at the trace of Process Monitor. Fortunately, very few applications are as sinister and self-reliant as MS Access.

Yet another way of fixing a self-repair issue should be also mentioned, highlighted by a recent EE question. Looking at the record in the event log revealed that the name of the allegedly broken feature of Office 2007 was clearly related to a Handwriting recognition component.  Since the user did not in fact need Handwriting, he easily solved the problem by running "Modify" on Office, and uninstalling the Handwriting feature.  If your habit is to install the default full set of all the features (which of course should be condemned), then the probability that you in fact don't need the broken component is significant - and it's even further increased by the fact that the most exotic and useless features of the various products have the highest chance of these issues occurring, resulting in inconsistent installations and self-repairs. In fact, quite paradoxically, if a particular feature constantly needs repairs, then most likely it's not needed at all. I'm wondering, does it only apply to software?