RegistryReadKey on x64 systems

[migro]

I got a little bit confused reading registry values from x64 systems using the RegistryReadKey function.

When I use the function like this:

Code: Select all

RegistryReadKey>HKEY_LOCAL_MACHINE,SOFTWARE\Microsoft\Microsoft SQL Server\100\Tools\ClientSetup,Path,strSQLcmd100

The function won't return the value from the above key it returns the Value from the wow6432Node:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Microsoft SQL Server\100\Tools\ClientSetup

Does anybody know how to avoid this behavior?

[migro]

I found that the problem is with what’s called “Registry Redirection and Reflectionâ€

[Marcus Tettmar]

It would appear so:

http://msdn.microsoft.com/en-us/library ... S.85).aspx

[migro]

Hi Marcus,

thanks for the Info.

Are You sure its the right one? I understand Registry reflection copies specific registry keys and values between the two views. But we only need to read values from the x64 section of the registry.

Also don't have any idea how to use C++ code in MacroScheduler.
Should it be used like this?

Code: Select all

LibFunc>Advapi32,RegDisableReflectionKey( __in  HKEY hBase),result,0

and after reading the registry:

LibFunc>Advapi32,RegEnableReflectionKey( __in  HKEY hBase),result,0

But how do I get a handle to the key?
Can You please provide us with a little sample?

[Marcus Tettmar]

Perhaps it's something different - I'm not sure. I'm just reading the online MSDN docs. You could do the same.

To figure out how to use these functions in Macro Scheduler see:
http://www.mjtnet.com/blog/2009/04/17/w ... functions/

[migro]

Reading several MSDN docs I found two related articles what makes it a little bit more clear:

http://blogs.msdn.com/cumgranosalis/arc ... Part1.aspx

This way does *not* disable redirection of 32-bit applications to 32-bit-only registry keys; it will only disable reflection.

The functions described in the following article looks more to be the right thing:

http://blogs.msdn.com/cumgranosalis/arc ... Part2.aspx

I tried it this way:

Code: Select all

LibFunc>advapi32,RegOpenKeyEx,result, HKEY_LOCAL_MACHINE, SOFTWARE\\Microsoft\\Microsoft SQL Server\\100\\Tools\\ClientSetup, 0, KEY_READ | KEY_WOW64_64KEY, hkey

and all time get the error back: "Unable to load DLL".

But even if the api call succeeds, is it then possible to access the 64-bit-only registry keys with MacroScheduler functions like "RegistryReadKey"? I don't think so.

If nobody knows a little workaround for this problem I will wait until an option variable to set the registry functions to access the 64 bit registry keys is available.

[Marcus Tettmar]

Here's the correct translation and a working example:

Code: Select all

Let>HKEY_LOCAL_MACHINE=-2147483646
Let>HKEY_CURRENT_USER=-2147483647
Let>KEY_READ=131097
Let>KEY_QUERY_VALUE=1
Let>KEY_WOW64_64KEY=256
Let>flags={%KEY_QUERY_VALUE% OR %KEY_READ% OR %KEY_WOW64_64KEY%}

Let>key=Software\Microsoft\Windows NT\CurrentVersion

LibFunc>advapi32,RegOpenKeyExA,result,HKEY_LOCAL_MACHINE,key,0,flags,ref:0
Let>hkey=result_5

Let>RRF_RT_ANY=65535
Let>buffer_SIZE=255

LibFunc>advapi32,RegGetValueA,result,hkey,,ProductId,RRF_RT_ANY,type,str:buffer,ref:255
MessageModal>ProductId: %result_6%

LibFunc>advapi32,RegCloseKey,result,hkey

Change the key and value accordingly. The above gets "ProductId" from the 64 bit registry of Windows Vista/7.

Of course if you use RegOpenKeyEx yourself then you must then continue to use LibFunc and the registry API functions to get the data - you can't use RegOpenKeyEx and then use the native registry functions. Note that in future we'll implement the ability to make the native registry functions retrieve from the 64 bit registry.

[migro]

Dear Markus,

thanks a lot for this sample. I try it out later in the evening.