For those of you who haven’t had the joys of the Win64 registry, I decided that I would blog about it. When Win64 came around, clearly the Windows team had to think about how to support having 32-bit and 64-bit applications installed side-by-side. Their solution was to have two different versions of HKEY_LOCAL_MACHINE\Software. Which version of HKEY_LOCAL_MACHINE\Software your application got depended on if the process was 64-bit or 32-bit. Then, some keys are ‘reflected’. This means that if you register a 32-bit exe under ‘HKEY_LOCAL_MACHINE\Software\Classes\CLSID\{guid}\LocalSever32’, that key will also be automaticially written to the 64-bit registry. This isolation makes life much easier for some applications. However, it makes life much more complicated for the VS Debugger.

There are a few problems with this scheme:

1. 64-bit processes can write into the 32-bit version of the registry by writing HKEY_LOCAL_MACHINE\Software\Wow6432Node. 32-bit processes can read/write 64-bit registration by requesting KEY_WOW64_64KEY access. However, I don't believe that a 32-bit MSI can write these keys, so if you want to write keys in a 32-bit setup, they need to go in the 32-bit registry.
2. All settings are duplicated in two places. This means that we need to write two registry keys instead of just one. As an example, there are two different versions of AeDebug (HKLM\Software\Microsoft\Windows NT\CurrentVersion\AeDebug and HKLM\Software\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug).
3. Remote registry reads act like they are from a 64-bit process. So remote registry reads now need to check two locations for registry keys.
4. Because the ‘LocalSever32’ key is reflected, if you install a 32-bit and 64-bit version of the same EXE, the last installer wins, and uninstall will uninstall both. This isn’t true for COM dlls (InprocServer32 isn’t reflected).

A bit more information is here - http://support.microsoft.com/default.aspx?scid=kb;EN-US;305097