>Using the RegOpenKeyEx windows API to read registry entries:
>
>

>#DEFINE HKEY_CURRENT_USER   0x80000001
>#DEFINE HKEY_LOCAL_MACHINE  0x80000002
>#DEFINE HKEY_USERS          0x80000003
>#DEFINE KEY_READ            0x20019
>
>DECLARE INTEGER RegOpenKeyEx IN advapi32;
>        INTEGER   hKey,;
>        STRING    lpSubKey,;
>        INTEGER   ulOptions,;
>        INTEGER   samDesired,;
>        INTEGER @ phkResult
>
>LOCAL nHKey,lcSubKey
>nHKey=0
>lcSubKey="SOFTWARE\ATI"
>? RegOpenKeyEx(HKEY_LOCAL_MACHINE,lcSubKey,0,KEY_READ,@nhKey)
>

>
>See attached screenshot. It succeeds and fails for no discernible reason:
>
>lcSubKey="SOFTWARE\2X" returns 2 - failure
>lcSubKey="SOFTWARE\Adobe" returns 0 - Success
>lcSubKey="SOFTWARE\AGEIA Technologies" returns 0 - Success
>lcSubKey="SOFTWARE\AMD" returns 2 - failure
>lcSubKey="SOFTWARE\ATI" returns 0 - Success
>lcSubKey="SOFTWARE\ATI Technologies" returns 0 - Success
>
>and so on and so on. I've verified these registry entries are properly inheriting permissions.
>
>Curiously, if I instead use the HKEY_CURRENT_USER hive and query that section of the registry the RegOpenKeyEx function always returns 0 Success.
>
>
>I'm at a loss. Any ideas?


It turns out that when a 32bit application is accessing the registry on a 64bit system, when the app specifies SOFTWARE\Something the RegOpenKeyEx is actually returning SOFTWARE\Wow6432Node\Something

More info here:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724878(v=vs.85).aspx

See KEY_WOW64_32KEY and KEY_WOW64_64KEY