cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
xrz1138
Level 3

64-bit install writing to the 32-bit Registry area

Hello all,

This one is a tad long, so thanks in advance to any who did not just click away...

Problem:
=========================
We are building the installer for a 64-bit application using IS 2011 on a
32-bit box.

This is, and must be, a pure InstallScript installation.

I find that some of our Registry changes are being written to the 32-bit area
of the target 64-bit system.
(Note: this is the HKLM/SOFTWARE/Wow6432Node sub-key)
=========================

Note: this is a simple installer, defining only the OnFirstUIBefore,
OnMaintUIBefore, and OnUpdateUIBefore routines.

Now, we have explicitly added the use of the variable PROGRAMFILES64 in
in defining TARGETDIR, to ensure that all files are installed into, for
example, "C:\Program Files" and not into the 32-bit equivalent
"C:\Program File (x86)". This is working fine.

We have also added using the Registry related global to affect Registry
changes. Specifically, I added this line to my installer:

REGDB_OPTIONS = REGDB_OPTIONS | REGDB_OPTION_WOW64_64KEY;

Now for the heart of the matter:
=========================
Using the options above did make all Registry calls *that I make explicitly*
in my code write to the correct location.

It did not affect the Registry changes that InstallShield makes for me.
=========================

Specifically, this code:
#define INSTALL_REGISTRY_KEY "SOFTWARE\\Company Name, Inc.\\Installed Software"
RegDBSetDefaultRoot(HKEY_LOCAL_MACHINE);
szKey = INSTALL_REGISTRY_KEY;
nvReturn = RegDBSetKeyValueEx(szKey,"ApplicationCount", REGDB_STRING, szAppCount, -1);

Did create the new key "ApplicationCount" into HKLM\SOFTWARE\Company...

BUT I also ended up with the new key

HKLM\SOFTWARE\Wow6432Node\Company\Product\version

Where "Company" was *precisely* the installer "Company Name", taken straight
from the ISM files "General Information" sheet. "Product" was similarly taken
from the General Information sheets "Product Name". Same for Version.

So, what is happening here is that InstallShield is taking the General
Information settings and building default Registry settings, but it is writing
them to the Wow6432Node 32-bit sub-key of the registry which is wrong.

Basically, I need a method for ensuring that REGDB_OPTION_WOW64_64KEY
will make ALL Registry entries be made to the 64-bit part of the Registry.


Thank you all for the time and kind attention!

Chris Hahn
Labels (1)
0 Kudos
(9) Replies
xrz1138
Level 3

I should add that I tried my own fix for this.

I added my own "Registry Set" in the "System Configuration" -> "Registry"
section of IS 2011, and in this new set, I added

HKLM/SOFTWARE/COMPANY/PRODUCT/VERSION2

(with a value of VERSION that was slightly different from that in the
General Information page of InstallShield)

Saving and then building this yields an installer that correctly wrote:

HKLM/SOFTWARE/COMPANY/PRODUCT/VERSION2

into the 64-bit part of the Registry, but it ALSO wrote:

HKLM/SOFTWARE/Wow6432Node/COMPANY/PRODUCT/VERSION

I also used IS's Direct Editor to remove the "Default" record from
ISRegistrySet table. Doing this allowed me to specify just the new
Registry Set that I created above would be used for all Components
of this install. (by doing this, I found that I was unable to
de-select the Default Reg Set so I took this additional step)

No Joy.

I am under the gun and am going to have to release 64-bit installers that
my people will be having to worry about indefinitely. Yuck!
0 Kudos
RobertDickau
Flexera Alumni

According to the bottom of the REGDB_OPTIONS help topic, the REGDB_OPTION_WOW64_64KEY flag doesn't affect Add or Remove Programs-type information, in case that's what's being written to the 32-bit part of the registry. The CreateInstallationInfo help topic mentions that behavior, too.
0 Kudos
xrz1138
Level 3

Let me re-phrase that...

I have figured out how to make the Add or Remove keys in the proper place...
[Company Name] -> [Product Name] -> [Product Version]
Registry entries to HKLM\SOFTWARE.

