Retracing faulty Registry key entry

[dariom]

We have recently migrated an older IS project (build with InstallShield 12) to InstallShield 2020 RC1. The actual installation after the migration works fine but we're having an issue during uninstallation. Specifically, it seems that the installer is attempting to remove the entire "HKEY_LOCAL_MACHINE\SOFTWARE\" subkey for some reason. Here an excerpt from the install log:

MSI (s) (A4:CC) [11:29:52:948]: Executing op: RegOpenKey(Root=-2147483646,Key=Software,,BinaryType=0,,)
MSI (s) (A4:CC) [11:29:52:948]: Executing op: RegRemoveKey()
RemoveRegistryValues: Key: \Software, Name: 
MSI (s) (A4:CC) [11:29:53:104]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE32\Software\Microsoft\EAPSIMMethods\18\FastReauthContext 3: 5 
Info 2835.The control ErrorIcon was not found on dialog SetupError.
Error 1402.Could not open key: HKEY_LOCAL_MACHINE32\Software\Microsoft\EAPSIMMethods\18\FastReauthContext. System error 5. Verify that you have sufficient access to that key, or contact your support personnel.
MSI (s) (A4:CC) [11:30:05:198]: Product: EVOware 2.8 Service Pack 4 -- Error 1402.Could not open key: HKEY_LOCAL_MACHINE32\Software\Microsoft\EAPSIMMethods\18\FastReauthContext. System error 5. Verify that you have sufficient access to that key, or contact your support personnel.

This of course fails, because some of the subkeys seem to be protected (in this case, the "FastReauthContext" key).

To retrace it, I opened both the pre-migration and post-migration MSI in Orca and I indeed found corresponding entries in the Registry table that access the "Software" subkey, although they did have one key difference: In the pre-migration installer the "Name" column was "+", in the post-migration installer it is "*" which does explain, why it is attempting to delete the "Software" subkey. However, I am confused why the migration would even change that in the first place.

But be that as it may, now to the part that I can't figure out: In both versions of the installer, the registry entry is associated with the same Component according to Orca. However, when I look at that component in the migrated InstallShield project in the InstallShield editor, it does not have any associated registry entries at all.

Also, the registry entries in both versions of the installer have different Registry identifiers. From what I can tell, for most other entries in the Registry table, the Registry identifiers have not been changed in the migration. If I open the IS project file in notepad, I cannot seem to find either of the Registry identifiers in it either.

Any ideas on how to track this registry entry down in the InstallShield editor to fix it? I don't want to have to patch the installer via Orca or anything like that.

[dariom]

UPDATE: The registry entry seems to stem from an external *.reg file that is associated with the Component via the "REG File to Merge At Build" setting. However, that REG file hasn't changed during the migration. Has InstallShield changed the way, registry entries from *.reg files are interpreted / processed? The registry entry in question in the *.reg file looks like this:

[HKEY_LOCAL_MACHINE\Software]

With just an empty line underneath, then the next entry is listed. Can I make any changes here that tell InstallShield to create the entry if it doesnt exist but not delete it on uninstall (i.e. Registry Name="+" instead of Name="*")?

Alternatively I will try to just delete that entry, as the "Software" key should always exist anyways. But this behavior is quite strange.