Diagnosing self-healing MSI

Question

The app I work on is written mainly in VB6.

Some users report that when they start up my app a different MSI installer will automatically run and try to repair its own installation. Often this is for AutoCAD but sometimes other programs also.

Usually this occurs every time they start the app.

What is a procedure that we can use to diagnose why this occurs? Since it is a third-party's installer which is running we don't have any visibility into what it is doing.

AutoDesk does have some info published on this:

• Unexpected installer launches
• Windows Installer displayed unexpectedly

but these do not directly provide enough information. Ideally I want to be able to completely prevent this from occurring to my end users, rather than just telling them how to avoid it or clean it up.

Answer 1

Your installer is acting on a directory, file or registry key that Windows Installer knows is part of the AutoCad installation.

First, I would turn on global Windows Installer logging. This means that any Windows Installer activity - including AutoCad's installer - is written to an external log file (in %temp%).

• How to Enable Windows Installer Logging

Next, run your installer, and let the AutoCad installer run.

Now go to %temp% and you should find files MSIXXXX.LOG - one for your installer, one for AutoCad. Open these and you can work your way through them and identify which file or registry key the AutoCad MSI find is missing or changed.

You may find WiLogUtl.exe helpful for this:

• Wilogutl.exe

With any luck you will identify that the directory, file or registry key triggering autorepair is also in your installer. If you're really in luck you can identify it as an item you should not be installing anyway - perhaps you are referencing a system component that would be present anyway, something protected by Windows File Protection.

If not, you will have to look at something like RegFree COM to move files out of shared directories into your private directory and reduce registry conflicts. Also, if you are using (consuming) the Visual C++ Runtime MSMs to make your MSI, consider using the Microsoft EXE installer instead or (best of all) placing the DLLs directly in your program folder, since I've found that the MSMs can cause just this sort of problem.

Answer 2

With regards to Peter Cooper Jr's comment on VB6 causing self-repair. Please check out the heat.exe documentation for Wix. You will see that there is a special switch the tool supports to suppress extracting certain registry values that are owned by the VB6 runtime itself (and hence shouldn't be messed with or updated by any other MSI): http://wixtoolset.org/documentation/manual/v3/overview/heat.html

Go down the list to the switch -svb6 and read the description to the right. (Reproduced here:)

When registering a COM component created in VB6 it adds registry entries that are part of the VB6 runtime component:

• CLSID{D5DE8D20-5BB8-11D1-A1E3-00A0C90F2731}
• Typelib{EA544A21-C82D-11D1-A3E4-00A0C90AEA82}
• Typelib{000204EF-0000-0000-C000-000000000046}

[as well as] Any Interfaces that reference these two type libraries

Does your installer write to these keys? If so try to exclude them - this is good to do even if it isn't the culprit in this particular case.

Other than that there is a lengthy description of what can cause Windows Installer self-repair here: How can I determine what causes repeated Windows Installer self-repair?. It is a long article because there are so many different ways self-repair can occur. The common denominator is that different installers on your system are fighting over a shared setting that they keep updating with their own values on each application launch in an endless loop.