UninstallString written to wrong registry location on Win764

[jsmith]

The first thing I do in the MSIcode for my setup project for 64 bit OSes is:

Code: Select all

Set x64 - Native 64 bit Windows, AMD64 and EM64T Architectures - installation mode

My application is a true 64-bit application, and the above line of MSIcode makes it so registry values go to the right place, namely HKLM\SOFTWARE and not HKLM\SOFTWARE\Wow6432Node.

However, I just found that my upgrades fail on Win7/64. On upgrades, we need to get the UninstallString out of:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{product-code}

The problem is that there is no UninstallString value in that key on Win7/64. I searched the registry and found that it is being written to:

HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{product-code}

The only values in that key are "UninstallString" and "(Default)". All the other values typically in the Uninstall key are where I'd expect them to be - in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{product-code}.

Why is this info being written to the Wow6432Node key when I'm installing a 64-bit app after having called "Set x64" in my MSIcode? Is there any way to stop this happening and have all the registry keys go to the correct place? I can alter my MSIcode to work around this by checking for the UninstallString in Wow6432Node, but I feel I shouldn't have to. Is there a way to avoid this workaround?

Thanks!

[jsmith]

Quite related to this problem is that what gets writen to:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\$TITLE$

on 32-bit systems is getting written to

HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\$TITLE$

on Win7/64, despite my setting "Set x64" on the first line of my MSIcode.

The problem caused by this is that we write NoModify, NoRepair, and NoRemove values to HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\$TITLE$ to stop users altering our product from within the ARP applet. Unfortunately, that isn't working on Win7/64 because it looks like ARP is looking in the Wow6432Node key for these values for our product. I can work around this on 64 bit OSes by writing these values to the Wow6432 node, but again I feel I shouldn't have to. For some reason, when I install my product all of the following are created and paritally populated:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\$TITLE$
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{product-code}
HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\$TITLE$
HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{product-code}

This seems to be wrong. There should be entries either in HKLM\SOFTWARE or in HKLM\SOFTWARE\Wow6432Node, but not in both. And since I called "Set x64," they should all be in HKLM\SOFTWARE and not in HKLM\SOFTWARE\Wow6432Mode.

[mills]

I created a test project (called 'registry64'). It contains only the code:

Code: Select all

Set x64 - Native 64 bit Windows, AMD64 and EM64T Architectures - installation mode
Write Registry Key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\$TITLE$\test, test
Apply Install
MessageBox: done, wrote to registry

And the results are as follows:

The key that was written (above) appeared in:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\registry64

The following keys were generated in:
HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\registry64

Comments
Contact
DiplsayIcon
DisplayName
DisplayVersion
HelpLink
InstallLocation
ModifyPath
Publisher
UninstallString
URLUpdateInfo
VersionMajor
VersionMinor

I'm not sure if those entries that are appear in the Wow6432Mode path can be modified, since the IA installer is itself a 32-bit application, but I will notify our developers in any case.

[mills]

One thing I need to clarify is your comment:

The problem caused by this is that we write NoModify, NoRepair, and NoRemove values to HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\$TITLE$ to stop users altering our product from within the ARP applet. Unfortunately, that isn't working on Win7/64 because it looks like ARP is looking in the Wow6432Node key for these values for our product.

I wasn't sure what you meant by "ARP applet", so correct me if I'm wrong, but I think you mean add/remove programs, right?

If that's the case, it should look in both the "normal/64-bit" registry path and the Wow6432Node path for installed applications.

Let me see if it's possible that all of the values could be placed in the 64-bit path with a 32-bit installer.

[jsmith]

Thanks for the reply, Andy. Yes, by ARP applet I meant the "Add or Remove Programs" control panel applet.

I'm not sure if those entries that are appear in the Wow6432Mode path can be modified, since the IA installer is itself a 32-bit application, but I will notify our developers in any case.

This is likely the problem, but it would be nice to know if it's possible to have no entries go to Wow6432Node on 64 bit Windows.

If that's the case, it should look in both the "normal/64-bit" registry path and the Wow6432Node path for installed applications.

