I discovered that I could solve my problem using the flag: KEY_WOW64_64KEY , as in: result = RegOpenKeyEx(key, s, 0, KEY_READ|KEY_WOW64_64KEY, &key); For a full explanation: 32-bit and 64-bit Application Data in the Registry
On an x64 machine, here is an example of how to access the 32-bit view of the registry: using (var view32 = RegistryKey.OpenBaseKey(RegistryHive.CurrentUser, RegistryView.Registry32)) { using (var clsid32 = view32.OpenSubKey(@”Software\Classes\CLSID\”, false)) { // actually accessing Wow6432Node } } … as compared to… using (var view64 = RegistryKey.OpenBaseKey(RegistryHive.CurrentUser, RegistryView.Registry64)) { using (var clsid64 = view64.OpenSubKey(@”Software\Classes\CLSID\”, true)) … Read more
You can use RegistryKey.OpenBaseKey to solve this problem: var baseReg = RegistryKey.OpenBaseKey(RegistryHive.LocalMachine, RegistryView.Registry64); var reg = baseReg.CreateSubKey(“Software\\Test”);
If you can change the target .Net version to v4, then you can use the new OpenBaseKey function e.g. RegistryKey registryKey; if (Environment.Is64BitOperatingSystem == true) { registryKey = RegistryKey.OpenBaseKey(Microsoft.Win32.RegistryHive.LocalMachine, RegistryView.Registry64); } else { registryKey = RegistryKey.OpenBaseKey(Microsoft.Win32.RegistryHive.LocalMachine, RegistryView.Registry32); }
2 GB by default. If the application is large address space aware (linked with /LARGEADDRESSAWARE), it gets 4 GB (not 3 GB, see http://msdn.microsoft.com/en-us/library/aa366778.aspx) They’re still limited to 2 GB since many application depends on the top bit of pointers to be zero.