Showing results for 
Show  only  | Search instead for 
Did you mean: 
Level 10

COM Extract at Build not working if DLL is not registered on build server

Hi there,

I am working on a Basic MSI project with IS 2012 Spring.
Our installation package must install a COM DLL on the target PC and register it.
So until recently I only set the "COM Extract at Build" to "Yes" and it did its magic. It extracted the corresponding COM entries in the Registry table, and the installed application ran smoothly.

But we recently upgraded our build servers, and we have got one that we have never used to actually build our application. Its only purpose it to build the installation package with IS 2012 Spring Standalone Build. So, the COM DLL has never been registered on this server.

We found out that the "COM Extract at Build" does not properly extract all the entries to the Registry table when building the installation package on this server. Some entries are missing, while other contain some wrong GUID's.
If we build the installation package on a server where the DLL was registered, all the COM info is correctly extracted.

So, here are my questions:

  • Is that a known issue?
  • Is there a way to make this work without registering the DLL on the build server?
  • I thought of setting the DLL file to self-register, but it doesn't work. It displays an error message "Error 1904. Module C:\Program Files (x86)\My Company\My Product\MyCOM.dll failed to register. HRESULT -2147220473. Contact your support personnel.".
    If I register the DLL by hand with regsvr32, it works fine.

    • How does Self-Reg differ from regsvr32?

Labels (1)
0 Kudos
(5) Replies
Level 5

0 Kudos
Level 10

Hi there,

Thanks for the link Marek22! I did a few tries with the UseAPIRegistryHooks registry value, and it helped to point me in the right direction.

So, it took me a very long time to nail that one down. With the help of Tech Support, I finally managed to isolate the problem by following this procedure (in a VM)

  • Install Windows 7 x64
  • Install Visual Studio 2010 and its SP1, but do not start Visual Studio yet.
  • Install InstallShield 2012 Spring with its SP1
  • Build the affected MSI package --> The COM extraction works fine.
    Start Visual Studio. When started for the first time, it asks what sort of project it will mostly be used for (Choose your default environment settings). In my case, I usually choose Visual C++ Development Settings.
    Then Visual Studio loads the user settings.
  • Build the affected MSI package --> The COM extraction is erroneous.

From there, I analyzed what happened in the Registry when starting Visual Studio for the first time. When starting VS (not launching it as Administrator), it creates some user-specific registry entries under the following keys:

  • [HKEY_CURRENT_USER\Software\Classes\Interface]
  • [HKEY_CURRENT_USER\Software\Classes\TypeLib]
  • [HKEY_CURRENT_USER\Software\Classes\Wow6432Node]

Once these entries exist, the COM extraction at build no longer works in the same way, and the resulting Registry table is erroneous.
If you delete (or rename) the above registry keys, the COM extraction at build works fine again.

So, it looks like a bug in InstallShield 2012 Spring SP1 to me.
And it has nothing to do with registering my COM server on my development machine. I could register or unregister my COM server on my machine, the COM extraction was still erroneous.
So the title of this thread is a bit misleading...

Funnily enough, this issue seems to be fixed in InstallShield 2013 SP1.

What I would still like to know is:

  • Was that a known issue in IS 2012 Spring SP1?
  • Is there a hotfix available?
0 Kudos
Level 10 Flexeran
Level 10 Flexeran

There was an issue with the newer style kernel mode COM extraction in IS 2012 that would cause COM data to be extracted incorrectly if any keys were present under the Wow6432Node key in HKCU\Software\Classes. The issue was reported in work order IOA-000066199 as a failure to correctly extract proxy/stub related information.

No hotfix was made available for IS 2012. However, it should be possible to copy the kernel filter drivers from IS 2013 into the System folder for IS 2012 (ISRegFlt.sys and ISRegFlt64.sys from \Program Files\InstallShield\2013\System; it may be necessary to reboot the machine after copying the files to ensure they are reloaded if COM extraction was already used). The code changes were self contained to the registry filter code in the drivers so no other files should be needed. Please note, however, that we have not tested using the IS 2013 filter binaries with IS 2012.
0 Kudos
Level 10 Flexeran
Level 10 Flexeran

As a follow up to my previous reply, using the registry filter driver binaries from IS 2013 may not work correctly. One reason no hotfix was made available for this issue in IS 2012 is there are a number of other changes included in the driver, including changes to how multiple concurrent build processes are handled. How the registry filter driver listens for COM extraction requests changed between IS 2012 and IS 2013 as part of these changes.

While attempting to use the IS 2013 driver binaries with IS 2012 should not cause any adverse effects, it is possible that no COM information will be extracted. As such, we would either recommend migrating to IS 2013 if possible, or, change the COM extraction method in use as highlighted in the COM extraction whitepaper previously mentioned.
0 Kudos
Level 10

Hi Josh,

Thanks a lot for your answer!
I wish the support technician had escalated the corresponding incident to you. It would have saved me a long time finding a way to isolate this bug.

But there is something I have missed there: according to the release notes of IS 2012 Spring SP1, this bug should have been resolved in the version I'm using.
0 Kudos