24

Do OpenSubKey() and other Microsoft.Win32 registry functions return null on 64-bit systems when 32-bit registry keys are under Wow6432node in the registry?

I'm working on a unit testing framework that makes a call to OpenSubKey() from the .NET library.

My development system is a Windows 7 64-bit environment with Visual Studio 2008 SP1 and the Windows 7 SDK installed.

The application we're unit testing is a 32-bit application, so the registry is virtualized under HKLM\Software\Wow6432node. When we call:

Registry.LocalMachine.OpenSubKey( @"Software\MyCompany\MyApp\" );

Null is returned, however explicitly stating to look here works:

Registry.LocalMachine.OpenSubKey( @"Software\Wow6432node\MyCompany\MyApp\" );

From what I understand this function should be agnostic to 32-bit or 64-bit environments and should know to jump to the virtual node.

Even stranger is the fact that the exact same call inside a compiled and installed version of our application is running just fine on the same system and is getting the registry keys necessary to run; which are also being placed in HKLM\Software\Wow6432node.

What should I do?

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
BrMcMullin
  • 1,261
  • 2
  • 12
  • 28
  • Follow up: it turned out we didn't need to create a new platform target after all. We run the tests through nunit, which distributes an x86 specific executable. Using the x86 specific executable allowed the tests to access the Registry without changes to the framework. – BrMcMullin Feb 18 '11 at 18:18
  • I found answered here [http://stackoverflow.com/questions/1074411/how-to-open-a-wow64-registry-key-from-a-64-bit-net-application](http://stackoverflow.com/questions/1074411/how-to-open-a-wow64-registry-key-from-a-64-bit-net-application) – Jirapong Nov 17 '10 at 03:50

4 Answers4

23

It sounds like your unit testing project compiles to 64 bit. In the Compile settings of your unit testing project, set the "Target CPU" to x86 (instead of AnyCPU).

Heinzi
  • 167,459
  • 57
  • 363
  • 519
11

If you really need a 32 bit application, you can access the 64 bit registry like this:

RegistryKey localMachine64 = RegistryKey.OpenBaseKey(RegistryHive.LocalMachine, RegistryView.Registry64);
RegistryKey regKey = localMachine64.OpenSubKey(@"Software\MyCompany\MyApp\", false);
nmat
  • 7,430
  • 6
  • 30
  • 43
  • What is the minimum required version of .NET for OpenBaseKey() to be available? In particular, would it be available using Visual Studio 2008? – Peter Mortensen Feb 13 '15 at 02:04
  • It seems to be .NET 4.0. From [another answer](http://stackoverflow.com/questions/26217199/what-are-some-alternatives-to-registrykey-openbasekey-in-net-3-5/26217602#26217602): "For .NET versions earlier than version 4 there is no framework API that allows access to alternate registry views.". – Peter Mortensen Feb 13 '15 at 19:51
3

Yes, I also have the same issue with Windows 7 64-bit and Visual Studio 2008 SP1. But my solution is the opposite, which is to change from "x86" to either "Any CPU" or "x64".

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Rudi Suwanto
  • 31
  • 1
0

To whom may concern

In my test, if you are using AnyCpu to build the code to do the OpenSubKey, and run it on a x64 OS, You will find that you are not working on where you are expecting.

Say for example: (Tested in .net 4.5.2)

RegistryKey rsk = Registry.LocalMachine.OpenSubKey("SOFTWARE");

when you check the rsk.GetSubKeyNames()

I checked this in debug , the result is neither HKLM nor HKCU, at least i cannot tell what it is (very much like HKCU but not the same).

And the most famous issue this could lead to is:

DeleteSubKeyTree will throw Argument Exception. if you try open the subkey before deleting, it is ok, but when doing the deletion, it will say, hey, it is not here...

So be careful, now I will never never use AnyCPU any more.

Jcat
  • 51
  • 1
  • 5