Registry access


New Member
I posted this previously in Rainmeter forums and was redirected here.

I am trying to use rainmeter with HWiNFO64. I am on a standard Windows user account, while HWiNFO64 requires admin privileges to run, so the registry variables do not appear under HKEY_CURRENT_USERS. I have found them under HKEY_USERS, but rainmeter does not support HKEY_USERS as a root key. Rainmeter only supports HKEY_CURRENT_CONFIG, HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE, HKEY_CLASSES_ROOT, HKEY_PERFORMANCE_DATA, HKEY_DYN_DATA as valid root keys.

The reply I got was "HWiNFO should be storing sensor data in the HKEY_LOCAL_MACHINE hive, not in HKEY_CURRENT_USER"

Are there any plans to change where HWiNFO stores its variables?
I can change storing of data into HKEY_LOCAL_MACHINE, but that would break compatibility with current Rainmeter apps.
So I'd first like to hear the opinion from Rainmeter devs if they would accept such change and are ready to make an update on their side too.
Hello Martin!
I'm not a Rainmeter dev, but I'm a Rainmeter user and skin developer, and have a lot of folks using my skins that interface with HWiNFO. Rainmeter is unaffected by where the HWiNFO data is stored. Rainmeter has a generic function to read registry data, but Rainmeter itself does not care where it is.

The issue is that, because some users are not administrators of their PCs (i.e., corporate users), when running HWiNFO (which requires elevation) and running Rainmeter (which does not require it), the skin users are unable to see the sensor data because it is not stored in their HKCU hive, it is stored in the HKCU hive of the admin user, which is not accessible.

As you noted, this will definitely break compatibility of any skins written to use HKCU, but it will not affect Rainmeter itself.
Sorry, I meant breaking compatibility with all current Rainmeter skins and those using HWiNFO with Rainmeter.
HWiNFO v7.0 introduced significant changes that affected many Rainmeter users, many had to rewrite skins. Now, a few months later, if I'd make this change many users would be again confused why things stopped working again. How can we minimize this impact if I'd make such change?
The majority of users, who have accounts that can elevate programs to admin access on their PC's with UAC won't see any benefit from this. In addition, there will have to be a search and replace done on every skin, and there are no doubt tons, that have been changed or written to use HKEY_CURRENT_USER.

Rainmeter is designed to run with a "user" approach. There is one copy of the application in C:\Program Files, but then the settings file, Rainmeter.ini, is in the user's APPDATA folder, and the skins are in the user's Documents folder.

This means that a single instance of the "program" can have very distinct settings and skins for each "user" account. I don't think it is particularly wise to put these keys in a "machine" level hive, rather than in a "user" level hive. If the computer is shared, this can only cause problems in my view.

In my view, HKEY_LOCAL_MACHINE is for settings that are always going to be the same for every user on the computer. This will not necessarily be true for the values any given user selects to output for HWiNFO.

I really don't follow how you only find the values in HKEY_USERS. HKEY_CURRENT_USER is really a "shortcut" to the values found in HKEY_USERS, under a subkey that is the numeric account ID for each user. That is why we don't support HKEY_USERS in Rainmeter, it's really kinda redundant, and HKEY_CURRENT_USER is much easier to use.

I really think perhaps you are going to want to have an account on the computer that has administrator security, or perhaps run HWiNFO as a "Scheduled Task", where you can ensure that it is started with administrator access. It's not that Rainmeter requires admin access, it doesn't. HWiNFO certainly does.

Last edited:
Well, then probably the best option would be that HWiNFO would store the same data into both HKCU and HKLM hives. This wouldn't break existing compatibility, but it would still require updating those skins that require non-admin support. Not an universal solution either.
Well, then probably the best option would be that HWiNFO would store the same data into both HKCU and HKLM hives. This wouldn't break existing compatibility, but it would still require updating those skins that require non-admin support. Not an universal solution either.

I'm fine with that, but is there a possibility of this causing excessive "thrashing" of the registry when the values are written? I just select ALL the sensor values to be output, even though I only use a few of them. I do this so I can create new skins without having to worry about messing up the index numbers. I know Windows is very good at how it physically "writes" to the registry, but doesn't writing everything twice have some possible impact?
Last edited:
I guess in theory which "hive" to write to could be a setting in HWiNFO... HKCU is the most sensible to me, and would be what I would prefer. I really wonder if this is a problem that can only be properly solved by having the user ensure that HWiNFO itself is started with admin privileges. Rainmeter does not ever require admin to read HKCU.