The Change/Repair/Uninstall options did not disappear from APR until I explicitly wrote NoModify, NoRepair, and NoRemove to the Wow6432Mode version of the key. When they were in the normal location for the key, these reg values had no effect.

[mills]

The most important question at this point is whether you intend to distribute and allow simultaneous installations of both 32 and 64 bit applications.

If only 64-bit, then your best bet for the short-term is to, while in 64-bit mode, write the registry keys you want to affect ARP to HKLM/SOFTWARE/Wow6432Node/...

There doesn't seem to be a way to work around this at the time. For instance, I tried creating an installer that copies all of the entries from Wow6432Node to their 64-bit equivalent locations and then deleted the Wow6432Node entries.

While the program was listed in ARP, there were definite side-effects and I couldn't seem to be able to get the program installed or to recognize its sources.

[jsmith]

Thanks for following up, Andy. I've already implemented this workaround and it works fine. For example, I handle NoRemove et al thusly:

Code: Select all

[compiler if Variable PLATFORM Equals (Ignore Case) x64]
   Write Registry Key HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\, 
   Write Registry Key HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\$TITLE$\NoModify, 1
   Write Registry Key HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\$TITLE$\NoRemove, 1
   Write Registry Key HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\$TITLE$\NoRepair, 1
   Write Registry Key HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\$TITLE$\DisplayVersion, $VERSION$
[compiler else]
   Write Registry Key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\, 
   Write Registry Key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\$TITLE$\NoModify, 1
   Write Registry Key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\$TITLE$\NoRemove, 1
   Write Registry Key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\$TITLE$\NoRepair, 1
   Write Registry Key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\$TITLE$\DisplayVersion, $VERSION$
[compiler end]

It would be nice, though, to see this fixed in future releases of InstallAware.

[mills]

Glad you're good to go. I'm not sure what the final verdict will be, but I'm trying to put some pressure on our developers to fix this.

And while I don't think it applies to you (it may apply to someone reading this), my concerns about installing 64 and 32 bit versions of the same software on the same system shouldn't cause a problem as long as you give the different versions distinct product codes.

[sol952]

Is the workaround that jsmith posted still the best way to this problem?

[FrancescoT]

This is an old post ...for what I know, this should be handled correctly by more recent IA versions.

Of course, assuming to install a native x64 setup package on a x64 bit target OS.

Regards

[sol952]

I am having this issue on the x4 version. Is there more that I need to add to the beginning of the msicode to set it to x64 than this?

Code: Select all

if Variable ISWIN64 Equals TRUE
  Set x64 - Native 64 bit Windows, AMD64 and EM64T Architectures - installation mode
  else
  MessageBox: $TITLE$ Setup Debug, This package requires a x64 OS!$NEWLINE$$NEWLINE$The setup can not continue.
  Terminate Installation
end

all registry entries except the uninstall string are in the correct places. I will test more and try it without running the msi as system

[FrancescoT]

Dear sol952,

I was wrong, I just run a quick verification installing a native x64 setup package (Set x64 - Native 64 bit Windows, AMD64 and EM64T Architectures - installation mode) on a x64 target OS.

The MSI engine runs in 32 bit mode Always and consequently, it places the UninstallString under the Wow6432Node Always.
So on the MSI engine side there isn't so much that can be done, also because the MSI engine wants the same Wow6432Node location when the same package gets un-installed.

Regards

[sol952]

Is there any way to get around that for msi installs? maybe some group poilicy setting? I am also running into this with exe version that I tried.

[FrancescoT]

Dear sol952,

if the problem is to have an "UninstallString" key under the x64 Registry node, you may try to explicitly write it.

Code: Select all

~InstallAware Clipboard Data~
~Write Registry~
~{B2F0E694-6554-4FC6-AE17-377469162AEE}~
~0~
~2|~
~SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\$PRODUCTCODE$~
~UninstallString~
~$UNINSTALLLINK$~
~TRUE~
~FALSE~

Just tried and it works.
Of course, you must use "Set x64 - Native 64 bit Windows, AMD64 and EM64T Architectures - installation mode" before the above key gets created.

Hope this helps you.

Regards