Why does the RegQueryValueEx() function return ERROR_FILE_NOT_FOUND while trying to read from a registry key?

Question

System: Windows 7 32bit
Language: C++

I have tried to access register HKEY_LOCAL_MACHINE\\HARDWARE\\DEVICEMAP\\Scsi\\Scsi Port 0, key Driver (type REG_SZ) -- no problem.

The same for reading from HKEY_LOCAL_MACHINE\\HARDWARE\\DEVICEMAP\\SERIALCOMM, all keys (types REG_SZ) got slashes, for example \Device\Serial0.

While reading such keys it always returns 2 (no such file) with following example code:

HKEY hKey = 0;
DWORD dwType = REG_SZ;
char buf[255] = {0};
DWORD dwBufSize = sizeof(buf);

if( RegOpenKeyEx( HKEY_LOCAL_MACHINE, TEXT("HARDWARE\\DEVICEMAP\\SERIALCOMM"), 0, KEY_QUERY_VALUE, &hKey ) == ERROR_SUCCESS ) 
{
  auto ret = RegQueryValueEx( hKey, TEXT("\Device\Serial0"), 0, &dwType, (LPBYTE)buf, &dwBufSize );
  // ret always == 2 for key with slashes
--- CUT ---

What is the proper way to read key values with slashes in name?

Above has been properly answered by Cody Gray.

Below another issue.

Im getting the same problem when Im using variable instead of a text string.
Iv considered both approaches with single and double slashes:

HKEY hKey = 0;
DWORD keyType = REG_SZ;
TCHAR buf[255] = {0};
DWORD bufSize = sizeof(buf);

QSettings winReg("HKEY_LOCAL_MACHINE\\HARDWARE\\DEVICEMAP\\SERIALCOMM", QSettings::NativeFormat);
auto comsKey = winReg.allKeys();

FOREACH( auto com, comsKey )
{
  // FOREACH - boost macro
  // comsKey = QList<QString> (list of key names) [from Qt framework]
  // com = QString (single key name) [from Qt framework]
  if( RegOpenKeyEx(HKEY_LOCAL_MACHINE, TEXT("HARDWARE\\DEVICEMAP\\SERIALCOMM"), 0, KEY_QUERY_VALUE, &hKey ) == ERROR_SUCCESS )
  {
    wchar_t* keyw = new wchar_t();
    //com.replace("/", "\\\\"); <- checked both variants commented and not commented; com == /Device/Serial0 so im converting to \\Device\\Serial0
    int size = com.size();
    mbstowcs( keyw, com.toStdString().data(), size );
    //auto ret = RegQueryValueEx( hKey, TEXT("\\Device\\Serial0"), 0, &keyType, (LPBYTE)buf, &bufSize ); // <- this works!
    auto ret = RegQueryValueExW( hKey, (LPCWSTR)&keyw, 0, &keyType, (LPBYTE)buf, &bufSize ); // <- this one not works!

I have tried all variants with "\Device..", "/Device", "\Device", etc.

@Werner, no, the `RegQueryValueEx` function *only* queries the value of a registry key. Values are the name/data pairs stored within keys. So you can't pass it a nested path of keys as you describe because values don't have paths. Admittedly, the terminology is quite confusing, Raymond Chen attempted to explain it [here](http://blogs.msdn.com/b/oldnewthing/archive/2009/02/04/9394113.aspx). — Cody Gray - on strike, Dec 21 '11 at 12:11
[`RegGetValue()`](https://learn.microsoft.com/en-us/windows/desktop/api/winreg/nf-winreg-reggetvaluew), on the other hand, can query a value of a nested subkey. — Remy Lebeau, Apr 30 '19 at 00:17

Cody Gray - on strike · Accepted Answer · 2011-12-21T13:54:30.097

8

You have to escape the slashes, just like you did in the first line...

if( RegOpenKeyEx( HKEY_LOCAL_MACHINE, TEXT("HARDWARE\\DEVICEMAP\\SERIALCOMM"), 0, KEY_QUERY_VALUE, &hKey ) == ERROR_SUCCESS ) 
{
  auto ret = RegQueryValueEx( hKey, TEXT("\\Device\\Serial0"), 0, &dwType, (LPBYTE)buf, &dwBufSize );
  // ret always == 2 for key with slashes

If you don't, the RegQueryValueEx function can't find the specified key, and it returns ERROR_FILE_NOT_FOUND (== 2).

But there's another problem. You should be declaring the buffer array as type wchar_t (or TCHAR), rather than char:

TCHAR buf[255] = {0};

Otherwise, the RegQueryValueEx function is going to attempt to fill the array with a Unicode string read from the specified registry key, and you're going to get something unreadable.

edited Dec 21 '11 at 13:54

answered Dec 21 '11 at 11:21

Cody Gray - on strike

239,200
50
490
574

1

buf should be declared as TCHAR, not as wchar_t. ReqQueryValueEx does not care about how buf is declared, the returned value depends on whether RegQueryValueExA or RegQueryValueExW is called. – Werner Henze Dec 21 '11 at 11:59
@Werner: Yes, that's technically true. But Windows applications haven't been compiled as ANSI (non-Unicode) for over 10 years. A lot of people don't care to use the macros anymore, and it's hard to blame them. – Cody Gray - on strike Dec 21 '11 at 12:05
Your answer is rather optimized to give the OP a hard time. C++11 syntax, WMI is quite unfriendly in C++, serial ports are not plug-and-play devices. – Hans Passant Dec 21 '11 at 12:36
@Hans: I copied the `auto` syntax from the original question; I assume he's not using Microsoft's compiler. What would you suggest as a better approach than WMI? I'm almost certain that reading this from the registry is not the right way. – Cody Gray - on strike Dec 21 '11 at 13:15
2

Reading that registry key to discover COM port names is the prescribed way. The .NET SerialPort.GetPortNames() method uses it for example. – Hans Passant Dec 21 '11 at 13:28
@CodyGray: auto syntax is compatibile with Microsoft Visual Studio 2010 compiler. – killdaclick Dec 22 '11 at 13:26

Why does the RegQueryValueEx() function return ERROR_FILE_NOT_FOUND while trying to read from a registry key?

1 Answers1