Failure to complete a repair

[jonathanqis]

I have an Installshield MSI project. When installed, I can delete a file from the applications folder, then run the 'repair' option from 'Programs and Features' change item successfully.
The file is recovered and the application now launches.

However,

When I try to invoce the application from 'file explorer' or windows menu, it brings up the 'Preparing to install' dialog and leaves a spinning cursor.
This never completes.
When I have tried to cancel this dialog it does not complete.
I have to kill it with the process manager.

I believe the repair is a windows installer function, but can you tell me why invoking it in different places might make a difference to it's success.

N.B. The install is done from a compressed setup.exe file.
and I cache the extracted msi in the '[CommonAppDataFolder]' folder.

[joshstechnij]

A Windows Installer auto-repair will log two warning events in the Application event log on the machine which can be viewed with Event Viewer. One event contains the component that triggered the repair (the trigger being an advertised entry point: an advertised shortcut, a file extension verb registered through the MSI Extension/Verb tables, or the invokation of a COM CLSID registered through the MSI Class table). The other event will list the component Windows Installer is trying to repair and the resource that it believes is missing from the machine. Both of these components will be contained in the same feature or related by parent feature.

You can also enable the MSI logging policy on the machine to get a verbose MSI log of the auto-repair operation to see if that provides any help in isolating the cause of the hang.

[jonathanqis]

Indeed there are two warning entries generated in the 'Application' section of the EventLog when I try to launch the installed application after removing a file rfom its folder.

1. Detection of product '{4415C927-50F7-45DD-A333-C91902F0DAFC}', feature 'ProcessLink', component '{52FDBBDA-432D-4104-96F0-AC08122B57AB}' failed. The resource 'C:\Program Files (x86)\QiSOFT\Q6\SwmOERP_Exp.dll' does not exist.

2. Detection of product '{4415C927-50F7-45DD-A333-C91902F0DAFC}', feature 'ProcessLink' failed during request for component '{EF2DEBCF-E859-4229-995B-B67A77FAC830}'

The first is as expected, that was the removed file.
However, the second refers to a component (EF2DEBCF-E859-4229-995B-B67A77FAC830) that contains one file, a third party ocx (tx4ole14.ocx).
I have not removed or unregistered this file from the installation folder.

The containing component is referenced just once in a merge module and this module is included in the main installation project. The ocx has no dependencies.

N.B. Running the installed application as an administrator still invokes the repair and it still fails.

N.B. I am tesitng this on a Windows 7 64bit system.

I've attached the properties page for the ocx.

We have previously inserted the same file in the same fashon in a Wise install project and had no problems with the Windows Installer auto-repair functionality.
Indeed we specifically tested it as above.

Are there any other necessary settings for components or ocx files ?

[joshstechnij]

These two event entries indicate the following:
- A request was made to create an instance of some class implemented by tx4ole14.ocx (installed as the keyfile of component {EF2DEBCF-E859-4229-995B-B67A77FAC830}) through some mechanism such as CoCreateInstance. This component is installed by feature ProcessLink.
- Due to the request above, Windows Installer auto-repair iterated through each component in the feature ProcessLink and found the keypath of component {52FDBBDA-432D-4104-96F0-AC08122B57AB} missing (in this case, the file C:\Program Files (x86)\QiSOFT\Q6\SwmOERP_Exp.dll).
- The auto-repair dialog shows up once a resource is determined to be missing and Windows Installer starts a repair operation for the product that installed the missing resource.

