What's the correct way to redirect registry access when using NtOpenKey?

Question

The code I'm working on has both 32-bit and 64-bit components and they need to share information in the registry. Because of this, I'm trying to control registry redirection when using the NtOpenKey function (the user-mode equivalent of ZwOpenKey) - I need to call this function from 64-bit code but access the 32-bit registry. (The code used to be 32-bit only and now it's getting upgraded to 64-bit so I'd prefer using as much of the existing code as possible - this is to say I'd prefer not to rewrite everything to use RegOpenKeyEx.)

Naturally, NtOpenKey doesn't recognize the KEY_WOW64_32KEY access flag, unlike high-level registry functions so there's no way to specify redirection.

At this point the only solution I can think of is to explicitly hardcode Wow6432Node in the key names when accessing the registry; something like:

\Registry\Machine\Software\Wow6432Node\MyCompanyKey\MyKey

Unfortunately, this is more of a hack and it's specifically discouraged by Microsoft.

Is there a correct solution to this problem? Reading through the documentation didn't help and I couldn't find any relevant search results either.

Edit: just a bit of extra detail: I need to support Windows Server 2003 32-bit/64-bit, Windows 7/8 and Windows Server 2008 32-bit/64-bit. (Basically all server flavors starting with Windows Server 2003 + Windows 7 and over.)

Answer 1

The native API does not offer an equivalent to KEY_WOW64_32KEY. Your options are:

1. Use the Win32 API.
2. Stick with native API and hard code the path.
3. Mix the Win32 and native APIs. Use the Win32 API to open HKLM\Software with KEY_WOW64_32KEY. Then call NtQueryKey to find out the native name of the key. And then use the native API from there on. This gets around your objection to hard coding.

Option 3 sounds plausible, but I've never called NtQueryKey and can't even be sure that the idea works.

Answer 2

Apparently I misunderstood your problem -- I thought this flag as a key option, not an access specifier.
In that case, I believe NtOpenKey should work just fine with KEY_WOW64_32KEY as the access mask. What happens when you try that?

Old answer (wrong):

This is why Windows Vista & later introduced NtOpenKeyEx.

I recommend using NtOpenKeyEx if it's available (make sure to link dynamically, not statically), and if it isn't, then either use NtCreateKey if possible, or use Wow6432Node otherwise.

There's no other solution AFAIK.