Windows x64 – All the Same Yet Very Different, Part 7: File System and Registry Redirection, Registry Reflection

This is the seventh part of a mini-series on Windows x64, focusing on behind the scene changes in the operating system. In the last article I explained that mixed 32-/64-bit processes are not allowed and how that rule affects both administrators and script-writers. In this context I mentioned the strangely named directory SysWOW64. Today I am going to explain what it is used for by starting with redirection.

File System Redirector

As you know, every Windows installation has a directory System32 that contains most DLLs that ship with the operating system. The names of many of those DLLs are well-known. advapi32.dll and ntdll.dll, for example, are used by almost every application. Some DLLs contain the number 32 in their name, some do not. That, however, is misleading: all DLLs in System32 of a 32-bit system are 32-bit images. Programmers know and expect this. When they need a certain DLL they have their program load the appropriate DLL from System32 and all is well.

All is well? Certainly not!

Consider a programmer who wants to make his product available both as 32- and 64-bit versions. He will do that by defining two compiler configurations, one for 32 bit, one for 64 bit. Without changing a single line of code he can build both a 32-bit and a 64-bit version of his application (provided he wrote good code in the first place). Wait. There must be a catch somewhere.

There is. The path to the System32 directory will (more often than not) be hard-coded in the program. We now have a 32- and a 64-bit application that both expect system DLLs to reside in the System32 directory. Both can run on the same (x64) system. Both can only load and use DLLs that have the same bitness as themselves. 32- and 64-bit DLLs have the same names.

Mission Impossible?

Not quite. Actually the solution is quite simple: use two System32 directories, each containing either 32- or 64-bit DLLs, and show each process the folder appropriate to its bitness under the name System32. That is, in a nutshell, what the file system redirector does.

In reality, it is a little more difficult, as you probably have guessed. Windows x64 has a directory System32 that contains 64-bit DLLs (sic!). Thus native processes with a bitness of 64 find “their” DLLs where they expect them: in the System32 folder. A second directory, SysWOW64, contains the 32-bit DLLs. The file system redirector does the magic of hiding the real System32 directory for 32-bit processes and showing SysWOW64 under the name of System32.

To make things more interesting, redirection is disabled for several subfolders that contain data independent of an application’s bitness (log files and the such):

Additionally, 32-bit processes “see” a different program directory. %ProgramFiles% points not to C:\Program Files but to C:\Program Files (x86).

Of course, loading DLLs directly from a file system path is only one of several prevalent techniques. Another involves the registry which stores registration information of COM servers (DLLs, often, EXE files, sometimes). Windows x64 needs to ensure that 32-bit processes only “see” DLLs they can actually load (the same applies to 64-bit processes, obviously).

Registry Redirector

On Windows x64, several high-level registry keys containing information specific to the bitness of a process have a sub-key called WOW6432Node. 64-bit applications see all of the registry while 32-bit processes get to see the contents of the WOW6432Node subkey instead. To be specific:

As with the file system, there are exceptions. Many registry keys containing data independent of a process’s bitness are excluded from the redirection. The following keys exist only once on Windows x64:

We know now that 32-bit processes see different content in several parts of the registry than 64-bit processes. Yet, in the attempt to isolate 32-bit from 64-bit DLL registration information, the registry redirector goes too far. The key HKLM\Software\Classes, for example, contains not only information on DLLs, but also file type associations (and other data). Who would want to associate the file extension DOC with Microsoft Word in 64-bit Explorer and end up in Wordpad when double-clicking a DOC file in a 32-bit instance of Windows Explorer?

Registry Reflection

To prevent that from happening, another component, called registry reflection, copies select data between the 32- and 64-bit views of the registry. Reflection is enabled for:

The reflection mechanism has some built-in logic: only registration information on out of process COM servers is reflected (out of process COM servers are executed in their own process, not in the process of the caller – in essence, EXEs, not DLLs).

The “last writer wins” principle applies. If you install IrfanView 32 bit and then Photoshop 64 bit (whenever that will be available), most image file types will probably be associated with Photoshop.

No (64-bit) program should create registry keys called “WOW6432Node” or (64-bit) programs recursively enumerating registry keys might end up in endless loops.

Conclusion

Microsoft has put a great deal of thought and work into the redirection and reflection processes to make the transition to Windows x64 as seamless as possible. These processes, however, have side-effects. One of them being that 32- and 64-bit applications do not “see” the same COM servers.

With this note I officially conclude this series. I might (and probably will) post additional articles detailing specific aspects of the x64 platform. The same applies to my colleague Nicholas Dille.