I guess I'm not overstanding how HWiNFO is able to write to HKEY_USERS and / or HKEY_LOCAL_MACHINE, and not HKEY_CURRENT_USER.
Last edited:
HWiNFO always needs to be started with admin elevation, it requires direct access to hardware and kernel. Problem is only when the "consumer" of its data is run as standard user as that maps to a different HKCU key.
HWiNFO always needs to be started with admin elevation, it requires direct access to hardware and kernel. Problem is only when the "consumer" of its data is run as standard user as that maps to a different HKCU key.
By "consumer", I assume you mean the "Sensors" functionality?

So what I'm hearing is that when the "sensors" are accessed by a non-admin account, the data is able to be written to HKEY_USERS, but then that is not transferred to the HKEY_CURRENT_USER hive? That semes very strange to me.
The HKEY_CURRENT_USER hive is actually just a pointer to the key located under the HKEY_USERS hive that's named the same as your security identifier. You can make changes in either location since they are one and the same.

The reason HKEY_CURRENT_USER even exists, given that it's just a reference point to another hive, is that it provides an easier way to view the information. The alternative is to find the security identifier of your account and navigate to that area of HKEY_USERS.

Again, everything seen in HKEY_CURRENT_USER pertains only to the user that's currently logged on, not any of the other users that exist on the computer. This means that each user that logs in will pull their own information from the corresponding HKEY_USERS hive, which in turn means HKEY_CURRENT_USER will be different for each user that views it.

Because of how this is set up, you could actually just navigate to a different user's security identifier in HKEY_USERS to see everything they would see in HKEY_CURRENT_USER when they're logged in.
You don't ever actually write to HKEY_CURRENT_USER, that doesn't really physically exist. that is just a "view" into the correct HKEY_USERS hive under the current account ID. I think of it like a "symlink" in the folder world...

So If I'm following this correctly, it seems like this user is running HWiNFO using some admin account, so HWiNFO has the proper access. However, when they are accessing the registry, it is as a different non-admin account, presumably with a different account ID, and so the values are not visible in that particular "pointer" view into HKEY_USERS displayed in HKEY_CURRENT_USER. If this is the case, then I guess the only answer is to allow it to write to either HKCU or HKLM with a setting of some kind in HWiNFO? I'm a tad leery of writing over 200 sensor values to two different hives once every two seconds.

We could in theory allow access to HKEY_USERS in our Registry measure, but I'd be opposed to that solution. It would mean that each skin would only work in a single unique instance. On a single machine, and with a single user identified in the skin with the numeric account ID. This is very non-Rainmeter. The skin(s) could never easily be shared.
Last edited:
The situation really only affects users who are not admins on their machine; i.e., some companies do not allow users to be Administrators, and any app that needs to be elevated requires entering the username/password of an admin account. So what is happening is that HWiNFO is running under a different user account than the Rainmeter user, so when the Rainmeter skin looks at HKCU for the HWiNFO sensor data, it is blank/missing. It's there, but in another user account/registry key that the Rainmeter user can't (???) access.

This is obviously an edge case. The solution is to run both Rainmeter and HWiNFO elevated, but I am hearing complaints from users. The only other solution I can think of is HWiNFO writes sensor data to HKLM, which is readable by all users (read-write to admins). I'm not happy with this option either, as everyone who has already changed their skins to use the new method will have to change them all again.

P.S.: Another solution would be to create a batch file that runs both HWiNFO and Rainmeter. The user runs the batch file elevated (i.e., "Run as admin..."), then after entering his credentials, both apps will be run elevated. This means the user doesn't have to enter credentials twice. And no changes to HWiNFO or any skins, which is nice...
Last edited:
I'm wondering how can users without Admin access run HWiNFO as it always requires Admin elevation. So I think the situation is such that they do have Admin access and allow HWiNFO to run as Admin, but don't want to do the same for Rainmeter. I think that such a group of users is very small - most either have Admin access and allow both or don't have Admin access and cannot run HWiNFO either.
Agreed... the more I think on this, the more I dislike the idea of changing anything. I guess the real source of the complaints/issues is that you didn't need used to need to run Rainmeter elevated if you were using Shared Memory and the old HWiNFO Rainmeter plugin. But as you noted, you still have to run HWiNFO elevated anyway, so the problem seems to limited to a small group of users who do have access to a viable work-around.