2

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?

Petronius
  • 428
  • 4
  • 12

1 Answers1

3

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.

PhilDW
  • 20,260
  • 1
  • 18
  • 28
  • You are very close. In fact, the event viewer has two entries: Detection of product ' {A958E33B-5EC8-45C7-B1E0-661D0D7AD318}', feature 'ThisFeature', component '{1CD44446-251F-40CC-B158-717060F8A3B6}' failed. The resource 'HKEY_CURRENT_USER(64)\Software\Company\InstalledMyAppShortcuts' does not exist. Detection of product '{A958E33B-5EC8-45C7-B1E0-661D0D7AD318} ', feature 'ThisFeature' failed during request for component ' {FC3E0B6A-F62B-11D1-B144-00C04F990B2B} – Petronius Jan 04 '17 at 18:59
  • But the shortcut reg key doesn't exist for any user because it is HKCU specific. And "{FC3E0B6A-F62B-11D1-B144-00C04F990B2B}" is a GUID for Tabctl32.ocx. If I install Tabctl32.ocx as a loose file instead of the merge module, the self-repair doesn't occur. That means, I know for sure the shortcut is not the culprit. – Petronius Jan 04 '17 at 19:04
  • Not sure what this means: "the shortcut reg key doesn't exist for any user because it is HKCU specific" because the per machine install will install it for the installing user but not for other users. There isn't enough info in your post about key files/registry entries, or which components are in the feature because the entire containing feature is repaired, not just the component. – PhilDW Jan 05 '17 at 21:28
  • @Petronius: VB6 deployment has always been problematic and riddled with weird problems - usually [self-repair related](https://stackoverflow.com/questions/5501028/how-can-i-determine-what-causes-repeated-windows-installer-self-repair). This certainly looks like per-user data that is needed for the COM control. There are several other common VB6 deployment problems, and I may get around to updating the linked article with a VB6 section. – Stein Åsmul Aug 03 '17 at 23:54