2

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:

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.

StayOnTarget
  • 11,743
  • 10
  • 52
  • 81
  • 1
    The first link describes the kind of event log entry you should look for. It will tell you the component that Windows Installer detects as needing repair. It's up to you to figure out why that component needs repair, or to describe it better so we can help. See also http://stackoverflow.com/questions/5501028/how-can-i-determine-what-causes-repeated-windows-installer-self-repair – Michael Urman Aug 24 '16 at 12:04
  • the installer that shows up, is it from your app or from Autodesk/AutoCAD? – Augusto Goncalves Aug 24 '16 at 17:34
  • It is the AutoCAD installer which runs, not our own. Question has been clarified - thanks. – StayOnTarget Aug 24 '16 at 18:06
  • I remember this sort of thing happening ages ago (when I was working on VB6 projects), though in our case it was the Microsoft Office installer. Somehow there was some common library that both the project and Office used, and Windows Installer had to make sure it was "correct" each time. I don't recall ever getting to the bottom of it, though. –  Aug 25 '16 at 12:20

2 Answers2

2

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%).

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:

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.

Alasdair King
  • 106
  • 1
  • 4
1

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.

Community
  • 1
  • 1
Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
  • It looks like our installer does not write those keys; but that is an incredibly useful thing to know. I've added the key bits from the link you referenced just in case it ever disappears in the future. – StayOnTarget Apr 20 '17 at 20:05