How to disable Installer self-repair for particular product

Sometimes Installer’s auto-repairing the product becomes anti-productive, and the question “how to disable self-repair for one particular product” can be often seen in various forums.

Here’s how.

Self-repair is triggered by the additional information in the registry, specified along with the ProgID. While the default value says how to call the program, the extra information relates to the Installer’s data about the installed product. This extra information is called Darwin descriptor (named by the original name of Windows Installer – Darwin), and looks like noise in regedit, however with remains of the “original” value. Here’s an example:

Figure 1

 

So, whenever the user is about to Open Word document, Windows will notice this Darwin descriptor and will check if the component it refers to is intact. The name of the feature the component belongs to can be recognized in the “noise”, in this case it’s WORDFiles. Checking if component is intact boils down to checking whether the so called key of the component is the same as it was in the installation. The key may be either file, or registry value. If the file has changed or was removed, or registry value is not found, self-repair will be triggered.

Which means that if we want to avoid repairing this particular component, all we have to do is to remove the Darwin descriptor.

The most difficult part is finding the registry key in question. This search should start from the entry with EventID 1004 in the event log about the missing component that triggered the self-repair. The entry will mention what actually was missing. That’s what needs to be looked for in the registry. Continuing with our example, if we rename winword.exe and then try to open Word file, the following entry will show up in our event log:

Detection of product '{90280409-6000-11D3-8CFE-0050048383C9}', feature 'WORDFiles', component '{8E46FEFA-D973-6294-B305-E968CEDFFCB9}' failed.  The resource 'C:\Program Files\Microsoft Office\Office10\WINWORD.EXE' does not exist.

followed by similar entry with EventID 1001, and then self-repair will be triggered. If for whatever reason we were trying to disable self-repair of Word file association, we would have to find in the registry the above key where winword.exe is mentioned, and remove Darwin descriptor.

Since advertising information is often centered on file associations, there’s also another, less involved way. If we open file association in question in Folder Options / File Types, and simply resave it, Darwin descriptor, of any, will be removed from the extension. In our case:

Figure 2

Once Darwin descriptor is removed, Windows won’t have any reason to check integrity of the product with Installer, so self-repair won’t be triggered.

Of course, one must have good reason to do the above procedure, since it naturally decreases resilience of the product installation. But software developers (or maybe installation builders) often do give enough of these good reasons. The #1 example that comes to mind is installation of Automate from Network Associates, where self-repair is triggered by mere removing their application from Startup folder.