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
- :
- Can't access 32-bit Registry item from a 64-bit installer
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
‎Jun 25, 2013
06:50 AM
Can't access 32-bit Registry item from a 64-bit installer
I'm having a problem with my 64-bit Basic MSI project. It's a package that needs to poll a Registry entry written by our other package (32-bit Basic MSI). The polling is done via an InstallScript custom action, and even though I run REGDB_OPTIONS = REGDB_OPTIONS & ~REGDB_OPTION_WOW64_64KEY; before my RegDBGetKeyValueEx query, I get the error code that FormatMessage translates to "The system cannot find the file specified", even though I've checked multiple times that the Registry key exists and the path is correct in my project apart from the Wow6432Node part (which should be handled by Windows). Or is it so that when querying 32-bit Registry from a 64-bit package, I'd need to hardcode the Wow6432Node into the path and REGDB_OPTIONS are not enough?
NvSize has been initialized and I tried this also with InstallShield 2013. The result was the same there as well.
NvSize has been initialized and I tried this also with InstallShield 2013. The result was the same there as well.
(4) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 25, 2013
08:33 AM
The InstallScript CA is running as a 32-bit process no matter the platform of the containing MSI, so HKLM\Software registry accesses will be redirected under Wow6432Node unless REGDB_OPTION_WOW64_64KEY is part of REGDB_OPTIONS. If you are accessing a different hive the redirection may not exist (or if it's accidentally the wrong hive it may just be the wrong key entirely).
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 26, 2013
01:44 AM
Thanks for the info MichaelU. Based on that info it looks like there's a bug here. The value I'm trying to access is indeed under HKLM\Software and as the project has both 32-bit and 64-bit releases, the custom actions use entry point functions which deliver the correct REGDB_OPTIONS to the actual functions. However, in my 64-bit version I need to temporarily fall back into using 32-bit Registry, but it seems like REGDB_OPTIONS = REGDB_OPTIONS & ~REGDB_OPTION_WOW64_64KEY; doesn't work after the entry point function has run REGDB_OPTIONS = REGDB_OPTIONS | REGDB_OPTION_WOW64_64KEY;
I actually tried hard-coding Wow6432Node into the path I tried to use and that reached the correct value. However, for obvious reasons I wouldn't like to use that approach but keep the path as one single define and let the OS pick the correct branch according to REGDB_OPTIONS.
I actually tried hard-coding Wow6432Node into the path I tried to use and that reached the correct value. However, for obvious reasons I wouldn't like to use that approach but keep the path as one single define and let the OS pick the correct branch according to REGDB_OPTIONS.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 27, 2013
03:12 AM
Neither REGDB_OPTIONS = REGDB_OPTIONS & ~REGDB_OPTION_WOW64_64KEY; nor REGDB_OPTIONS = REGDB_OPTION_USE_DEFAULT_OPTIONS; works in this case. Is it really so that the only way to actually access the value is by hard-coding Wow6432Node into the key path?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 27, 2013
04:34 AM
Would you like to post ( zip ) an test setup here?
![](/skins/images/D60DF682EA37BF37032955CE10F3F0BB/responsive_peak/images/icon_anonymous_message.png)