regedit on x64 Server 2008

[Ray_Portrait]

Hi all,

I am having problems extracting registry using both EXE CA and InstallScript CA to call regedit /E . Only the SysWOW6432Node registry hive gets exported.

We have values in both hives as our Server is a x64 application but our Client is still 32bit.

When I run the identical call to regedit from cmd (c:\Windows\system) I get the x64 registry exported which is what I want the install to do. When I do the call from the 32bit cmd (c:\Windows\SysWOW64) I get the same outcome as the install giving me the 32bit registry.

What also concerns me is that the 32bit registry hasn't got SysWOW6432Node mentioned anywhere in the exported registry file. I guess this is a functionality Windows thought was important.

The IS Project (BasicMSI) has template summary of x64;1033, all components are marked as 64 bit components and the INSTALLDIR is [ProgramFiles64Folder]Blah\Bleh.

I don't think doing system searches and placing the PROPERTIES into the registry is feasable at this moment as we have a substantial amount of registry keys to backup.

Any help will be greatly appreciated.

[MichaelU]

I'm a little confused what the problem you're describing is. From a pure 64 or 32 bit representation of the registry, both will refer to e.g. HKLM\Software\Company\Product, and on a 64-bit machine the 32-bit name will map to HKLM\Software\WOW6432Node\Company\Product when it does a 32-bit access to the registry. Thus in general I would not expect to see an explicit reference to WOW6432Node.

If you want to write 64-bit keys from InstallScript, which is always 32-bit code, you will need to either modify REGDB_OPTIONS (when using InstallScript API to write keys), or ensure you call a 64-bit executable for something like your regedit /E example. To call the 64-bit executable from the System64Folder/WINSYSDIR64 path, you will probably have to Disable(WOW64FSREDIRECTION) around the call to LaunchApplication.

As a side thought, there are some technical limitations in our COM extraction that prevent use of REGSAM flags from differentiating between 32-bit and 64-bit keys. So for a 64-bit COM extraction to write a 32-bit key, unfortunately it would have to refer to the WOW6432Node explicitly, and this name would get installed as a 64-bit key. This is not a best practice, although personally I expect it will work fine for a long time.

[Ray_Portrait]

I think that I have solved my registry backup problem.

I created a vbscript CA that has the ability to run as x64 (in IS 2010). I then launch regedit (the x64 version 🙂 ) from the script and I can export the x64 registry.

Set WshShell = CreateObject("WScript.Shell")
PathSYS = Session.Property("System64Folder")
Command = PathSYS + "regedt32.exe /E c:\test_install.txt HKEY_LOCAL_MACHINE\SOFTWARE\Blah\Bleh\Version"
WshShell.Run Command

MichaelU, you are quite right when you say that the ISScript is always 32-bit (as far as I know the built install runs as 32-bit). Thus any calls to cmd, regedit and cscript always seems to favour 32-bit versions of these files.

As for the REGDB_OPTIONS, you are correct when saying that it should be setup up to include the "REGDB_OPTION_WOW64_64KEY" option to read/writing registry files using IS functions. It rightfully so doesn't have any effect on external app calls (which is my problem).

Com extraction makes me nervous for win 64, but touch wood I haven't had any problems with it yet. Thanks for your input!! I agree with you that this is not best practise but desperate times call for drastic measures.