32 out of 65 rated this helpful - Rate this topic

RegOpenKeyEx function

Applies to: desktop apps only

Opens the specified registry key. Note that key names are not case sensitive.

To perform transacted registry operations on a key, call the RegOpenKeyTransacted function.

Syntax

LONG WINAPI RegOpenKeyEx(
  __in        HKEY hKey,
  __in_opt    LPCTSTR lpSubKey,
  __reserved  DWORD ulOptions,
  __in        REGSAM samDesired,
  __out       PHKEY phkResult
);

Parameters

hKey [in]

A handle to an open registry key. This handle is returned by the RegCreateKeyEx or RegOpenKeyEx function, or it can be one of the following predefined keys:

HKEY_CLASSES_ROOT
HKEY_CURRENT_CONFIG
HKEY_CURRENT_USER
HKEY_LOCAL_MACHINE
HKEY_USERS
lpSubKey [in, optional]

The name of the registry subkey to be opened.

Key names are not case sensitive.

The lpSubKey parameter can be a pointer to an empty string. If lpSubKey is a pointer to an empty string and hKey is HKEY_CLASSES_ROOT, phkResult receives the same hKey handle passed into the function. Otherwise, phkResult receives a new handle to the key specified by hKey.

The lpSubKey parameter can be NULL only if hKey is one of the predefined keys. If lpSubKey is NULL and hKey is HKEY_CLASSES_ROOT, phkResult receives a new handle to the key specified by hKey. Otherwise, phkResult receives the same hKey handle passed in to the function.

For more information, see Registry Element Size Limits.

ulOptions

This parameter is reserved and must be zero.

samDesired [in]

A mask that specifies the desired access rights to the key to be opened. The function fails if the security descriptor of the key does not permit the requested access for the calling process. For more information, see Registry Key Security and Access Rights.

phkResult [out]

A pointer to a variable that receives a handle to the opened key. If the key is not one of the predefined registry keys, call the RegCloseKey function after you have finished using the handle.

Return value

If the function succeeds, the return value is ERROR_SUCCESS.

If the function fails, the return value is a nonzero error code defined in Winerror.h. You can use the FormatMessage function with the FORMAT_MESSAGE_FROM_SYSTEM flag to get a generic description of the error.

Remarks

Unlike the RegCreateKeyEx function, the RegOpenKeyEx function does not create the specified key if the key does not exist in the registry.

Certain registry operations perform access checks against the security descriptor of the key, not the access mask specified when the handle to the key was obtained. For example, even if a key is opened with a samDesired of KEY_READ, it can be used to create registry keys if the key's security descriptor permits. In contrast, the RegSetValueEx function specifically requires that the key be opened with the KEY_SET_VALUE access right.

If your service or application impersonates different users, do not use this function with HKEY_CURRENT_USER. Instead, call the RegOpenCurrentUser function.

Note that operations that access certain registry keys are redirected. For more information, see Registry Virtualization and 32-bit and 64-bit Application Data in the Registry.

Examples

For an example, see Deleting a Key with Subkeys.

Requirements

Minimum supported client

Windows 2000 Professional

Minimum supported server

Windows 2000 Server

Header

Winreg.h (include Windows.h)

Library

Advapi32.lib

DLL

Advapi32.dll

Unicode and ANSI names

RegOpenKeyExW (Unicode) and RegOpenKeyExA (ANSI)

See also

RegCloseKey
RegCreateKeyEx
RegDeleteKey
Registry Functions
Registry Overview
RegOpenKeyTransacted
RegQueryKeyEx

 

 

Send comments about this topic to Microsoft

Build date: 3/6/2012

Did you find this helpful?
(1500 characters remaining)
Community Content Add
Annotations FAQ
No mention on this page about KEY_WOW64_32KEY and when it is needed.
... or how to read a virtualized (x64) bit reg key.  You have to stumble into the link in this paragraph:

"samDesired [in]

A mask that specifies the desired access rights to the key to be opened. The function fails if the security descriptor of the key does not permit the requested access for the calling process. For more information, see Registry Key Security and Access Rights."

The function fails with FILE_NOT_FOUND when you don't add KEY_WOW64_32KEY and it's not very helpful when the key is visible in REGEDIT!


Proposed Changes to Documentation on lpSubKey [in, optional]
<RegOpenKeyEx function (Windows) - Current Documentation>

lpSubKey [in, optional]

The name of the registry subkey to be opened.
 
Key names are not case sensitive.

The lpSubKey parameter can be a pointer to an empty string. If lpSubKey is a pointer to an empty string and hKey is HKEY_CLASSES_ROOT, phkResult receives the same hKey handle passed into the function. Otherwise, phkResult receives a new handle to the key specified by hKey.

The lpSubKey parameter can be NULL only if hKey is one of the predefined keys. If lpSubKey is NULL and hKey is HKEY_CLASSES_ROOT, phkResult receives a new handle to the key specified by hKey. Otherwise, phkResult receives the same hKey handle passed in to the function.

</RegOpenKeyEx function (Windows) - Current Documentation>

<RegOpenKeyEx function (Windows) - My Proposed Revised Documentation>

lpSubKey [in, optional]

The name of the registry subkey to be opened.

Key names are not case sensitive.

