You Again: Understanding Windows Installer (MSI) Self-Repair

When you order pizza delivery, it’s the pizza you want, not the box. In much the same way, an installation program is a means of delivering a deployed product, and not the goal.

The behavior we usually expect from an installation program is for it to run to completion, and then never be seen again. (At least not until uninstallation time, or during manual feature changes or repairs using Add or Remove Programs.) Sometimes, however, an installation program appears to launch itself when an application or document is opened, which can feel like taking a bite of pizza and finding a piece of cardboard in it.

The issue manifests itself by a small installation progress bar appearing when launching an application or opening a file:

The surface cause is that the application was launched by an advertised shortcut (or by opening a file of a type registered by an advertised file association) and the corresponding component’s key path is missing.

Apart from such obvious causes as a user inadvertently deleting a file from an installed product, the deeper cause of the issue can usually be traced back to one of:

  • A feature having been installed as advertised/install on first use/install when required
  • Files inappropriately shared between components, features, or products, which can lead to the resource being uninstalled while a product is still using it
  • A product with per-user data having been installed on a multi-user system by one user and then launched by another user

The general Windows® installer feature is called self-repair or resiliency, and it’s part of Windows Installer’s core functionality. There’s no real way to disable this functionality, either globally or for a particular product, without disabling the Windows Installer service. One way to get the same effect is by creating standard, non-advertised shortcuts in the Shortcuts view and by disabling feature advertisement by setting features’ Advertised setting to “Disallow Advertise”, along with writing file-type and COM data directly in the registry. (A more drastic remedy is avoiding the use of key files, but doing this disables a good deal of Windows Installer functionality that depends on key files.)

To investigate the resource whose absence triggers self-repair, look in the Application section of the system’s event log. Self-repair events are displayed with source “MsiInstaller”.

Viewing that the event properties shows the product code, component code, and specific missing resource.

If this occurs on your build system, you can use InstallShield’s MSI Sleuth utility, introduced with InstallShield 2009 Professional and Premier editions, where you enter a component code and the tool displays the product and publisher name. In MSI Sleuth, select File > Open by Component Code, and paste or enter the component code that appeared in the event log.

When you press Enter, InstallShield MSI Sleuth displays the product or products currently using that component.

Keep in mind that InstallShield MSI Sleuth can display information only about components that were installed using a Windows Installer package, and not resources installed by (for example) a pure InstallScript installer or a batch file. To investigate data installed by an InstallScript installation program, the InstallShield Log File Viewer supports searches, such as for a file name.

Installation programs that run smoothly may not be as good as a slice of cheese pizza (without the cardboard), but at least you have some tips that can help you to avoid this type of behavior in the future.

 

One comment on “You Again: Understanding Windows Installer (MSI) Self-Repair

  1. Colby Ringeisen on   # Reply

    Just adding a common example of one of the causes of this issue identified in the original article…

    A common example case where “a product with per-user data has been installed on a multi-user system by one user and then launched by another user” (the third bullet in the original article) is where an installation developer gets a request to add a shortcut to the program menu that opens a folder location (such as the location where application logs might be created/updated) rather than launches an actual application executable. I frequently get this type of request and usually try to push back (by referencing the MS “best practices” for installing shortcuts), especially in cases where I’m using a “pure” MSI package (no InstallScript) and another requirement to install on WinXP WITHOUT updating MSI to 4.5 exists (so the package is limited to MSI 3.1 and cannot take advantage of the enhanced shortcut features in later versions of MSI).

    I realize that is a pretty narrow set of requirements, but if you are in that boat then watch out for this scenario as adding such a shortcut in an MSI package (and not via a custom action) will always install the shortcut per-user even if the installation is being run per-machine (and result in the behavior described in the article). You’ll usually be able to catch this if you run MSI validation (and you should probably be taken out and shot if you’re releasing an MSI package that doesn’t pass validation), but the MSI validation message displayed in this scenario isn’t as helpful as it could be in identifying this scenario.

Leave a Reply

Your email address will not be published. Required fields are marked *