cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
gknierim
Level 6

RegDBKeyExist Fails

We cannot figure out why this fails:

if (RegDBKeyExist(SQL_BASE_PATH) = 1) then...

where SQL_BASE_PATH = "SOFTWARE\\Microsoft\\Microsoft SQL Server\\Instance Names\\SQL"

We are calling RegDBSetDefaultRoot(HKEY_LOCAL_MACHINE); before this.

This is on Windows Server 2008 R2 (64 Bit). I have tried the same code on Windows Server 2008 (32 Bit) and it can find the Instance Names\\SQL key. We have tried setting REGDB_OPTIONS to look in the 64 bit part of the registry but it still fails.

We have tried various other registry keys of length and some work and some do not. We have tried just going up to the Instance Names in the string and it fails. If we just go up to Microsoft SQL Server, it works.

Keys that work (return 1):
SOFTWARE\\Microsoft\\Microsoft SQL Server
SOFTWARE\\Microsoft\\Microsoft SQL Server\\100
SOFTWARE\\Microsoft\\Microsoft SQL Server\\RefCount
SOFTWARE\\Microsoft\\NET Framework Setup\\NDP\\v4\\Full
SOFTWARE\\Microsoft\\NET Framework Setup\\NDP\\v4\\Full\\1033

Keys that don't work (return < 0):
SOFTWARE\\Microsoft\\Microsoft SQL Server\\Instance Names
SOFTWARE\\Microsoft\\Microsoft SQL Server\\Instance Names\\SQL
SOFTWARE\\Microsoft\\Microsoft SQL Server\\ExceptionMessageBox
SOFTWARE\\Microsoft\\Microsoft SQL Server\\RefCount\\SNAC10


We have checked the permission on the various keys and they all have the same permissions. We have checked whether spaces might be an issue but they are not. it isn't a length issue as we have tried keys that are longer than above and they work.

Does anyone have any ideas?

Thanks,
Greg
Labels (1)
0 Kudos
(4) Replies
gbaltazar
Level 6

On 64bit systems, you have to use

REGDB_OPTIONS = REGDB_OPTIONS | REGDB_OPTION_WOW64_64KEY

if you want to check the 64bit hives. Otherwise, the current check will look at the syswow64 instance of HKLM.
0 Kudos
gknierim
Level 6

Well, we aren't checking the 64 bit part of the registry which is why I wasn't using it. However, when adding the line below BEFORE setting the HKEY_LOCAL_MACHINE, then it did find it.

So it appears that it searches the 64 Bit part of the registry by default unless you add the line below. Correct?

If so, this is opposite of what the documentation says:

When you enable the REGDB_OPTION_WOW64_64KEY option, this affects where registry entries from registry sets are created. For example, if this option is enabled when you call the CreateRegistrySet function, the registry set is created in the 64-bit part of the registry. It is recommended that you enable this option for the specific 64-bit registry sets you want to install, then disable the option so other registry entries or sets are not incorrectly created in the 64-bit part of the registry.

Anyway, it is working now by adding the REGDB_OPTIONS line below.
0 Kudos
rrinblue22
Level 9

I think the document is still correct.

* Native mode 64-bit programs run in Native mode and access keys and values that are stored in the following registry sub key:
HKEY_LOCAL_MACHINE\Software
* 32-bit programs run in WOW64 mode and access keys and values that are stored in the following registry sub key:
HKEY_LOCAL_MACHINE\Software\WOW6432node
0 Kudos
gknierim
Level 6

Thanks for the reply. I was thinking that the WOW6432 key was the 64 bit part of the registry. My mistake.

So, when my install project runs on a 64 bit OS, I have to enable looking in the 64 bit part of the registry. OooooK. One would think that I would need to enable looking in the 32 Bit part of the registry (if I needed to) instead of the part of the registry that matches the OS. But whatever I guess. Maybe this will get changed in future versions when 64 Bit is the norm. Maybe I'm just hoping then. I have the install project set to x64 so that is why I thought it would default to the 64 Bit part of the registry.
0 Kudos