MSI self-repair triggered for the non-admin user when Tabctl32 was installed via merge module

2
votes

One of our applications is VB6 app, which requires Tabctl32.ocx.

So I added "tabctl32.msm" (which contained it with the version 6.1.97.82) to per-machine based Wix. When I ran this per-machine MSI, it installed that OCX and the application worked fine when I as an admin logged in and launched the VB app.

However, if any person with a standard user privileges logged in and launched this VB app for the first time, it triggered an MSI self-repair. Once the self-repair completed for that user, it worked and didn't trigger the self-repair any more for that user. This self-repair didn't occur for the admin users.

When I examined the MSI with Orca, in "ModuleDependency" table, this tabctl32 module had the dependencies with COMCAT msm and OLEAUT32 msm, we installed them with the merge modules as well.

I don't understand why the self-repair doesn't happen for the admin-users but for the standard users?

Can anyone explain what's going on here?

1
vb6wixwindows-installer

1 Answers

3
votes

It may be nothing to do with standard users or admin users or OCXs - it may just be different users.

If there is any resource in the MSI that is owned by a particular user (such as a user-oriented file in Personal folders or others, or registry entry in HKCU) then the first install will install all of these for the installing user.

If another user logs in and uses the app (installed per machine, hopefully) then repair triggers (such as using a shortcut) will notice that these user items are missing for this particular user and will install them. This should happen only once - it the repair happens repeatedly for the same user then it's something more serious.

In any case, the application event log should have an MsiInstaller log entry with some data about the product and the missing component.

This may also depend on the VB6 app - it's old, has no manifest, and so may be interacting with UAC in strange ways. For example, if its behavior is virtualized to use a \VirtualStore location for the system folder then it may well need to reinstall the tab control into that virtualized system folder. Admin users wouldn't have the same issue.