While COM Extract at Build and .NET settings appear to be disabled for this component, was the COM data for this OCX extracted in the project by right-clicking the file and selecting 'Extract COM Data for Keyfile' or was the file added through the Component Wizard (and the 'Extract COM Info Immediately option was enabled)? COM data extracted statically in this manner is registered through the MSI Class table, providing an advertised entry point that can trigger auto-repair.

If the above information is not know, go to the Advanced Settings | COM Registration for the component containing tx4ole14.ocx to see if any CLSIDs are listed under COM Classes. If any are there, these will serve as entry points that can trigger auto-repair when any instances of these classes are created through an API such as CoCreateInstance.

Self-registering the file instead of using COM extraction to register the file will eliminate the advertised entry point. The component can also be moved to a hidden, unrelated feature that is always installed to ensure Windows Installer won't find any broken components (though there will be at least one component it will verify) when a class from this OCX is instantiated.

[jonathanqis]

The package was installed on a 64bit Windows 7 machine and the main program starts without incident.

I removed only one file from the installation folder 'C:\Program Files (x86)\QiSOFT\Q6\SwmOERP_Exp.dll'.

I expected it to repair the install simply by recovering that one file, however, it also complained (event log 'Application' entry) about the component containing the file tx4ole14.ocx.

The original (full) installation appears to work when testing components that directly invoke the COM components contained in tx4ole14.ocx.
It is infact a text editing control with associated toolbar, statusbar and ruler.

It appears to work equally well after a repair is invoked from the 'Programs and Features' item in control panel.

The component containing the file tx4ole14.ocx is not marked for 'self registration'. The COM entries were created on adding the file to the merge module.

N.B. I found the component tx4ole.chm did not contain a corresponding .chm file. This has been corrected and tested. It does not change the outcome of the repair.

The ocx component is part of a merge module with it's related files. Don't think moving it to a separate hidden feature is an acceptable option.
We are trying to eliminate self-registration from the installation to best ensure that the installation succeeds (99.999% of the time).

What is still unexplained, is why the repair only fails when invoked from the shortcut to the program from the menu and from invoking the main executable in 'file explorer'.
It would also suggest there is a fundamental difference in what occurs in the repair process depending on where it is invoked from.

[joshstechnij]

A repair from Add/Remove Programs will run the full installation; in this case with an InstallScript MSI project, the InstallScript engine will be running and will drive the MSI portion of the installation.

When auto repair occurs, only MSI is running. This is another unfortunate side-effect of InstallScript MSI projects in that there are disconnects between InstallScript and MSI in a scenario like this (MSI has no knowledge of the InstallScript engine or of needing to run the InstallScript engine). If, for some reason, this project relies on InstallScript (event driven) functionality to successfully install, this could cause an issue.

The best course of action to take at this point would be to enable the MSI logging policy on the machine to get MSI to generate a log file when the repair occurs. The log file may help to isolate what is causing the repair to hang (for example, a custom action that is waiting indefinitely on something). The last lines in a log may should what operation was last run (standard action, custom action, etc.).

One thing to note is that there is nothing wrong with tx4ole14.ocx. It is only serving as an entry point to allowing Windows Installer to run a consistency check on all related components to verify their keypaths are present on the machine. The only damaged component in this repair is {52FDBBDA-432D-4104-96F0-AC08122B57AB}. You can find more information on auto repair in the following articles:
Application Resiliency: Unlock the Hidden Features of Windows Installer - http://msdn.microsoft.com/en-us/library/aa302344.aspx
INFO: Description of Resiliency in Windows Installer - http://support.microsoft.com/kb/290997

[jonathanqis]

I've attached the verbose windows installer log file generated when I attempted a repair in the previously described scenario.
Not a lot to go on 😞

I have tried this scenario on both Windows XP and Windows 7 machines.

N.B. As part of the installation we install Windows Installer 4.5.

Q. Are you aware of any issues that Installshield 12 may have with this version of the windows installer.

I'm wondering now if there may be omissions in the installation tables etc.

Reading the first article you suggested, reminded me of my original note:

N.B. The install is done from a compressed setup.exe file.
and I cache the extracted msi in the '[CommonAppDataFolder]' folder.

Q. Could this be a problem with the windows Installer trying to retrieve the msi from that location (though the article does say it will prompt you for the source media if not found) ?

[joshstechnij]

The following from the log seems somewhat strange:

MSI (c) (08:94) [09:17:23:692]: RunEngine wait timed out
Install server not responding
...
MSI (c) (08:94) [09:18:00:204]: fFatalExit=true

Unfortunately, these messages aren't from our code so we can't provide any explanation as to what would cause these messages to be logged.

Regarding using a compressed setup, if the MSI is cached on the machine there shouldn't be any issues. Just a note though that the install that generated the attached log didn't get anywhere near the point of requiring the MSI package, so source shouldn't be an issue. There also shouldn't be an issue related to the MSI 4.5 engine installation since Windows 7 ships with MSI 5.0 (eliminating the need to install 4.5).

At this point, some basic troubleshooting steps are in order:
- Does this behavior happen on all machines or just some? Does this happen on a clean install of Windows (this is rather important for isolating the cause of unexpected behavior that could be related to something on a machine; just yesterday I tracked down an issue on a customer's machine caused by some Internet activity monitoring software that hooked all CreateProcess calls on the machine and a bug in the hook prevented 64-bit processes from being launched which ultimately blocked InstallScript custom actions from running)?
- If this is happening on all machines, even clean installs of Windows, can you try creating a sample InstallScript MSI project that mimics your project (you can set up auto repair through an advertised shortcut for simplicity) to determine if this might be project specific?

If the issue is project specific, the next step would be to run MSI validation against the built project (this needs to be an uncompressed build) to see if there are any glaring issues with the MSI table data. If this doesn't show anything useful, then removing parts of the project (eventually down to the main EXE, the OCX that triggers repair, and the file you were originally deleting as a repair test) until the issue stops occurring. This should help isolate down to something in the project that might be related to the behavior.

[jonathanqis]

It appears to behave exactly the same on a clean virtual machine running Windows XP.
The install does have three pre-requisite packages including Windows installer 4.5. All three went on without incident during the install.
Thus 4.5 was the installer present on that machine.
On my test Windows 7 machine it is indeed Windows installer 5.0.

Annoyingly there are several web pages refering to the error but so far they all seem to suggest upgrading WI to 4.5 (arrrghhh!)

I've not used the MSI validation in anger yet. I shall take a look at that first.
Then I suspect I shall have to bite the bullet and start doing the cut down testing you suggest. This will be in a few days though as I've been moved onto other issues temporarly. So watch this space !

Thanks.