How does CurrentControlSet differ from HKEY_CURRENT_USER

[Tom F 83]

Not specifically a Delphi question:

I wrote a program that reads a registry entry of someone else's program, "ProgramX".

 

When I install ProgramX on my Win10 machine, I find ProgamX's registry entries where I expect them:

 

Computer\HKEY_CURRENT_USER\SOFTWARE\CompanyName\ProgramX.

However, when a user of my program installed ProgramX on their computer, my program doesn't find that registry entry.

 

The user tells me he used RegEdit to find  the entries here:

 

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\StorageDevicePolicies\SOFTWARE\CompanyName\ProgramX.

 

The user is 12 time zones away from me and speaks a different language, so it is difficult to communicate with him.

 

I have googled "CurrentControlSet" but am unable to find anything that explains why CurrentControlSet exists. Is it created explicitly by an application, or is it created automatically by Windows, and why? Is it only created on certain machines, perhaps when there is more than one Windows login?

 

Is reasonable for my program to check the HKEY_CURRENT_USER path for the key and if not found, try to find the registry entries in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet path?

[Remy Lebeau 1392]

On 7/21/2022 at 9:08 AM, Tom F said:

When I install ProgramX on my Win10 machine, I find ProgamX's registry entries where I expect them:

Computer\HKEY_CURRENT_USER\SOFTWARE\CompanyName\ProgramX.

Yes, that is where I would expect them, too.

Quote

The user tells me he used RegEdit to find  the entries here:

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\StorageDevicePolicies\SOFTWARE\CompanyName\ProgramX.

That is absolutely wrong.  Application settings do not belong there.  That is likely a bug in the program.

Quote

I have googled "CurrentControlSet" but am unable to find anything that explains why CurrentControlSet exists. Is it created explicitly by an application, or is it created automatically by Windows, and why?

It is a system-managed key, and it holds system settings, hardware configurations, service setups, etc.  Note that HKLM\SYSTEM likely contains other keys ControlSet001, ControlSet002, etc. Those are like backups/previous versions of CurrentControlSet.  If something goes wrong with the current settings, Windows has something it can roll back to.

Quote

Is it only created on certain machines, perhaps when there is more than one Windows login?

Every computer has a CurrentControlSet key.  But not every computer has a StorageDevicePolicies key (mine doesn't).

Quote

Is reasonable for my program to check the HKEY_CURRENT_USER path for the key and if not found, try to find the registry entries in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet path?

Absolutely not.  You should contact the program author and explain the issue so they can fix it.

Edited July 22, 2022 by Remy Lebeau

[Tom F 83]

THANK YOU. Thank you, Remy.  As usual, you're a fount of information!  I appreciate you're having taken the time to answer this question. And of course I also appreciate all the contributions you have made over the years with your software and with your participation in the forums.

Insert other media

[Fr0sT.Brutal 900]

HKCU => "Install for me only"

HKLM => "Install for everyone"

 

IDK why the settings have gone to \SYSTEM\CurrentControlSet though - I'd expect them in \Software. Probably W10 have changed things a bit

[Remy Lebeau 1392]

10 hours ago, Fr0sT.Brutal said:

IDK why the settings have gone to \SYSTEM\CurrentControlSet though - I'd expect them in \Software. Probably W10 have changed things a bit

I still think it is likely a bug in the program, not in Windows itself.  Like if the program had opened the StorageDevicePolicies key for some unrelated purpose, and then accidentally used that opened HKEY handle as a base when writing its settings to its own subkey rather than using the predefined base HKLM handle.

Edited July 25, 2022 by Remy Lebeau

[aehimself 396]

I'd doublecheck every registry operation and make sure every .OpenKey has a .CloseKey, and every TRegistry.Create has a .Free in the Finally block.

I had my share of issues when I wanted to reuse the same TRegistry object within a method to perform different writes. I ended up creating it and freeing it up after each "task".

[KodeZwerg 54]

Since I do not know how your registry code looks like, may it be a 32/64bit issue?

//for 32bit
  Reg := TRegistry.Create(KEY_READ or KEY_WOW64_32KEY);
//for 64bit
  Reg := TRegistry.Create(KEY_READ or KEY_WOW64_64KEY);