"Stop Installation Idiocy" PCWorld's Hassle Free PC article

  • Article

While searching for news with "Windows Installer" in the subject, I recently came across the Hassle Free PC article Hassle-Free PC: Fix Stubborn Windows Install Errors where a reader asked for assistance with the Windows Installer dialogs under the subheading “Stop Installation Idiocy”. I thought I'd offer some deeper context on this scenario.

First, if this dialog happens during First Run of the application, this can be by design. Windows Installer encourages application to write their “user data” at first run of the application. This is particularly useful for applications that install to machines that will have multiple users such as home machines with Fast User Switching enabled or to business machines that multiple people will use.

Second, if the application is installing something “on demand”, this too can be by design. This Installation-On-Demand can be useful for a number of design reasons, particularly when an application has a feature that is less frequently. As a hypothetical, let’s say Word studied it’s features and discovered that Mail Merge was used quite infrequently save for holiday greetings times. The Office deployment developers could choose to expose the Mail Merge option on the menu but leave it on the CD until the user actually invoked it. At the point the user invoked Mail Merge, Word could recognize the bits were not installed and then call to the installation package (MSI) and ask for them to be installed. Given all this happens within the application context, the application can wait for the install to complete then load the functionality without the user ever having to leave their context. Admittedly, if a user is not aware that this is possible, this can be disorienting.

Third, if the application state has become inconsistent, this too can be by design. The Resiliency features of the Windows Installer are designed to both detect when an application is out of specification as well as provide actions to put the application back into compliance with the specification. From one point of view, one could say this is the Windows Installer way of addressing DLL Hell. Window Installer will be provide the file each application expects even if they are the same file path and file name. The only way to do this “correctly” is to swap the files out per application context. There are of course other solutions to DLL Hell from Microsoft including the Fusion technology and the Virtual Machine offerings each with it’s own strengths and weaknesses.

Though there are a number of by design cases for the Windows Installer dialogs occurring during application execution, there is the occasional break such as you cite in your article. A sophisticated user can differentiate these cases by following the FAQ entry Every time I launch my application, Windows Installer performs an installation. How can I determine the cause of the on-demand installation? That FAQ item reads as follows

Q. Every time I launch my application, Windows Installer performs an installation. How can I determine the cause of the on-demand installation?
A. An easy way to determine the cause of an on-demand installation is to look in the application event log for MsiInstaller log messages of the form:

 Event Type: Warning
Event Source: MsiInstaller
Event ID: 1001
Description:
Detection of product '{000C1109-0000-0000-C000-000000000046}', feature 'Example' failed during request for component '{00030829-0000-0000-C000-000000000046}'
Event Type: Warning
Event Source: MsiInstaller
Event ID: 1004
Description:
Detection of product '{000C1109-0000-0000-C000-000000000046}', feature 'Example', component '{00030829-0000-0000-C000-000000000046}' failed. The resource 'C:\Progam Files\example\example.exe' does not exist.

The first message (with event ID 1001) states which component was being installed. The component listed here is the component named in the Component_ column of the Shortcut table for the particular shortcut.

The second message (with event ID 1004) indicates which component failed detection. Improved event logging in Windows Installer 2.0 has updated the message so that in most cases, the message identifies the actual resource that resulted in the failed detection. The component with the missing or damaged keypath is the component that is triggering the reinstallation.

In the example above, the reinstallation is triggered because the resource 'c:\Program Files\example\example.exe' does not exist. You would then need to find out why the keypath does not exist—in this case, the user deleted it.

[Author: Robert Flaming]

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at https://www.microsoft.com/info/cpyright.htm.