Scripting, Migrating and Managing Registry Data In 64-bit Windows Print E-mail
Written by Darwin Sanoy   
Thursday, March 3, 2011 3:33pm

Working in an environment of mixed 32-bit and 64-bit Windows can mean some frustration when managing registry settings for 32-bit software.  In this article we give a description of the challenges, tips and and techniques and a very handy .REG file to ease your frustration!

32-bit Registry Redirection for 32-bit EXEs

Note: Software that is designed for 64-bit can be primarily or completely composed of 32-bit EXEs and DLLs – hence the usage of the term “32-bit EXE” throughout this article.  In other words, Windows does not care if the supported platforms in the marketing description of the software claim to be a 64-bit edition – it only cares about the bitness of the EXEs that are running.

This challenge primarily affects 32-bit software since it stores registry settings in a special place in the registry of 64-bit Windows.  Keep in mind that many installation packages that install successfully for 64-bit windows are still installing software that is made up of 32-bit EXEs that are simply designed to work properly on the 64-bit version of Windows.  This challenge can also affect 64-bit software when it is installed by 32-bit installation technology that inadvertently places the required registry keys in the 32-bit registry.  The opposite can happen as well – a Windows Installer package marked as 64-bit can contain 32-bit EXEs that cannot find the required registry keys after installation.

On 64-bit Windows the local machine software registry “HKLM\Software” is only supposed to contain registry keys for 64-bit EXEs.  32-bit EXEs store their data in HKLM\Software\Wow3264Node.  This storage scheme is enforced by the Windows kernel – when a 32-bit EXE writes to “HKLM\Software” the operations are redirected to “HKLM\Software\Wow3264Node”  To the 32-bit EXE everything is transparent – it thinks it is reading and writing to the key it always has.

Learn about supporting applications on 64-bit Windows in our class CSI-330 - Provisioning and Supporting Applications on 64-bit Windows.

The implementation works similarly to UAC Virtualization – however, it is NOT UAC Virtualization and it is NOT disabled if you disable UAC Virtualization (by any of the many methods available).

If you use .REG files to configure or migrate software settings, you can run into some frustrations with your scripting and manual use of .REG files.  The 64-bit version of Windows Explorer registers the 64-bit version of regedit.exe to process all .REG files.  .REG files are not marked in any way that allows 64-bit Windows to automatically direct the keys to the correct place, so they end up in the 64-bit software registry location.

Here are some of the troublesome scenarios:

  • .REG files from a 32-bit machine that contain HKLM\Software keys, when imported, are brought into HKLM\Software, but 32-bit EXEs running on the same machine are being redirected to HKLM\Software\Wow3264Node where the keys do not exist.
  • .REG files from a 64-bit machine that contain HKLM\Software\Wow3264Node keys are imported to this same location on 32-bit machines where they are ignored by the 32-bit EXEs that usually reference these keys.  This also hampers attempts to correct key locations by moving them from the 32-bit software registry to 64-bit software registry on the same machine.

I’m afraid it get’s a little bit worse, before it get’s better.  The same issue affects all types of registry scripting.  Editing the registry with NT Shell Scripts (.CMD/.BAT), VBScript (.VBS) or Powershell (.PS1).  Editing the registry with the command line tool reg.exe is also affected.

Now that you have visions of yourself endlessly doing search and replace operations on all your scripts and .REG files, let’s show you an easier way.

All the 32-bit versions of the script engines and reg.exe are also redirected like any other 32-bit EXE.  In addition, all of the 32-bit versions of the script engines and EXEs are also installed on 64-bit Windows in a folder called %WinDir%\SysWOW64”

So in the case of scripting engines, you will want to override the default 64-bit scripting engines with an explicit reference to the 32-bit version.

Here are some sample translations:

Default 64-bit:
Force 32-bit Engine Processing:
OurLogonScript.vbs %WinDir%\SysWOW64\wscript.exe OurLogonScript.vbs
FixUp.cmd %WinDir%\SysWOW64\cmd.exe FixUp.cmd
SoftwareWrapper.ps1 %WinDir%\SysWOW64\WindowsPowerShell\v1.0\powershell.exe SoftwareWrapper.ps1
reg.exe ADD HKLM\Software /ve   %WinDir%\SysWOW64\reg.exe ADD HKLM\Software /ve

