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.