Useful WOW64 file system trick

On all 64-bit versions of Windows, the operating system performs a few file system and registry tricks for 32-bit applications. Essentially, operations targeting certain locations are transparently redirected to separate locations to allow applications that might not even know they’re on a 64-bit machine to interact with a more predictable environment.

The functioning of 32-bit applications on 64-bit Windows is described in detail in MSDN. The short version is that when applications are looking for files into C:\Program Files, they’re transparently redirected to C:\Program Files (x86). The same goes for C:\Windows\System32, which contains the 64-bit Windows binaries and is redirected to C:\Windows\SysWOW64 (the destination for the 32-bit equivalents). Same for a bunch of other file locations and registry hives, subject to a few caveats.

Sometimes it is necessary for 64-bit aware x86 code to get out of its shell and reach out to the true 64-bit locations. For application code, it’s quite easy to work around both the file system and the registry redirector. To access an alternate view of the registry (32-bit from a 64-bit app or viceversa), you need to remember the KEY_WOW64_64KEY and KEY_WOW64_32KEY flags, and to access the true 64-bit directories, a few API calls must be made. But here’s the fun part:

If you write a script (batch, or JavaScript/VBScript), it’s easy to tell if you’re running in a native 64-bit command processor or in the WOW, but there’s almost no way to work with the 64-bit files and registry locations from a script running as 32-bit if the host doesn’t help you.

Starting with Vista, there’s a very simple way to reach the true System32 directory from the WOW: Look for %WINDIR%\sysnative. This is a virtual directory available only to 32-bit applications on 64-bit operating systems which points to the true %WINDIR%\System32. Let’s try it out:

Launch %WINDIR%\SysWOW64\Cmd.exe (the 32-bit command prompt). Let’s see if anything exists under %WINDIR%\sysnative:

Microsoft Windows [Version 6.0.6001]
Copyright (c) 2006 Microsoft Corporation.  All rights reserved.

C:\>if exist %WINDIR%\sysnative\reg.exe echo Foo


On the other hand, if you run the same command from a 64-bit command prompt launched from %WINDIR%\System32\Cmd.exe:

Microsoft Windows [Version 6.0.6001]
Copyright (c) 2006 Microsoft Corporation.  All rights reserved.

C:\>if exist %WINDIR%\sysnative\reg.exe echo Foo


It’s as simple as that. If you need to modify the 64-bit registry from a script running under the 32-bit host, all you need is to invoke reg.exe from the sysnative directory. Better yet, you can come up with batch files that re-launch themselves with the 64-bit command interpreter on a 64-bit OS. All you need to do is look for %WINDIR%\sysnative\cmd.exe, after all.

About these ads
This entry was posted in Computer and Internet. Bookmark the permalink.

9 Responses to Useful WOW64 file system trick

  1. Ajith says:

    Awesome! Thats exactly what I was looking for! BTW, for those readers who want this for Win2k3 64-bit, get this hotfix:

  2. Homiczyl says:

    Thank you ist very helpfull :]

  3. John Rolstead says:

    This solution works for vbscript as well. Case is when launching cscript.exe from SCCM. Set the SCCM program to call %windir%\Sysnative\cscript.exe so you get the 64 bit version which will then run the 64 bit version of any exe you run from the vbscript. An example is Manage-Bde.exe, it will quitely exit and do nothing if you don’t call the 64 bit version.

  4. Green says:

    i tried running the following i can’t seems to get the vbs to work.

    @echo off
    CScript necdaily.vbs

    Is there a anything wrong with my codes

  5. Ray says:

    Thank you x 1000

  6. ronney says:

    but how to get back to default?

    • ovidiupl says:

      Not sure what you mean. My suggestion does not involve changing any defaults, just using a 64-bit Windows feature. There is nothing to go “back” to, this is just how 64-bit Windows works.

  7. geoff says:

    Thanks a lot !!
    I have a powershell script that modifies the registry. It worked fine when run locally but not from SCCM. Because SCCM has a 32bit client it was redirecting to use the 32bit version of powershell which was then redirecting entries to HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node in the registry.

  8. Rohan says:

    Great article.
    This resolved an issue I had trying to install fonts to Win 7 64bit machines via DELLs KACE1000 software deployment system.
    KACE1000 agent is 32bit so was writing font registry entries to Wow6432Node in registry and fonts weren’t available to end users.
    After using the sysnative trick to run the 64bit cscript.exe for my vbscript, everything worked perfectly.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s