HKCU randomly uses Users registry entry

Public support forum for peer to peer support with related to the Visual Objects and Vulcan.NET products
ic2
Posts: 1987
Joined: Sun Feb 28, 2016 11:30 pm
Location: Holland

Re: HKCU randomly uses Users registry entry

Post by ic2 »

Hello Wolfgang,
wriedmann wrote: Wed Feb 05, 2025 4:28 am you do need a default value to understand if the expected value is there.
If you pass in for example "$%&" as default value and the call returns that string, you can be sure that the value is not there.
I think you still misunderstand what I wrote.
In a sense I have a default value: an empty string. I read the registry value and get a non empty string - so using your recommendation I would conclude it worked. But I got that string (in seemingly random situations) from the users hive instead of HKCU. And this is a critically different (non empty) value than the one I asked for, from HKCU.

Dick
Jamal
Posts: 360
Joined: Mon Jul 03, 2017 7:02 pm

Re: HKCU randomly uses Users registry entry

Post by Jamal »

Dick,

Since you have not provided the class source code, it does not really help to find what is wrong with your situation.

Anyway, an alternative is to use an INI file where you encrypt the license info and forget about using the registry.
ic2
Posts: 1987
Joined: Sun Feb 28, 2016 11:30 pm
Location: Holland

Re: HKCU randomly uses Users registry entry

Post by ic2 »

Hello Jamal,
Jamal wrote: Thu Feb 06, 2025 5:01 pm Since you have not provided the class source code, it does not really help to find what is wrong with your situation.
Thanks for your message. I see that I actually defined a subclass and use several methods from which I think they are from the SDK somewhere so I looked up the code.

This is what I use in the program:

Code: Select all

LOCAL oreg:=Class_HKCU{} AS Class_HKCU																				
cTerminate:=oreg:GetString("\Software\IC2\iConnect","SomeValue")
And this is the class + init + the GetString code. I don't see anything which could explain the program retrieving values from anywhere else than HKCU, which almost always works like it should, except (sometimes I think) on 1 server with freshly added users. But maybe you directly see something in the code which could cause it?

Dick

Code: Select all

CLASS Class_HKCU INHERIT _Class_Registry
	// Subclass for HKEY_CURRENT_USER
CLASS _Class_Registry

    DECLARE ACCESS hKey
    DECLARE ASSIGN hKey

    DECLARE ACCESS Working_SubKey
    DECLARE ASSIGN Working_SubKey

    DECLARE METHOD Build_Full_SubKey

    DECLARE METHOD GetString
    DECLARE METHOD GetInt

	DECLARE METHOD CreateKey
	DECLARE METHOD CreateSubKey
    DECLARE METHOD WriteString
    DECLARE METHOD WriteInt

    DECLARE METHOD Get_SubKey_ValueNames

    DECLARE METHOD DeleteValue
    DECLARE METHOD DeleteValueName
    DECLARE METHOD DeleteSubKey

    DECLARE METHOD Flush

    PROTECT Working_SKey    AS STRING
    PROTECT s_Class           AS STRING
    EXPORT LastError         AS LONG
    PROTECT hKeyP              AS PTR

METHOD Init CLASS Class_HKCU
	SUPER:Init()
	SUPER:hKey := HKEY_CURRENT_USER
RETURN SELF

METHOD GetString( s_SubKey AS STRING, s_ValueName AS STRING ) AS STRING STRICT CLASS _Class_Registry

    // Returns a value as a STRING
    //  -- regardless of the TYPE of the data
    //  -- maximum string length is 2047 characters
    // If s_ValueName is a NULL_STRING (or "") then the "Default"
    //  data for the subkey is returned.

    LOCAL li_Error        := 0        AS LONG
    LOCAL s_Return        := ""       AS STRING
    LOCAL psz_Value       := NULL_PSZ AS PSZ
    LOCAL dw_KeyHandle    := 0        AS DWORD
    LOCAL dw_ValueType    := 0        AS DWORD
    LOCAL dw_ValueLen     := 0        AS DWORD
    LOCAL s_Full_SubKey   := NULL_STRING AS STRING

    s_Full_SubKey := SELF:Build_Full_SubKey( s_SubKey )

    li_Error := RegOpenKeyEx(                   ;
                    SELF:hKeyP,                  ;  //  hKeyP AS PTR
                    String2Psz( s_Full_SubKey ),;  //  lpSubKey AS PSZ
                    0,                          ;  //  ulOPtions AS DWORD
                    KEY_QUERY_VALUE,            ;  //  samDesired AS DWORD
                    @dw_KeyHandle               ;  //  phkResult AS PTR
                    )                              //  AS LONG PASCAL:ADVAPI32.RegOpenKeyExA#149

    IF ( li_Error == ERROR_SUCCESS )

       psz_Value   := StringAlloc( Space( 2048 ) )
       dw_ValueLen := PszLen( psz_Value )

       li_Error := RegQueryValueEx(             ;
                    dw_KeyHandle,               ;  //  hKeyP AS PTR
                    String2Psz( s_ValueName ),  ;  //  lpValueName AS PSZ
                    0,                          ;  //  lpReserved AS  DWORD PTR
                    @dw_ValueType,              ;  //  lpType AS DWORD PTR
                    psz_Value,                  ;  //  lpData AS BYTE PTR
                    @dw_ValueLen                ;  //  lpcbData AS DWORD PTR
                    )                              //  AS LONG PASCAL:ADVAPI32.RegQueryValueExA#157

       RegCloseKey( dw_KeyHandle )

       IF ( dw_ValueType == REG_SZ )

           s_Return := Psz2String( psz_Value )

       ENDIF

       MemFree( psz_Value )

    ENDIF

    SELF:LastError := li_Error

    RETURN Trim( s_Return )
Jamal
Posts: 360
Joined: Mon Jul 03, 2017 7:02 pm

Re: HKCU randomly uses Users registry entry

Post by Jamal »

The samDesired like I suspected is not set to the correct value for 64bit Windows environment. Also the access rights are possibly affecting some of the servers at client's machines.

In the GetString method, try to change to KEY_QUERY_VALUE to KEY_ALL_ACCESS + KEY_WOW64_64KEY

FYI:

KEY_ALL_ACCESS (0xF003F)
Combines the STANDARD_RIGHTS_REQUIRED, KEY_QUERY_VALUE, KEY_SET_VALUE, KEY_CREATE_SUB_KEY, KEY_ENUMERATE_SUB_KEYS, KEY_NOTIFY, and KEY_CREATE_LINK access rights.

KEY_WOW64_64KEY (0x0100)
Indicates that an application on 64-bit Windows should operate on the 64-bit registry view. This flag is ignored by 32-bit Windows. For more information, see Accessing an Alternate Registry View.
This flag must be combined using the OR operator with the other flags in this table that either query or access registry values.

HTH,
Jamal
Post Reply