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
- :
- Problem using Active Setup on x64 systems
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
‎Jul 08, 2014
06:09 AM
Problem using Active Setup on x64 systems
I am using the Microsoft Active Setup registry key to execute a .reg file when a different user logs into the system.
The current implementation works for x86 systems. However, for x64 systems, it is not working.
The MSI is a basic MSI, compiled as a x86 setup.
The component for setting up Active Setup has a registry key written to HKLM\SOFTWARE\Microsoft\Active Setup\Installed Components\[ProductCode]
The registry entry is Version=1,0; stubPath=regedit /s "[INSTALLDIR]myRegFile.reg"
In the same component, I have a corresponding matching key for HKCU.
When I install on a x86 machine, the values are written correctly in both locations.
On a x64 system, the HKLM key writes to the Wow6432Node BUT HKCU does not write anything to the Wow6432Node, instead it is writing to the x86 Node.
When the current user restarts the x64 machine, they are given a UAC prompt to modify the registry. They should not be prompted for anything for this since the version exists in the HKCU key. I am not even sure if this Hive is supposed to support virtualization either. However, Active Setup, if I give permissions to run, creates a key in a node labeled Wow6432Node for Active Setup. If I restart the system again, there are no more prompts for merging a .reg file. If I log into a system as a different users there are no prompts for merging .reg changes. However if I inspect the registry, the .reg file has definitely been merged.
Here is an article that explains how this key is used: http://www.etlengineering.com/installer/activesetup.txt, by Ed Tippelt.
Attached is a sample MSI that shows the problem. Run the installation on a Windows x64 system. After look at the HKLM registry key, and then again at the HKCU key. HKCU insists on writing to the 64bit registry hive while HKLM is writing, correctly, to the HKLM hive.
Seeing this problem I thought I would try writing specifically to the Wow6432Node in HKCU, but no, Vista x64 does not like this at all and tells me that I do not have sufficient privileges to perform this action. I tried this using a condition VersionNT64 for the component so that it only installs on x64 systems, and NOT VersionNT64 on the x86 component.
The current implementation works for x86 systems. However, for x64 systems, it is not working.
The MSI is a basic MSI, compiled as a x86 setup.
The component for setting up Active Setup has a registry key written to HKLM\SOFTWARE\Microsoft\Active Setup\Installed Components\[ProductCode]
The registry entry is Version=1,0; stubPath=regedit /s "[INSTALLDIR]myRegFile.reg"
In the same component, I have a corresponding matching key for HKCU.
When I install on a x86 machine, the values are written correctly in both locations.
On a x64 system, the HKLM key writes to the Wow6432Node BUT HKCU does not write anything to the Wow6432Node, instead it is writing to the x86 Node.
When the current user restarts the x64 machine, they are given a UAC prompt to modify the registry. They should not be prompted for anything for this since the version exists in the HKCU key. I am not even sure if this Hive is supposed to support virtualization either. However, Active Setup, if I give permissions to run, creates a key in a node labeled Wow6432Node for Active Setup. If I restart the system again, there are no more prompts for merging a .reg file. If I log into a system as a different users there are no prompts for merging .reg changes. However if I inspect the registry, the .reg file has definitely been merged.
Here is an article that explains how this key is used: http://www.etlengineering.com/installer/activesetup.txt, by Ed Tippelt.
Attached is a sample MSI that shows the problem. Run the installation on a Windows x64 system. After look at the HKLM registry key, and then again at the HKCU key. HKCU insists on writing to the 64bit registry hive while HKLM is writing, correctly, to the HKLM hive.
Seeing this problem I thought I would try writing specifically to the Wow6432Node in HKCU, but no, Vista x64 does not like this at all and tells me that I do not have sufficient privileges to perform this action. I tried this using a condition VersionNT64 for the component so that it only installs on x64 systems, and NOT VersionNT64 on the x86 component.
(4) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 08, 2014
07:49 AM
Dan,
here is also a very helpful article, especially the comment from Christopher Painter !
http://blogs.flexerasoftware.com/installtalk/2011/11/using-active-setup-to-repair-user-settings.html
will try your area51.msi later.
regards
Markus
here is also a very helpful article, especially the comment from Christopher Painter !
http://blogs.flexerasoftware.com/installtalk/2011/11/using-active-setup-to-repair-user-settings.html
will try your area51.msi later.
regards
Markus
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 08, 2014
08:33 AM
I separated the HKCU registry key values to a separate component.
I created a separate component that writes to HKCU\Software\Wow6432Node
I set the condition for the Wow6432Node component to VersionNT64
I set the condition for the x86 component to NOT VersionNT64
I thought I had tested this scenario yesterday but I guess I did something wrong. My tests this morning are successful with this configuration.
I understand what Christopher posted. However in our case the key does not have to be rewritten on upgrade. So for me I have factored my to use the UpgradeCode for the Active Setup key. Otherwise I would implement something like Christopher indicates.
Note that the following Microsoft article explains the registry limitations for Wow6432Node: http://msdn.microsoft.com/en-us/library/windows/desktop/aa384253(v=vs.85).aspx
I created a separate component that writes to HKCU\Software\Wow6432Node
I set the condition for the Wow6432Node component to VersionNT64
I set the condition for the x86 component to NOT VersionNT64
I thought I had tested this scenario yesterday but I guess I did something wrong. My tests this morning are successful with this configuration.
I understand what Christopher posted. However in our case the key does not have to be rewritten on upgrade. So for me I have factored my to use the UpgradeCode for the Active Setup key. Otherwise I would implement something like Christopher indicates.
Note that the following Microsoft article explains the registry limitations for Wow6432Node: http://msdn.microsoft.com/en-us/library/windows/desktop/aa384253(v=vs.85).aspx
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 09, 2014
02:55 PM
DLee65 wrote:
I separated the HKCU registry key values to a separate component.
I created a separate component that writes to HKCU\Software\Wow6432Node
I set the condition for the Wow6432Node component to VersionNT64
I set the condition for the x86 component to NOT VersionNT64
I thought I had tested this scenario yesterday but I guess I did something wrong. My tests this morning are successful with this configuration.
I understand what Christopher posted. However in our case the key does not have to be rewritten on upgrade. So for me I have factored my to use the UpgradeCode for the Active Setup key. Otherwise I would implement something like Christopher indicates.
Note that the following Microsoft article explains the registry limitations for Wow6432Node: http://msdn.microsoft.com/en-us/library/windows/desktop/aa384253(v=vs.85).aspx
The build I tested from my development machine worked with the above configuration but the same changes from the build machine does not work. I am not certain why. I compared the two MSI files and the same registry entries are there, but still the error persists.
I suspect that Vista x64 and Server 2008 x64 are more strict on allowing installers to write to HKCU\Software\Wow6432Node directly.
Right now I am just removing the components that write to the Wow6432Node and let the system take care of itself on reboot. The .reg file will just overwrite the existing data, but it should be the same data anyway.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 09, 2014
03:13 PM
May be a stupid question, but why use a "regedit" to write to the registry. Why not using basic MSI registry functionality in a component, or installscript in a custom action.
And if "active setup" is through windows activated on 64-Bit and you call "regedit", which version is used from windows ?
"%systemroot%\system32\regedit" (64-bit process) or "%systemroot%\syswow64\regedit" (32-bit process)
regards
Markus
And if "active setup" is through windows activated on 64-Bit and you call "regedit", which version is used from windows ?
"%systemroot%\system32\regedit" (64-bit process) or "%systemroot%\syswow64\regedit" (32-bit process)
regards
Markus