The lpSubKey parameter can be a pointer to an empty string.  If lpSubKey is a pointer to an empty string and hKey is one of the predefined keys, the contents of phkResult receives a handle back to the same predefined key specified by hKey which was passed into the function.  Otherwise, for the case of a non-empty string, hReturn receives a new handle to the key specified by or corresponding to the lpSubKey string.

The lpSubKey parameter can be NULL.  If the lpSubKey parameter is NULL, the contents of phkResult receives the same hKey handle passed into the function, predefined or not.  For example. if pSubKey is NULL and hKey is HKEY_CLASSES_ROOT, one of the predefined keys, the contents of phkResult receives a handle back to the same predefined key specified by hKey which was passed into the function.  Similarly, if lpSubKey is NULL and hKey is not a predefined key, the contents of phkResult receives the same hKey handle passed into the function.

If the lpSubKey parameter specified is not empty nor NULL, it must point to a subkey name of the key identified by the hKey parameter.

</RegOpenKeyEx function (Windows) - My Proposed Revised Documentation>

Question:
What happens if you attempt to close a predefined registry key (ie. ::RegCloseKey(HKEY_CLASSES_ROOT)?  -- Nothing?  Throws an exception?  There is no mention in the documentation of what happens in this case.  If Microsoft prevents the closing of predefined keys, it would just make sense to close the key all the time.  Microsoft would then worry about whether the key is predefined or not, and trap or block a predefined key from being closed.
Symbolic links
There is an undocumented parameter: ulOptions - you can pass REG_OPTION_OPEN_LINK to this parameter, which allows you to get target of symbolic link (such as CurrentControlSet and others).
where is HKEY_CURRENT_CONFIG?
HKEY_CURRENT_CONFIG was in the 2000 MSDN.  now it's missing.  what happened?
Keys are created.
RegOpenKeyEx can, in fact,  create a non-existing key and return 0 (ERROR_SUCCESS).  LONG lRegResult = RegOpenKeyEx(HKEY_CLASSES_ROOT, m_RegSubKey, 0, KEY_QUERY_VALUE + KEY_WRITE, &hkRegistry); Successfully opens or creates m_RegSubKey under HKEY_CLASSES_ROOT.
Documentation about the lpSubKey parameter appears to be incorrect
Claimed: "The lpSubKey parameter can be NULL only if hKey is one of the predefined keys." Actual: A key is first opened to HKLM\Software, the resulting key is then passed to RegOpenKeyEx with lpSubKey as NULL. ERROR_SUCCESS is returned and the output parameter pointed to by phkResult is a new key value.

Claimed: "If lpSubKey is NULL and hKey is HKEY_CLASSES_ROOT, phkResult receives a new handle to the key specified by hKey." Actual: ERROR_SUCCESS is returned and the output parameter pointed to by phkResult is HKEY_CLASSES_ROOT (80000000).

Tested this on Windows XP and Windows 7.
unicode registry functions need the string pointers aligned on 16bit boundary
unicode registry functions like RegOpenKeyEx,RegCreateKeyEx,RegQueryValueEx need the LPCTSTR parameters aligned on a 16bit boundary otherwise error 998 is returned.

solution:

// ensure 16bit aligned string if unicode
#ifdef UNICODE
in_KeyPath = EnsureAlignedString(in_KeyPath, lv_PathBuf, 256);
#endif

// open subkey
if (RegOpenKeyEx(in_hBaseKey, in_KeyPath, 0, KEY_QUERY_VALUE, &lv_hKey) != 0)
return FALSE;

where:

TCHAR *EnsureAlignedString(TCHAR *in_Str, TCHAR *in_Buf, INT in_MaxLen)
{
// registry calls needs unicode strings to be aligned on 16bit boundaries
if ((INT)in_Str & 1)
{
// alignment is needed, copy to aligned buffer
tstrncpyeos(in_Buf, in_Str, in_MaxLen-1);

// use the buffer
return in_Buf;
}
else
{
// already aligned
return in_Str;
}
}
If combined with KEY_WOW64_32KEY this function will fail under Windows 2000
This call works perfectly in Windows 2000 and XP:

lResult = RegOpenKeyEx (hKeyRoot, lpSubKey, 0, KEY_READ, &hKey);

But this one fails in Windows 2000

lResult = RegOpenKeyEx (hKeyRoot, lpSubKey, 0, KEY_READ|KEY_WOW64_32KEY, &hKey);

The difference? The KEY_WOW64_32KEY:

http://msdn.microsoft.com/en-us/library/ms724878%28VS.85%29.aspx
samDesired is not enforced on the key, just checked on open
If you open a key with samDesired=KEY_READ, it does not prevent the HKEY returned in phkResult being used for operations that modify the registry. For example, a KEY_READ key returned by RegOpenKeyEx can be passed as the hKey argument to RegCreateKeyEx and it WILL create a key. In contrast, RegSetValueEx specifically requires a key opened with KEY_SET_VALUE rights.



RegCreateKeyEx creates intermediate keys
Note: RegCreateKeyEx("woz\foo\baz") will create the ancestor keys "woz" and "foo" if they do not exist. This means that if (for example) an .MSI installer file contains a typo for an ancestor key it will inadvertently create a whole new branch.