1

I have an installer package for a 32-bit Application (built with MakeMsi, originally for Windows XP, and simplicisticly maintained since then), that fails registering a COM server on modern (64-bit) Windows systems (7, 8, 10). This is what I see when trying to install my MSI normally:

Screenshot of COM registration error

Application Error

Exception EOleSysError in module xyz at 000F0B01. Error accessing the OLE registry.

If I bring the MSI in compatibility mode Previous version of Windows, the COM server registers successfully. Since "it's working" somehow, I didn't invest much time in exploring the reasons so far. But finally, I'm exhausted to remember our customers (and sometimes also me) again and again of this precondition, so I wish to fix this issue.

The registration (and de-registration) is done via CustomActions, as I see looking into it using Orca:

"[INSTALLDIR.MYAPP]\placeholder.exe" -regserver
"[INSTALLDIR.MYAPP]\placeholder.exe" -unregserver

For each of those entries, Type is 1122 and Source is INSTALLDIR.MYAPP.

I could imagine that the COM server is started with insufficient privileges in the installation procedure, but aren't installers run automatically with administrator rights? I mean, when I (as a standard user) start the installer by double-clicking it, it shows the UAC prompt before the actual installation takes place. Why are the COM servers not run with elevated rights for their registration and de-registration? It's confusing...

How should I change my MSI to make Windows installer process it successfully?

Community
  • 1
  • 1
Wolf
  • 9,679
  • 7
  • 62
  • 108

2 Answers2

2

I assume you know that the problem is in the executable that you're running as a custom action, not anything in Windows Installer. That means the issue will be the code in the executable, and it's probably old and incompatible with later OS versions. You'll need to look at the code to see what it's doing that is unsupported.

Many installs don't bother with self-registration. That data is all static data that can be extracted once and included in the MSI file in registry entries and other COM class tables. This means that there is no need to run code at all during the install.

PhilDW
  • 20,260
  • 1
  • 18
  • 28
  • 1
    In fact, self-registration is highly discouraged in MSI packages for a boatload of reason (read https://msdn.microsoft.com/en-us/library/windows/desktop/aa371608.aspx). I've only used it when I've had no other choice (a couple of extremely ancient 3rd-party OCX controls that furiously resisted my attempts at determining what keys they wrote in the registry) – Euro Micelli Aug 04 '16 at 04:31
  • After writing the question, I stumbled across an article that stated exactly this: [*`Using self registration is very strongly discouraged by Microsoft and should be avoided at all costs.`*](https://www.firegiant.com/wix/tutorial/com-expression-syntax-miscellanea/components-of-a-different-color/) Now I'm sure this is the problem I have. Have you any thoughts about how to get the registry entries for a COM server (exe) that is not part of a VS solution? I mean, beyond diffing the registry before and after in-vitro self-registration? – Wolf Aug 04 '16 at 05:56
  • Concerning *`the problem is in the executable`*: I think it's most probably correct what this executable does, but the privileges don't fit. If I start an exe for self-registration, I have to do that with admin rights. (Of course I accept that that self-registration isn't the right choice when installing.) – Wolf Aug 04 '16 at 06:03
  • Since I found a fast solution that is directly applicable to my actual problem, I better move the accept mark. Thanks anyway for helping with your answer, that is obviously "the right one" :) ...but I have to cope with a completely different (and of course somewhat outdated) toolset, so I chose the fast solution this time... (or let's have a look what happens in the next 23h) – Wolf Aug 04 '16 at 10:00
0

After learning how to register COM servers the right way, I still was interested to understand, why my MSI package worked before. In other words: what is the crucial change after Windows XP?
...I meanwhile also checked that the MSI works when I run it as an administrator...

As I figured out reading the WiX toolset documentation, there is an attribute Impersonate for CustomAction that controls if the CA is executed with elevated privileges:

This attribute specifies whether the Windows Installer, which executes as LocalSystem, should impersonate the user context of the installing user when executing this custom action. Typically the value should be 'yes', except when the custom action needs elevated privileges to apply changes to the machine.

It refers to the msidbCustomActionTypeNoImpersonateflag in the Type field of the CustomAction Table. The value 1122 I observed in my MSI is decompiled into this:

What I used to "fix" the problem the fast way is, enable the msidbCustomActionTypeNoImpersonate flag (2048) in the CA type (in WiX this would be Impersonate="no").

Translated into my MakeMsi script, I had to use the System attribute in the Type of the ExeCa command as to make self registration work as before:

Type="Deferred Sync AnyRc System"

I'm fully aware that this is only a workaround, since running a COM server for (un-)register is dangerous. And so the solution mentioned in the second section of PhilDWs answer should be preferred: manage COM related static information via registry entries in the MSI. But sometimes you need a fast solution, and sometimes there is no other option, see Euro Micellis comment.

Community
  • 1
  • 1
Wolf
  • 9,679
  • 7
  • 62
  • 108