Why can't I find my registry key?

The Windows Registry is a hierarchical database that stores low-level application and Windows settings. It stores these in separate directory areas (known as hives). Some of these areas hold 64-bit application settings and some are 32 bit specific.

The Windows Registry Redirector isolates 32-bit and 64-bit applications by intercepting registry calls from those applications to their respective directories and mapping them to their own separate logical views. This can cause some headaches when working with the registry in .NET and C# as you may not be viewing the registry you think.

Recently, I had to perform some maintenance on our AdminUI Installer. This required me to update an existing process that checks to see if a first-time installer has the required .NET and IIS prerequisites to run AdminUI. Working in this area exposed me to some of the common pitfalls a developer may come up against when working with the Windows Registry in C#.

In this article, I'll show you the Windows Registry Redirector and how that affects registry calls in your .NET applications. Then you'll see how to access the registry to get the data you want using C#.

Windows Registry Redirector in practice

Because you can run both 32-bit and 64-bit applications on Windows, there may be instances where you have both 32-bit and 64-bit versions of the same application on one machine. If this is the case and they have different registry settings, how does Windows know which ones to load? This is where the Windows Registry Redirector comes into play.

When a 32-bit application running on a 64-bit operating system works with the registry, some of its calls will be intercepted by the Windows Registry Redirector and redirected to the ‘Wow6432’ base path.

In practice, this would mean that a call to SOFTWARE\Something\SomethingElse would be redirected to Wow6432\SOFTWARE\Something\SomethingElse

See a full list of affected registry keys.

Effects in the wild

My specific problem was that I needed the AdminUI installer to check if the AspNetCoreModuleV2 for Internet Information Services (IIS) was installed on the user’s machine. The installer, as part of several other prerequisite checks, ensures that the relevant software is installed by viewing the "Uninstall" subkey, which is located at SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\ and Wow6432\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\

My thinking was that I would add the IIS module to the list of keys the program was already checking. I could see on my machine that the IIS module had a registry entry under the SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\ key. However, when my updated code ran, it told me that the module was not present.

This was because I was using the following method to open the registry: Registry.LocalMachine.OpenSubKey(path);

It turns out that this method, when part of a 32-bit application running on a 64-bit operating system, will only ever return the 32-bit view of the registry.

Despite calling the above method with both the SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\ and Wow6432\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\ paths, the code was only actually ever opening the Wow6432\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\ path.

The registry call to the 64-bit view was (due to the fact the installer is a 32-bit application) being intercepted by the Windows Registry Redirector and being redirected to the Wow6432 node.

Accessing the correct view
Now that I knew the registry call was being intercepted, I had to change the way I was accessing the registry and explicitly open the 64-bit view of the registry.

In .NET 4.0 and above, this functionality is available in the form of the RegistryKey.OpenBaseKey method. Within this method, you can specify which view of the registry you want to open (32-bit or 64-bit) using the RegistryView Enum.

I changed the registry access code from: Registry.LocalMachine.OpenSubKey(path); to: RegistryKey.OpenBaseKey(RegistryHive.LocalMachine, RegistryView.Registry64).OpenSubKey(path);

The AdminUI installer now correctly identifies the presence or absence of the IIS module.

Conclusion

In this article, you have learned about the Windows Registry Redirector, how it separates 32-bit and 64-bit processes in the registry, and how this can cause some confusion when querying registry entries. You have also seen how to make registry calls to explicitly open both the 32-bit and 64-bit registry views as needed.

If you would like to learn more about AdminUI, or request a demo, please contact our sales team.