cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Superfreak3
Level 11

Accessing HKLM\Software\Wow6432Node?

Hi all,

I've seen several posts on this subject, but I don't know if its really doable. we are moving from a 32 bit application to a 64 bit application/installation. I want to be able to access some values in HKLM\Software\Wow6432Node\OurApp\Subkey that were written during the live of the 32 bit app. I would use these to populate some serialization text boxes on a dialog.

I can't for the life of me get the values? I've tried toggling the look in the 64 bit registry option, but neither setting works.

Can this be done?
Labels (1)
0 Kudos
(4) Replies
Tetsuo
Level 4

Hi

What method are you trying to access the Wow6432Node key? Is this scripted?

Is your MSI pure 32bit running on 64bit machine?

This kind of thing is a right pain (thank MS!) but there are ways of achieving it
0 Kudos
Superfreak3
Level 11

Ah, yes good details to have left out.

It is a 64 bit installation that wants to access the WOW6432Node in HKLM.

I'm currently trying to use the System Search view in IS 2010.

I understand that I can write a CA dll, I guess, that could search the hive and set the running .msi properties I need, but C++ is recommended for that. I'm no C++ wiz (or any other programming language for that matter) but I might be able to scrape something together. Can I create a VB.NET dll to do the same or must it me C++?

What I initially tried was add a whole set of Properties to hold the searched/collected data from WOW6432Node. I was then going to set the dialog Properties to these newly created properties if they have been populated.

I would think maybe a .dll would be better. That way, if my original search properties (the ones displayed in the dialog) are not populated, I could fire the .dll Action to search the Wow6432Node.

Does anyone have any code that would get this done? If VB.net will work, that would be preferable.

Thanks for any info.

Any yes, this portion of .msi processing is a pain!!
0 Kudos
Tetsuo
Level 4

Hmm, how about creating a new vbscript custom action to fetch the registry properties?

It a little bit crude but the custom action script would be something along the lines of:

Dim objShell, strKey1, strKey2

Set objShell = CreateObject("WScript.Shell")

On Error Resume Next
strKey1 = ObjShell.RegRead("HKLM\SOFTWARE\Wow6432Node\InstallShield\16.0\CurrentVersion")
strKey2 = ObjShell.RegRead("HKLM\SOFTWARE\Wow6432Node\InstallShield\AdminStudio\ASLocation")

Session.Property("REGVALUE1") = strKey1
Session.Property("REGVALUE2") = strKey2


This should push the values of your registry keys into the desired Properties (REGVALUE1 etc) which could then be referenced elsewhere in your package.

I think the problem with the system search is that it is essentially returning a True or False value based on the Reglocator table and doesn't return the actual value of the key.
0 Kudos
Superfreak3
Level 11

I would have liked to get experience with writing a custom action .dll (in VB.NET preferably) to search the registry and set the properties.

However, this could work because if the registry entries can't be found, the user would just have to enter their serial number, etc the first time they upgrade our old 32 Bit Server app to the new 64 Bit app. In short, it's not a huge deal and although I would have like to try to see if its possible to have a custom action .dll written in VB.NET, the vbscript isn't a big deal.

I remember that vbscript custom actions are frowned upon, but we have a couple in our install presently anyway.

Thanks for the code snippet.

If anyone has successfully written and used a VB.NET custom action .dll, please let me know in which direction to go.

THANKS!
0 Kudos