All I need now is how to STOP Installshield from making this same sequence
of keys in the Wow6432Node sub-key.

I made a new Registry Set and deleted the default one. Then I added this
new Reg Set to every one of my Components.

Everything looks good....except that we have the duplicate keys being made
by IS down in the Wow6432Node area.

Please let me know how I might proceed. I am under the gun and will have
to release into the wild software that I am sure we will be dealing with in
all future releases.

Chris
0 Kudos
xrz1138
Level 3

Ugh....I take that back.

It is not just the [Company Name] -> [Product Name] -> [Product Version]
Registry keys that need to be redirected.

There is the
HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\GUID
area that would have to be deleted and recreated in the 64-bit part of the Registry.

...then I see that the uninstall was installed to the:
C:\Program Files (x86)\InstallShield Installation Information
directory, and that this would have to be moved to the 64-bit folder.

So, perhaps my manual approach is a dead-end.

POINT: I am building an Installscript installer using InstallShield 2011 Premiere
on a 32-bit Windows 7 box that intends to install 64-bit software onto 64-bit
systems.

How can I make such an installer consistently write to the 64-bit area in the
Windows Registry?

Thank you,

Chris Hahn
0 Kudos
RobertDickau
Flexera Alumni

You might be able to suppress the normal ARP settings by changing General Information > Maintenance Experience to No Uninstall or Maintenance. As the setting name suggests, though, re-running the installation wouldn't trigger maintenance mode, future installer versions probably wouldn't detect upgrades with built-in functionality, and so on; so proceed that way with serious caution, or at least a lot of testing the life-cycle operations you'll need in the future...
0 Kudos
xrz1138
Level 3

Yes, while I am waiting on confirmation from support, I begin to think
that I have been handed what for all intents and purposes is an unsolvable
problem.

I am going to have to rewrite an InstallScript installer into an MSI-Installscript
installer in a very short time period.

I will post questions here. If the answers do not save me, then perhaps
they will save the next poor soul.

Thanks for the time.

Chris
0 Kudos
xrz1138
Level 3

This is a dead end it seems.

There appears to be zero chance of preventing InstallShield Installscript
installers from writing the Add-Remove program Registry data to the
Windows 32-bit part of the Registry.

I am working to make sure that the material in:

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

is the only mis-placed data.

(and expecting windows to find what it needs when uninstalls run)

Good luck all,

Chris
0 Kudos
JR_Hine
Level 2

I found this thread when running into a similar issue. All my MSI needed to do was install 2 registry keys into HKLM>Software>Vendor Name and it kept redirecting them into HKLM>Software>Wow6432Node>Vendor Name.

What finally resolved this was a tip I found on IT Ninja:
In InstallShield, Installation Designer view, highlight Organization>Components in the left pane. Then highlight the component that you've setup to write the registry keys. Then, in the options on the right, set the following:
-change the "64-Bit Component" setting to "Yes"
-change the "Disable Registry Reflection" value to "Yes"



Hope this helps.
0 Kudos
dlavallee
Level 2

xrz1138 wrote:
This is a dead end it seems.

There appears to be zero chance of preventing InstallShield Installscript
installers from writing the Add-Remove program Registry data to the
Windows 32-bit part of the Registry.

I am working to make sure that the material in:

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

is the only mis-placed data.

(and expecting windows to find what it needs when uninstalls run)

Good luck all,

Chris


InstallShield CAN target 64-bit systems with 64-bit applications. When building a 64-bit app you must configure the Template Summary property for 64-bit applications. Additionally, if you are going to write to the 64-bit parts of the registry (via installscript) you need to add REGDB_OPTION_WOW64_64KEY to REGDB_OPTIONS first:
REGDB_OPTIONS = REGDB_OPTIONS I REGDB_OPTION_WOW64_64KEY;


See http://helpnet.flexerasoftware.com/installshield19helplib/helplibrary/Targeting64Bit-MSI.htm for details.

HTH,

Dave
0 Kudos