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.
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).
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.
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?