Just a quick note on PowerShell, the execution policy is a setting that redirected for the 32-bit version of Powershell, so you must set the execution policy for the 32-bit engine as well.  When setting the execution policy in your 64-bit Windows build set it for both engines with these two lines of code (if executing in the default 64-bit CMD.EXE):

%windir%\System32\WindowsPowerShell\v1.0\powershell.exepowershell Set-ExecutionPolicy Unrestricted

%windir%\SysWOW64\WindowsPowerShell\v1.0\powershell.exe Set-ExecutionPolicy Unrestricted

It is best to do this at the time the script is launched, rather than changing path references WITHIN scripts.  The reason is simple, once you’ve started your script with the 32-bit scripting engine, everything it calls locally comes from the redirected “system32” folder (SysWOW64) automatically with no changes to any of the remaining script code or utilities that it calls.


  • hard coded references in your script code (because the redirection happens at the kernel level).
  • scripting engines that have a path added to the system %PATH% variable (Powershell & cmd.exe) – even though these engines see the path, the kernel is redirecting the reference to %WinDir%\SysWOW64.

This approach should handle most of infrastructure scripting needs with a few key changes in various places.  You will need to determine that the platform is 64-bit or change all your scripts internally to probe for the 32-bit engine.  Our course on Supporting 64-bit Windows includes more in-depth information on these techniques.

Regedit Tricks To Avoid Editing .REG Files

What about ad-hoc use of your own administrator PC or when you are using remote control to a user PC or server?

There are two tricks to keep up your sleeve for general admin use – the first is, if you run regedit.exe from the SysWOW64 folder it shows you the registry exactly the same as 32-bit applications see it!  “So what?” you ask?  Let’s say you have a 64-bit application install with a 32-bit installer which mistakenly places 25 registry keys in HKLM\Software\Wow3264Node\CrazyApp.  You could export the key to a .REG file, do a search and replace on all the keys to remove “\Wow3264Node” (and hope you did the search replace correctly) and then re-import it.

Enjoying your read? Subscribe to our newsletter (without loosing your place in this article).
(Please ensure that the confirmation email clears your spam filter so that you will see future mailings.)

The easier way, however, is to simply run 32-bit regeditlexe from “%WinDir%\SysWOW64\regedit.exe” to do the export.  You will notice that the Wow3264Node does not exist in 32-bit regedit.exe and the keys that appear in “HKLM\Software” are the same as “HKLM\Software\Wow3264Node” in 64-bit Regedit.  Simply export the keys in 32-bit Regedit and import them in 64-bit Regedit.

64-bit Regedit (\system32\regedit.exe)

32-bit Regedit (\SysWOW64\regedit.exe)

64bitRegEdit 32bitRegEdit


Figure 1 – 32-bit Regedit Sees the “Wow6432Node” as the “SOFTWARE” Key.

Regedit only allows once instance to run, regardless of whether it is 32-bit or 64-bit, so you will need to launch and exit Regedit when moving between the two versions.

“Merge To 32-bit Registry” on .REG Context Menu

The other challenge is the use of .REG files – by default they are mapped to 64-bit Regedit.exe.  If you want to merge a .REG produced on a 32-bit Machine with the 32-bit Registry view of a 64-bit machine you would need to start 32-bit Regedit and use the menu to manually find the .REG file.

At the end of this article is a .REG files that adds “Merge with 32-bit Registry” for .REG files.  After merging this .REG file (using 64-bit Regedit), right clicking a .REG file will have this new menu item:


Figure 2 – New Menu Option For 32-bit Registry.

In our new 1 Day class CSI-330 - Provisioning and Supporting Applications on 64-bit Windows, we have these registry tweaks that add “Run in 32-bit Engine” and “Run in 32-bit Engine As Admin” for the files types .VBS, .CMD and .PS1.

The Rest of the Registry

This challenge only applies to HKLM\Software key.  So what happens if you are changing registry keys that are not in the software key along with keys that are?  The rest of the registry is mapped identically - so no matter whether you change other keys in 32-bit or 64-bit (scripting engines or regedit), it will be updated correctly.

Download this file ([ ]0.3 Kb

Add comment

Security code