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 o

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.