Self Repair

There are things that probably had good intentions early in its developement but eventually didn't turn out as great as one had hoped. Communism. The DeLorean DMC-12. MSI Self Repair.

An msi normaly register itself into the system during the end of the installation, running actions such as "PublishFeatures". With an msi you don't actually have to install the program, you only need to "publish" it. Some files and registry entries in the msi is set as keys, and if one of those is missing when the program needs it, Windows Installer will perform a Self Repair.

I don't know anyone who has ever published a program instead of installing it. But then again, I don't know that many people.

However, Self Repair has effect even when a program is fully installed, because the keys always have to be present. An msi usually applies source resiliency. In the rare case of an install that becomes corrupt it will try to reinstall the broken feature, but the more common scenario is that a user is launching the program for the first time and files and registry keys that are supposed to be in the user space are missing. When this works, it is ok. Not great, but ok.

This brings us to when it doesn't work, which is probably where a vast majority of people encounter Self Repair:

This was a very common problem during the days of removable media, but thankfully most computers don't even have a CD reader anymore. It's still a problem though, because users don't always have access to the company network, or the cache that used to contain the install has been purged. The latter is typical of an environment running the later versions of Microsoft System Center.

Some deployers seem to think Self Repair is the greatest thing since sliced bread, but it isn't. A proper program does NOT rely on Windows Installer for user files and a proper configured computer does NOT need to constantly repair broken installs.

Worse, many badly authored msi triggers unnecessary and sometimes repeating Self Repairs not only for itself but for features belonging to other, completely unrelated, programs. And for the love of God, don't set key paths to any startup locations! Do you hear me, Citrix?

There are a couple of work-arounds if you want to avoid actually solving the problem. The first and easiest is to create a new shortcut to the offending program and see if it launches correctly. Normally, the repair is triggered when the program is called by its advertised shortcut, a special lnk that goes to a launcher i C:\Windows\Installer. Repair is triggered by more events than launching the advertised shortcut though, so this might not always work.

The cause of the Self Repair should be noted in the Event Viewer in the Application Event log with an ID of 1004, and a quick fix could be to create a dummy file or registry key in place of the one missing.

The most brutal one is to use MsiZap to simply clean all the installer metadata, leaving only the program itself, completely unaware about any published features or components. This is a last resort solution that might cause new problems that are hard to troubleshoot further down the road, try to avoid it!

How to deploy an application that needs data in the user space will be covered, I promise.