Re: Help reading registry key

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

From: Michael J. Salamone [eMVP] (mikesa#at#entrek#dot#com)
Date: 04/22/04 

Date: Thu, 22 Apr 2004 07:17:21 -0700

Well, actually you have two problems.

First, buf is set to a registry key, not a value, so you are querying a
value that does not exist. That's the ERROR_INVALID_PARAMETER you are
seeing. Your buffer should be coming back with the same trash that was in
it before the call (i.e. it should be untouched).

Second (potential) problem is you may not get everything back. The API
takes BYTE buffers, and thus the size of the buffer must be the number of
bytes (MAX_PATH * sizeof(TCHAR) in your case). It will write a UNICODE
string to that buffer, and return the number of *bytes*, not number of
characters written.

Anyway, you are setting nDataSize to nMaxKeyNameSize (or MAX_PATH - which is
260). That's half the number of bytes the buffer actually is. So it would
write at most MAX_PATH/2 UNCODE characters (including NULL terminator) which
could cause truncation. And you'd get something like
ERROR_INSUFFICIENT_BUFFER or ERROR_BUFFER_OVERFLOW (I can't remember the
exact code). 

-- 
Michael Salamone [eMVP]
Entrek Software, Inc.
www.entrek.com
"Mike Welch" <michaelw@techemail.com> wrote in message
news:b3ce3d49.0404220356.4afc3a3e@posting.google.com...
> Overview: Probably a pointer or Unicode related problem...
>
> I've searched and searched help and google for something that would
> lead me to what I'm doing wrong here.  I'm trying to enumerate all of
> the active drivers and get the value of the driver "Name" key (e.g.,
> <HKLM>Drivers\Active\03\Name).  So close...but I'm not getting my data
> back (which would be for example "COM1:").
>
> Below is a segment of code.  I've fought with this unicode stuff until
> it's starting to make sense, which means something is _really_ wrong
> :)
>
> I'll assume you know about enumering a registry key so I won't detail
> that.
>
> Possible problem: I'm passing a fixed length buffer (array of char)
> in.  Could it be that it has to be dynamically allocated to just the
> right size?  That doesn't make sense as long as the result isn't too
> big, which it isn't.
>
> HKEY hkHandle;
> TCHAR buf[nMaxKeyNameSize]; <nMaxKeyNameSize = MAX_PATH>
> LONG Rx;
>
> Rx = ::RegOpenKeyEx(HKEY_LOCAL_MACHINE, cRegKeyActive, 0, 0,
> &hkHandle);
> if (Rx != ERROR_SUCCESS) {
>    AfxMessageBox(TEXT("DOHHHH!"));   // usability?
>    return;
> }
>
> TCHAR lpstrName[nMaxKeyNameSize];
> TCHAR lpstrClass[nMaxClassSize];
> TCHAR lpstrNameValue[nMaxKeyNameSize];
>
> for (int i = 0;;i++) {
>    DWORD nNameSize = nMaxKeyNameSize;
>    DWORD nClassSize = nMaxClassSize;
>
>    LONG Rx = ::RegEnumKeyEx(hkHandle, i, lpstrName, &nNameSize, 0,
> lpstrClass, &nClassSize, 0);
>
>    if (Rx == ERROR_NO_MORE_ITEMS) {
>       AfxMessageBox(TEXT("End of list"));
>       break;
>    }
>
>    // Build, for example: "Drivers\\Active\\03"
>    // note: this looks right in the debugger when executed
>    swprintf(&buf[0], _T("%s%s%s"), cRegKeyActive, _T("\\"),
> lpstrName);
>
>    HKEY hkFetchName;
>    Rx = ::RegOpenKeyEx(HKEY_LOCAL_MACHINE, buf, 0, 0, &hkFetchName);
>    if (Rx != ERROR_SUCCESS) {
>       AfxMessageBox(TEXT("Error opening for name key"));
>       return;
>    }
>
> // ** HERE IS WHERE IT DIES *** everything prior worked
>
>    DWORD nType = REG_SZ;
>    DWORD nDataSize = nMaxKeyNameSize;
>
>    Rx = ::RegQueryValueEx(
>       hkFetchName,
>       buf,
>       0,
>       &nType,
>       (LPBYTE)lpstrNameValue,  // <===== WHAT IS WRONG WITH THIS???
>       &nDataSize
>    );
>
> At this point, Rx is 87 (error) and what's coming back in
> lpstrNameValue is apparent trash.  I've finangled around with
> lpstrNameValue about every way I can think of.  Should it NOT be
> unicode?  I tried byte types too....
>
>    if (Rx != ERROR_SUCCESS) {
>       AfxHardResetWithFinalMessage(TEXT("NAHHHH NAHHHHH!"));  // ;-)
>       return;
>    }
>    RegCloseKey(hkFetchName);
>
>    ...
>
> Thanks!
>
> Signed,
>
> Groggy in Dallas
Quantcast