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

Minor Upgrade COM issue

For years our application has been distributed as a major upgrade.
Management wants to try minor upgrades in anticipation of offering upgrades between major upgrades.

The problem I am having is that a minor upgrade does not seem to remove COM information for the past install. This seems to have the effect of confusing the application and the application errors on startup.

In the registry under HKLM\Software\Classes\CLSID\{guid}\InprocServer32\ there are two different versions represented.
Let's say that I release the application with file version That is listed in the registry.
I then create a minor upgrade to This too is listed in the registry.

How do I get the minor upgrade to remove the reference on upgrade? Is this possible with a minor upgrade. What also confuses me is why the app does not simply pick the right one based on its manifest file? I would assume that the manifest contains the appropriate version.

Thank you.

EDIT: A major upgrade will remove the registry entries correctly. I believe that a minor upgrade will only remove registry entries when they have been added to the remove registry key on a minor upgrade. Of course trying to maintain the remove registry key for minor upgrades would be a futile exercise as every build would have changes.
Labels (1)
0 Kudos
(2) Replies
Level 4

Hi DLee65, hope you see this post

We had the exact same issue, and even opened a ticket with both Microsoft and Flexera to resolve this issue.

Neither Microsoft nor Flexera had a real solution to the issue, namely that MSI minor upgrades do not remove prior COM registration information, resulting in multiple orphaned COM registration entries that crash the application. In house, we call these 'duplicate COM entries'.

As you noted, adding and maintaining all the orphaned registration entries in the remove registry table is not manually feasible, however, it can be automated, not at build time, but at runtime...

The solution I developed involves a Custom Action DLL, built in C# using the Deployment Tools Fondation (DTF). You can get DTF with the WiX SDK, read about it here :

The CA only works if the new COM registration info has been added to the Registry table (ie: use 'COM Extract at build', not 'COM SelfReg').

Here's how it works :

  • For each component marked for installation, retrieve all matching records from the Registry table
  • For each resulting component/Registry record set, determine if any existing registry entries on the PC would become orphaned.
  • Add the orphaned registry entries from the previous step to the Remove Registry table.
  • Let Windows Installer proceed to remove said registry entries...

The tests so far have been conclusive : we don't have any orphaned/duplicate COM registration entries after minor updates. This solution hasn't yet been used in production, but it should be soon. I have limited the scope of the CA DLL to scan only for components installed to our installation folder, so problems could still exist for components deployed to other folders, like Windows\System.

This problem exists since the very beginning of Windows Installer (15 years!), and I have seen many old posts asking about this; so far no one had a better solution than going the major update route.
Honestly, if management had not been so pent up on having minor updates, I would simply have kept the major update solution, like everyone else, but I think my solution is a good one. Maybe I'll put the code up somewhere.
0 Kudos
Level 13

Thank you for the suggestion. It does seem like a workable solution.

I am familiar with the logic because at one point my build process was leaving some registry keys behind because I was attempting to clean a build with an updated version number and so it would never really clean up the registry. So I had to follow the same logic to create a PowerShell script to clean out the registry.

I have not worked with DTF yet, but the process sounds straight forward enough.

0 Kudos