This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- 64-bit install writing to the 32-bit Registry area
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 01, 2012
03:10 PM
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
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
(9) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 01, 2012
03:30 PM
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!
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!
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 01, 2012
06:41 PM
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 01, 2012
07:01 PM
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
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
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 01, 2012
08:46 PM
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
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
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 01, 2012
08:47 PM
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...
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 02, 2012
04:30 PM
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
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
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 04, 2012
11:37 AM
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
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
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 17, 2013
07:06 PM
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"
![](/legacyfs/online/vb/9907_Capture.JPG)
Hope this helps.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 08, 2014
08:06 AM
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
![](/skins/images/D60DF682EA37BF37032955CE10F3F0BB/responsive_peak/images/icon_anonymous_message.png)