Selectively suppress Wow64 filesystem redirection on Vista x64 with ‘Sysnative’

One of the features implemented by the Wow64 layer on x64 editions of Windows for 32-bit programs is filesystem redirection, which operates similarly to registry redirection in that it provides a Wow64 “sandbox”, for file I/O relating to the System32 directory.

The reasoning behind this is that many programs have the “System32” directory name hardcoded, and more importantly, unlike the transition between 16-bit Windows and Win32, virtually all of the DLLs implementing the Windows API retained their same name (and path) across the 32-bit to 64-bit transition.

Clearly, this creates a conflict, as there can’t be both 32-bit and 64-bit DLLs with the same name and path on the same system at the same time. The solution that Microsoft devised, filesystem redirection, is a layer that intercepts accesses to the system32 directory made by 32-bit applications, and re-points the accesses to the SysWOW64 directory, which functions as the Wow64 version of the system32 directory (where most of the core Wow64 system DLLs reside).

Normally, this works fairly well, but there are times when a program needs to access the real System32 directory. For this purpose, Microsoft has provided a set of APIs to enable and disable the filesystem redirection on a per-thread basis. This is all well and dandy, but sometimes you may find yourself needing to turn off Wow64 filesystem redirection in a place where you can’t modify a program easily.

Until Vista, there was no easy way to do this. Fortunately, Vista adds a “backdoor” to Wow64 filesystem redirection, in the form of a pseudo-directory named “Sysnative” that is present under the Windows directory (e.g. C:\Windows\Sysnative). This pseudo-directory is not visible in directory listings, and does not exist for native 64-bit processes. For Wow64 processes, however, it can be used to access the 64-bit system32 directory.

Why would you need to do that in the first place? Well, there are lots of reasons, most of them dealing with things like where there is only a 64-bit version of a program that you need to launch (or the 64-bit version is necessary, such as if you need to communicate between a 32-bit process and a 64-bit process by launching another 64-bit process or something of the sort). Prior to Vista, situations like this were a pain, as there was no built-in way to access the 64-bit system32 directory. The “sysnative” pseudo-directory allows the problem to be addressed in a general fashion without requiring code changes, as Wow64 programs can address the 64-bit system32 via the special path (of course, this does require the user supplying such a path, but there is little working around this given the fact that 64-bit and 32-bit system DLLs have identical names).

Sysnative is not a universal solution, however. Some functionality does not work well with it, as sysnative does not appear in directory listings; for instance, the common controls open/save file dialogs won’t allow you to navigate through sysnative due to this issue.

6 Responses to “Selectively suppress Wow64 filesystem redirection on Vista x64 with ‘Sysnative’”

  1. Jeff Curless says:

    This is one of the biggest mistakes Microsoft has made lately. They should have just added a “System64” directory. Then make sure the loader knows not to try to load a 32/64 bit binary into the wrong address space. Any other issues are up to the programmer to fix. What’s that you say? But what about apps which are recompiled for 64bit but have hardcoded system32 strings? Well they were wrong anyway, and since they are being recompiled, how about fixing that bug?

  2. Skywing says:

    Yeah, I agree that it is kind of weird that the 32-bit files like in SysWOW64, and the 64-bit files continue to live in System32.

    I can only assume that there were some significant breakages that would have occured if they hadn’t kept the system32 name.

  3. Jeff Curless says:

    I didn’t mean get rid of system32, just put all the new 64 bit stuff in system64, and leave all the old 32bit stuff in system32. Just like they did when they moved from 16bit….

  4. Yoni says:

    “Sysnative is not a universal solution, however. Some functionality does not work well with it, as sysnative does not appear in directory listings; for instance, the common controls open/save file dialogs won’t allow you to navigate through sysnative due to this issue.”

    What if you create a directory called Sysnative, to fool the comdlg?

  5. Skywing says:

    Good call. Yup, creating a sysnative directory seems to work without any visible negative side effects in 5 minutes of poking around.

  6. Ryan says:

    thanks.
    I key off of Environment.Is64BitOperatingSystem and set the subfolder to System32 or sysnative.