cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Janakiram
Level 4

64 bit Registry entry going into 32 bit registry area

Hi Team,

I really need your help here!!

All my MSI needed to do is install 1 registry key into HKLM>Software>Vendor Name but it is going into HKLM>Software>Wow6432Node>Vendor Name

This is happening only in windows 10(64bit OS), office 365 (64 bit), office excel version is 16.

It is working fine in windows 2008 R2(64 bit OS). office (64 bit), office excel version 14.

I tried changing below as well...

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"

Still it is writing registry entry into (Wow6432Node). Our code is


MsiGetProperty(hMSI, "EXCEL32BIT2007PLUS_INSTALLED", offcie32Version, nvSize);

office32version property is TRUE in our case. (as i already mentioned it is working on other host(OS 64 bit, office 64 bit). Issue is happening only in windows 10 64 bit, office 365 64 bit.


if(SYSINFO.bIsWow64 != 0) then

if (offcie32Version == "FALSE") then

//64-bit OS and Office 64
smExtensionsKey = "SOFTWARE\VendorName\\SM\\Extensions\\{2AB4F230-ED75-4dad-AAA5-6AA2NB9D35JF}";
sMExtensionPath = svInstallDir ^ "product\\smProduct\\Client\\bin-64\\SMxxxxxx.dll";

else

//64-bit OS But Office 32
smExtensionsKey = "SOFTWARE\\Wow6432Node\\VendorName\\SM\\Extensions\\{2AB4F230-ED75-4dad-AAA5-6AA2NB9D35JF}";
sMExtensionPath = svInstallDir ^ "product\\smProduct\\Client\\bin\\SMxxxxx.dll";
RemoveDirectoryA(svInstallDir ^ "product\\smProduct\\Client\\bin-64");

endif;
else

MessageBox("inside first if, IS OS not a 64bit, yes", INFORMATION);
smExtensionsKey = "SOFTWARE\\VendorName\\SM\\Extensions\\{2AB4F230-ED75-4dad-AAA5-6AA2NB9D35JF}";
sMExtensionPath = svInstallDir ^ "product\\smProduct\\Client\\bin\\SMxxxxx.dll";
RemoveDirectoryA(svInstallDir ^ "product\\smProduct\\Client\\bin-64");

endif;

REGDB_OPTIONS = REGDB_OPTIONS | REGDB_OPTION_WOW64_64KEY;
RegDBSetDefaultRoot(HKEY_LOCAL_MACHINE);
RegDBSetKeyValueEx(smExtensionsKey, "", REGDB_STRING, sMExtensionPath, -1);
RegDBSetKeyValueEx(smExtensionsKey, "type", REGDB_STRING, "SMxxxx.xxxxx", -1);

// Flush the NT registry to all applications.

szEnv = "Environment";
pEnv = &szEnv;
SendMessage (HWND_BROADCAST, WM_WININICHANGE, 0, pEnv );

end;

 

Labels (1)
0 Kudos
(12) Replies
Jenifer
Flexera Alumni

Hi @Janakiram ,

 

Other than the line:

//64-bit OS and Office 64
smExtensionsKey = "SOFTWARE\VendorName\\SM\\Extensions\\{2AB4F230-ED75-4dad-AAA5-6AA2NB9D35JF}";

which has to be 

smExtensionsKey = "SOFTWARE\\VendorName\\SM\\Extensions\\{2AB4F230-ED75-4dad-AAA5-6AA2NB9D35JF}";(with one back-slash added)

nothing seems to be wrong for me,i had verified the same code on windows 10-64-bit machine.It works properly.Can you verify it on some other machine(win-10-64-bit) and confirm?

But your comment on "the same code works on  windows 2008 R2(64 bit OS)" is little weird.You can enable log and check the comparison on both machines(Win10,Win2008 R2) if that could help.

Does that component any condition been set?

 

Thanks,

Jenifer

0 Kudos

Hi Jenifer,

Thank you for your reply!!

Back slash is my mistake while copying it here, It is correctly mentioned in our script .

The issue is reproducible across all environments that are windows 10 (64 bit) office 365 (64 bit).  As i mentioned it is working in other host (windows 10, 64 bit OS; office 32 bit ) and  (windows 2008R2, 64 bit OS; office 64bit) registry entry is going to both places.

"SOFTWARE\\VendorName\\SM\\Extensions\\{2AB4F230-ED75-4dad-AAA5-6AA2NB9D35JF}";

"SOFTWARE\\Wow6432Node\\VendorName\\SM\\Extensions\\{2AB4F230-ED75-4dad-AAA5-6AA2NB9D35JF}"

0 Kudos

With which InstallShield version do you work ? 2014, 2015, 2016 ?

regards

Markus

0 Kudos

Hi Markus,

I am using installShield 2013.

0 Kudos

Can someone help me on this?

0 Kudos

And it is a msi package you build, without bootstrapper (setup.exe) ?

regards

Markus

0 Kudos

Hi Markus,

It is setup.exe

0 Kudos

I'm not sure if it has anything to do with your problem. But if you use InstallShield 2013 and target Windows 10 you should update your SetupExe*.manifest files to recognize Windows 10.

See here for "How to do":

https://community.flexera.com/t5/InstallShield-Knowledge-Base/Windows-Compatibility-Issues-on-Windows-8-1-and-Server-2012-R2/ta-p/4683

And here to include also the detection for Windows 10:

https://docs.microsoft.com/en-us/windows/win32/sysinfo/targeting-your-application-at-windows-8-1?redirectedfrom=MSDN

And here:

https://community.flexera.com/t5/InstallShield-Knowledge-Base/Identifying-Windows-10-with-MSI/ta-p/4166

regards

Markus

0 Kudos

Hi Markus,

But our setup.exe is working fine in windows 10;64bit with office 32 bit

Thanks

 

0 Kudos

Hi Markus,

i have also added these entries to manifest.

<!-- Windows 10 -->

<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>

<!-- Windows 8.1 -->

<supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>

But i still see the same issue.

0 Kudos

Hi Team,

Can someone help me here.

Anything else i can do?

0 Kudos

Hi @Janakiram ,

 

"You can enable log and check the comparison on both machines(Win10,Win2008 R2) if that could help."

-Did you try this?Comparing the logs of both working & non-working version of 64-bit OS with 64-bit office?

If possible attach logs here

"windows 10(64bit OS), office 365 (64 bit), office excel version is 16.

It is working fine in windows 2008 R2(64 bit OS). office (64 bit), office excel version 14."

Can you elaborate a bit on "Windows 10 64bit with office 32 bit"?What is the role Microsoft application office plays a role here with respect to registry redirection.

That is something fishy which is out of InstallShield's scope.If the mentioned issue isn't working for Windows 10 64-bit on all versions(With or without office software) that might be an issue from InstallShield which isn't the case here.

 

Thanks,

Jenifer

0 Kudos