HKCU randomly uses Users registry entry

[ic2]

Our program stores and retrieves some license info, fed by data on our website, in the registry, as follows:

oreg:GetString("\Software\IC2\iConnect","SomeValue") where oReg = HKCU.

This SomeValue has returned values which were simply not stored there. Often for new users, the system manager of the client resolved it by completely recreating their Windows profile on the server. Which helped (except today) but did not make sense to me.

Today I found some info which led to the solution. For the new user, for which, as written, even the profile recreation failed to solve it, the registry info was retrieved from

Computer\HKEY_USERS\S-1-5-21-481379047-3217073560-4354130625-1137\Software\IC2\iConnect

This hive apparently appears to be a "convenient shortcut provided by Windows because it's so useful to get the keys for the currently logged in user." I read on Stackoverflow. Except that the values there don't match what is stored in HKCU - SomeValue in the above hive actually read a critical wrong value, different from the one in HKCU, preventing the user to enter my program.

Does this sound familiar to someone? How can I prevent Windows to read wrong values for some (new I think) users and just read where I programmed to read?

Dick

[Jamal]

Provide a sample AEF and include any registry lib you are using to set and get the reg key values.

[wriedmann]

Hi Dick,
Windows has two "special" profiles: the "default user" and the "all users" profile. It seems that in some cases the "default user" profile registry key has been read.
Instead of directly reading your value I would check if the registry tree exists before reading important data, or even better, always always always submit a default value in your call, so if the default value, maybe a thing like "$-&?=()" is returned, you know that the value does not exists.
Wolfgang

[ic2]

Hello Wolfgang, Jamal,

The problem is: the HKCU tree does exist but for a reason I don't know it reads from the users hive for some users, especially when newly added. I found out that my program was not reading what was in the HKCU hive when the client's system administrator sent a screenshot, from the users HKCU key we use, where the critical value was empty while for sure the program was reading another value. That of the Use hive.

The code is simple and works fine for all other users on the same server:

Code: Select all

LOCAL oreg:=Class_HKCU{} AS Class_HKCU
cVar:=oreg:GetString("\Software\IC2\iConnect","SomeValue")

I read that the user hive was some sort of alias for the HKCU hive. So I would either expect those two to be in sync, or expect that Windows let me read the registry hive I programmed it to read. Not that it it, seemingly random, chooses one with incorrect values.

Dick

[wriedmann]

Hi Dick,
maybe you have not understand what I meant: always pass in also a default value.
This manner you can check if the registry value exists or does not.
If you don't pass in a default value you are pressing Windows to return some other value if the value itself is not found.
Wolfgang

[Jamal]

Dick,

You may want to remove the slash before the Software in cVar := oreg:GetString("\Software\IC2\iConnect","SomeValue")

However, I suspect you are using and old Class_HKCU{} class that's not setting the security access mask: KEY_ALL_ACCESS + KEY_WOW64_64KEY.

This is why I asked you to attach your class code.

[ArneOrtlinghaus]

In the past we had also problems making stable functionality where registry settings (local machine and or current user) are used. Now in general the program tries to read/write only some necessary parts from the registry, for example the size and display options for the main window that cannot be changed after opening the window. Also everything that is necessary for the "probable user who wants to login into the program". Everything else is stored in the database or in some cases in inifiles.

For some of these settings the program compares the initial registry settings with the database settings of the logged in user and writes the differences into the registry and restarts the program.

Arne

[ic2]

@Wolfgang: I understood your answer. I did not need a default value, as I did get a value which seemed valid but it isn't as it was read from the wrong hive.

@Jamal: on my Pc I also get the value of string SomeValue without the slash. Not sure if it solves the issue of reading from the wrong hive, but I will probably see that when they add the next user!

@Arne: you are certainly right that everything which does not need some Windows function is more reliable than when it does. Storing settings in your own setting files is what we do. This functionality is dealing with checking license information and storing that in the registry prevents a user from copying previous (program) files to bypass these check results. Also it has worked for years on many servers, so I prefer not to fully rewrite this for one server which acts abnormal.

Let's wait and see if removing the slash prevents the problem and I thank you all for the replies.

Dick

[wriedmann]

Hi Dick,
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.
Wolfgang

[FFF]

But that doesn't help, as he actually gets another value back.