Registry calls return wrong values - how to fix?

Question

Here is the code used to open the key (all the variations shown produce the same behaviour)
bool Win32_OpenKey( const HKEY uPlaceInRegistry, HKEY& xKey, const char* const szKeyName, const bool bReadOnly = false )
// SE: make sure key exists
// SE - NOTE: this is deprecated. it worked fine, but suddenly doesnt :(
// so i have replaced it with the following line
//const bool bOpened = RegOpenKey( uPlaceInRegistry, szKeyName, &xKey ) == ERROR_SUCCESS;
const bool bOpened = RegOpenKeyEx( uPlaceInRegistry, szKeyName, 0,
bReadOnly ? KEY_QUERY_VALUE : KEY_ALL_ACCESS, &xKey ) == ERROR_SUCCESS;
bool bCreated = false;
if( !bOpened )
// SE - NOTE: this is deprecated. it worked fine, but suddenly doesnt :(
// the Licensor will create keys except in the case where we upgrade a user from
// an old license... so now using the Ex version in hopes it magically works.
//bCreated = RegCreateKey( uPlaceInRegistry, szKeyName, &xKey ) == ERROR_SUCCESS;
DWORD uDisposition = -1;
bCreated = ( RegCreateKeyEx( uPlaceInRegistry, szKeyName, 0, 0,
REG_OPTION_NON_VOLATILE, bReadOnly ? KEY_QUERY_VALUE : KEY_ALL_ACCESS,
0, &xKey, &uDisposition )
== ERROR_SUCCESS );
return bOpened || bCreated;
Here is where the values are queried.
unsigned int uMagic = 0;
unsigned long uType = 0xFFFFFFFF;
unsigned long uSize = sizeof( unsigned int );
//long err = RegGetValue( xKey, 0, "Magic", RRF_RT_DWORD, &uType, &uActivated, &uSize );
uType = REG_DWORD;
long err = RegQueryValueEx( xKey, "Magic", 0, &uType, reinterpret_cast< LPBYTE >( &uMagic ), &uSize );
if( (err == ERROR_SUCCESS) && ( uType == REG_DWORD ) && ( uSize == sizeof( unsigned int ) ) )
unsigned long long ullReadStartDate = 0;
uSize = sizeof( unsigned long long );
err = RegGetValue( xKey, 0, "Number", RRF_RT_QWORD, &uType, &ullReadStartDate, &uSize );
if( (err == ERROR_SUCCESS) && ( uType == REG_QWORD ) && ( uSize == sizeof( unsigned long long ) ) )
The values that are returned do not match the registry.
In fact the values returned are values that we never would have written either. The zero is fishy because maybe it indicates bad behaviour. The messed up time_t value is even more confusing... it comes from a more than 30 days ago, which is around the time
when I first started working on this code.
To make a guess I am getting back an ancient version of the key values which is somehow preserved and accessible but can not be seen in regedit. I have no idea why this is suddenly happening either - this code (before my commented changes were made) worked
exactly as expected for a few weeks now.
Slightly unrelated but it also seems that a standard user can not write to HKCU in our repeatable tests. This seems slightly crazy as well... should I just not be using the registry? It never seemed like a good idea, but I have done it to try and fit the
platform way of doing things after hitting lots of problems with naive use of files...

Answer 1

thanks for the tips. will probably come in handy in the future. :)
it turned out to be permissions and bad documentation in my case. the virtual store thing was not writing to where the docs say it should, and so something was lingering somewhere i couldn't find in the right place under any of the top level registry keys.
maybe there is some other place where it has gone in the registry that i am just not finding the documentation for...
my ultimate fix was to use a file in ProgramData :)
I figured I'd try and do it 'the MS way' and use the registry. what a terrible idea that turned out to be, since I guess its no longer the MS way given how riddled with backwards compatibility hacks it seems to be...