Windows x64 Part 7: File System & 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):

%Systemroot%\System32\catroot
%Systemroot%\System32\catroot2
%Systemroot%\System32\drivers\etc
%Systemroot%\System32\logfiles
%Systemroot%\System32\spool

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:

HKLM\Software -> HKLM\Software\WOW6432Node
HKCU\Software\Classes -> HKCU\Software\Classes\WOW6432Node

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:

HKLM\Software\Classes\HCP
HKLM\Software\Microsoft\Cryptography\Calais\Current
HKLM\Software\Microsoft\Cryptography\Calais\Readers
HKLM\Software\Microsoft\Cryptography\Services
HKLM\Software\Microsoft\CTF\SystemShared
HKLM\Software\Microsoft\CTF\TIP
HKLM\Software\Microsoft\DFS
HKLM\Software\Microsoft\Driver Signing
HKLM\Software\Microsoft\EnterpriseCertificates
HKLM\Software\Microsoft\MSMQ
HKLM\Software\Microsoft\Non-Driver Signing
HKLM\Software\Microsoft\RAS
HKLM\Software\Microsoft\Software\Microsoft\Shared Tools\MSInfo
HKLM\Software\Microsoft\SystemCertificates
HKLM\Software\Microsoft\TermServLicensing
HKLM\Software\Microsoft\Transaction Server
HKLM\Software\Microsoft\Windows NT\CurrentVersion\FontDpi
HKLM\Software\Microsoft\Windows NT\CurrentVersion\FontMapper
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Fonts
HKLM\Software\Microsoft\Windows NT\CurrentVersion\FontSubstitutes
HKLM\Software\Microsoft\Windows NT\CurrentVersion\NetworkCards
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Perflib
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Ports
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Print
HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Time Zones
HKLM\Software\Microsoft\Windows\CurrentVersion\Control Panel\Cursors\Schemes
HKLM\Software\Microsoft\Windows\CurrentVersion\Group Policy
HKLM\Software\Microsoft\Windows\CurrentVersion\Policies
HKLM\Software\Microsoft\Windows\CurrentVersion\Setup
HKLM\Software\Microsoft\Windows\CurrentVersion\Setup\OC Manager
HKLM\Software\Microsoft\Windows\CurrentVersion\Telephony\Locations
HKLM\Software\Policies

Redirect? Copy!

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:

HKLM\Software\Classes
HKLM\Software\Microsoft\COM3
HKLM\Software\Microsoft\EventSystem
HKLM\Software\Microsoft\Ole
HKLM\Software\Microsoft\Rpc
HKCU\Software\Classes

There are several things to note:

1. 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).
2. 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.
3. 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.