Choose different profiles with a start up option

GeoffW

Member
It used to be that I ran HWiINFO quite rarely, mostly when building a new system or updating hardware and wanting to see the details of what was there. I used other options for day-to-day monitoring. But those other options have all fallen by the wayside and I am trying to make HWiNFO serve both duties. I've always struggled to make HWiNFO work as I want for day-to-day monitoring, but now I have worked through it and I have a configuration I'm reasonably happy with: a couple of taskbar icons and a shortlist of most interesting sensors I can show in the window sized quite small in the corner, all neat and to the point. Which is good, except...

Now I can't easily use HWiINFO for the "show me everything" mode. I have tried saving out the registry keys so that I can run a script that will remove the registry keys, run HWiINFO in show everything mode, then close it and re-import the keys so that it goes back to what I want - but this is cumbersome and difficult to maintain.

So what I'd like is a start up option that let me direct HWiNFO to a particular profile (configuration and file and sensor settings etc.).

Ideally, I think the start up option should direct to configuration files (rather than registry), because this would make it possible to force the exe to be a good portable citizen and not clutter a system it may only be visiting. But since I don't do much portable stuff these days that doesn't worry me overly much. I imagine an easier way to implement this would be to just direct to the different registry path based on the start up parameter. OR even just a start up option that says ignore the registry sensor details and don't save any sensor customisations in this session (less flexible but would achieve what I want most).


(Which isn't meant to sound ungrateful. :eek: I just want to tame that detail a bit for daily monitoring purposes without losing the larger capability.)
 
This is an interesting idea. Can't you accomplish this by opening HWINFO with everything displayed, then click Backup User Settings in the Main Settings panel (that backup would be the "Show Everything" preset) then go through and hide or disable whatever you don't want to be included, then click Backup User Settings again and save it to a different filename? I don't see an Import Settings in HWINFO but since the backup files are .reg files, if you just import whichever one you want into the Registry, then open HWINFO, it should open with settings that match whichever Backup .reg file you last loaded into the Registry. The backup .reg files would act as "Presets".
 
My second paragraph tried to describe my registry script attempt in brief.

As far as I can tell a "Show Everything" option requires essentially deleting everything under this key: HKEY_CURRENT_USER\Software\HWiNFO64\Sensors (and then optionally restoring the window position values). This seems the best way to ensure no existing settings block what HWiINFO does. (As far as I can tell the logic is to show everything it has not been told not to show.) But, yes, the export settings works for a custom/cut-down configuration.

There are also a handful of options stored in HWiINFO64.ini. I'm not sure regarding the logic of what goes in the INI file (not much) and what goes in the registry (lots). So it may be necessary to fiddle with the file and part of the process.

None of that is particularly difficult. Put a bit of cmd or ps and some shortcuts around it, and it should work fine, but it's fiddly to set up and maintain. However, if the program could select a profile at start up (whether in the registry or in a file) it would automatically save changes to that profile and save any mucking around updating scripts every time you want to adjust something. (So not the end of the world if it is not there, but it would be convenient to have.)


When I saw there was a "Portable" download I thought that might be the easiest solution (it's a small enough app that separate copies would not be an issue), but it's not really portable in the sense used by portable-app enthusiasts (where "portable" is not just no-install, it's leave nothing behind). So multiple instances in this case doesn't achieve what I wanted.
 
Makes sense, thank you for explaining. I think having presets is a great idea but I am not sure how to best implement this. There is an INI file but only a few basic settings are stored there. The idea of having different presets be stored in the Registry in different paths may be the easiest way to do this since I don't think it would require large changes to how HWINFO currently works. Maybe if more people ask for presets, Martin (author) will consider adding them in some way.
 
The INI file contains settings that are considered portable, so settings that the user might want to use in other systems as well.
These settings are also machine-independant, while those stored in registry depend on actual system and transferring them to another system wouldn't work (i.e. different screen dimensions, set of sensors, etc.).
That's the reason why there are 2 different sets of settings.
 
The INI file contains settings that are considered portable, so settings that the user might want to use in other systems as well.
These settings are also machine-independant, while those stored in registry depend on actual system and transferring them to another system wouldn't work (i.e. different screen dimensions, set of sensors, etc.).
That's the reason why there are 2 different sets of settings.
Hi Martin. Thanks for chiming in. That makes perfect sense. That said, "Presets" (in my mind anyway) would just be different lists of the main options for sensor items - Monitor or not, Show or not, Log or not. Other variables like Color, Bold, Italics, Red Color </> Thresholds, Units, Multiplier, Offset (Add) would be nice to have but I suspect may overcomplicate things. I still think this could be accomplished by setting up what you want monitored, shown, and logged, then doing a Backup User Settings, then setting up the next "preset" and backing up again. To recall a "preset" just double-click the backup .reg file of the desired configuration before running HWINFO. I'm going to play around with this and see if it works.

Edit to add - Well my idea did not work at all. I opened HIWINFO, grabbed all the Core Residency items, hid them, then went to the Main Settings and clicked Backup User Settings, then set the items back to Show, then closed HWINFO. Then I double-clicked the backup .reg file that I just made which I thought would write the Hide settings into the Registry. Then I ran HWINFO again to see if the items I hid would be hidden but they weren't. So I obviously do not understand how this works.
 
Last edited:
Thanks for the explanation of the INI file, Martin. Makes sense, and I understand why you do not want machine specific settings to be used on a portable installation moving to another machine. (I imagine there would be ways to deal with that, but it's not something I'm asking for here because I don't do that sort of work much these days.)

SpeedyIV,

My first reaction is to ask if your normal access is running as the same user as HWiINFO? I always run as a normal user and HWiINFO has to run as admin, so a "double-click" on the reg file wouldn't end up in the right HKEY_CURRENT_USER for me. But most people do run as the same user, so this probably doesn't apply to you.

The registry under Sensors is complicated and I'm not sure of how Martin manages the identifiers for all this stuff. Simply restoring the registry should work most of the time, I would have thought, but faces potential issues in the face of system changes of various sorts. So...

I have a "Reset to Defaults" (show everything) registry file that looks like this (delete all existing registry entries for HWiINFO64):

Code:
Windows Registry Editor Version 5.00

[-HKEY_CURRENT_USER\Software\HWiNFO64]

While my reset sensors to a custom layout file is too big to post here, but I prefix it with this (to remove all existing sensor details, if any):

Code:
[-HKEY_CURRENT_USER\Software\HWiNFO64\Sensors]

If you put that at the top of your backup registry file then your process should work (assuming my first reaction doesn't apply). It seems to work here.

Accompany that with relevant save/restore of HWiINFO64.INI and you have a whole profile switching arrangement.


Martin,

What Embarcardero do with their RAD Studio (Delphi etc.) product is provide for a -r <name> command line parameter. If provided then everything is read and saved with a base key of: HKEY_CURRENT_USER\SOFTWARE\Embarcadero\<name>

If not provided then everything is read and saved to: HKEY_CURRENT_USER\SOFTWARE\Embarcadero\BDS

In your case I imagine it would go to HKEY_CURRENT_USER\Software\HWiNFO64\Profile\<name>, in order to avoid complications with your default/existing settings, and so all the profiles will be captured in your existing backup arrangements. A bit of sanitising around the <name> value and the rest seems likely to work with minimal changes in the rest of your code (well maybe ;)).

Embarcardero, too, have a very complex set of registry settings - so much so that trying to compare or synchronised changes to settings can be a significant undertaking - so simply moving to a different root and working there is a convenient way to deal with the problem.

Just FYI. None of this is meant to distract from and more important work on your excellent product. :)
 
Geoffw - Thank you for your response.

I am always logged in as Admin so double-clicking the .reg file that HWINFO generated when I clicked Backup User Settings should have (I think) modified the proper registry entries for the account I was logged in as. So I don't think that is the problem.

I think I understand what you are suggesting, which is to add the line [-HKEY_CURRENT_USER\Software\HWiNFO64\Sensors] at the top of the .reg file that HWINFO creates when I click on Backup User Settings. Adding this line at the top of the .reg file should clear out any previous configuration data in the registry, so the new data beneath this line can be added properly. Is this correct? I will try this and let you know if it works. I still don't understand why just double-clicking the backup .reg file does not work, but it doesn't, so I will try this. Many thanks for the suggestion.
 
It is common for program to NOT save settings that are at their default values. For two reasons: one is that it keeps what is actually saved down to what is relevant, making it easier to read and analyse; and the other is so that if a future version of the program changes the default then the installation will automatically see it (rather than still be reading an old default value from the settings).

When you do an export from the registry (as per the settings export done by HWiINFO), you get a list of what's there. You don't get what is not there (eg: settings at their default values). When you do an import from that file it will add or update the values from the export but it will not remove what might be already in the registry that was not part of the original export (unless you explicitly ask it to). For this reason the process is often referred to as merging. What the registry ends up with is a mix of what it already had plus what is added or updated from file.

That line to remove old values can help you produce more consistent results. BUT, obviously, you need to be careful: deleting stuff can be hazardous. This is especially true while running as administrator.


I just ran a little experiment.

Starting with a clear registry (my Reset to Defaults script above), I showed the list of sensors and under one of the blocks near the top I expanded the list of processors. Then I exited out of HWiNFO. The registry looks like this:

HWiINFO reg 1.png

Then I started HWiNFO back up again, the list of processors was still expanded so I collapsed it and then exited HWiNFO again. You can see the registry looks like this:

HWiINFO reg 2.png

The setting for collapsed (and for the entire sensor!) has disappeared. If I export the settings in this state that export would not carry the sensor settings to update anything in a future import.


I am still not entirely clear how this relates to what you originally described, since that really did seem like it should have worked: Hide was non-default so should have been saved with the export and restored with the merge, I would have thought. I suspect there are additional complications entering in to this situation. But whatever was going on there, you can now see what clearing existing settings before the import/merge is probably necessary to get consistent results.
 
Thank you for further explaining this. I will surely be VERY careful before adding or deleting things from the registry. I will back up the registry first and also make a Restore Point. I have some old Windows machines laying around that I could use as a test bed too. What you are suggesting (that default values are not written into the backup .reg file) makes sense but since Hide is not a default, it seems like it should have worked, but it didn't so obviously I am not getting something.

I know enough about the Windows Registry to be dangerous but I also know my limits. I spent some time looking through the HWINFO section and can make sense of some of it but not all of it. I never found any entries that look like they have anything to do with Core Residency (which is the section of sensor entries I hid in my test.) I can grab a copy of the registry with everything in HWINFO at defaults, then make some changes and create a Backup User Settings .reg file, then compare them in Winmerge. It should highlight all of the changes. Doing this may shed some light on exactly what changes when sensors are changed to Hide. I'll play with it this weekend and report back.
 
Yeah, sorry about the condescending "don't try this at home, kids" bit in bold, just that every now and then I get conscious of the fact that others may be reading over our shoulders, so to speak, and it would be so easy to put that "-" delete marker on the wrong line and end up knocking down a tree instead just one small branch of the registry.

It will be interesting to hear what you find about your situation, because so far my registry scripts are doing what I expect.
 
No apology necessary though I did not consider that someone else may be taking advice from this thread. Also, I am by no means an expert in editing the registry, so all cautions are appreciated. That said, I think I understand how to properly insert your registry scripts, but to be sure, please allow me to parrot the procedure back to you. I also did some new tests which are described at the end of this post.

Your first script is "Reset to Defaults" and is [-HKEY_CURRENT_USER\Software\HWiNFO64] which contains a hyphen in front of HKEY. This hyphen will cause EVERYTHING in HKEY_CURRENT_USER\SOFTWARE\HWiNFO64 to be deleted, hopefully clearing out any preexisting entries that may be interfering with the import of the backup.reg file.

Your second script is [-HKEY_CURRENT_USER\Software\HWiNFO64\Sensors] which also has a hyphen in front of HKEY. Putting this in the backup .reg file would delete EVERYTHING under HKEY_CURRENT_USER\SOFTWARE\HWiNFO64\Sensors, Assuming I am correct so far, here is a snip of the first few lines of the .reg file created after I opened HWINFO, hid all the Core Residency items, then clicked Backup User Settings. This file has not had anything added to it by me.

Core Res Hide Clean C.jpg

Here is the same file with your "Reset to Defaults" script added at the top. Double-clicking this file should cause it to merge into the registry. The added line should delete EVERYTHING under HKEY_CURRENT_USER\SOFTWARE\HWiNFO64 then insert all of the lines in the backup file into the main .reg file. I think HWINFO will insert all of the keys and data it normally inserts on first install, and the entries in this backup .reg file will be merged with what HWINFO adds.

Core Res Hide w All Delete Script.jpg

Here is the same file with your second script added instead of the "Restore to Defaults" script. This should delete EVERYTHING in HKEY_CURRENT_USER\SOFTWARE\HWiNFO64\Sensors, then insert all of the lines in the backup .reg into the main .reg file. I think this is the one I should use since this will only delete the Sensors key and everything in it. Everything else under HKEY_CURRENT_USER\SOFTWARE\HWiNFO64\ would remain. The contents of the backup .reg file would be inserted in the \Sensors key along with whatever else HWINFO adds when it is run.

Core Res Hide w Sensors Delete C.jpg

In both cases, the default setting for SHOW/HIDE Core Residency items is SHOW, and (theoretically) nothing gets written to the registry for defaults. The backup .reg file should contain data telling HWINFO to HIDE these items. Double-clicking the backup .reg file should cause this data to be merged into the proper locations in the registry. Running HWINFO after merging the backup .reg file should result in the Core Residency items being hidden.

What I am not sure about is what happens if there IS an entry in the registry file to SHOW an item but the backup .reg file contains data that says to HIDE that item. More generally, what happens when data in the backup .reg file conflicts with data already in the registry, or data that HWINFO adds to the registry when the program is started? In the case of a conflict, does data from the merged file overwrite data already in the registry or data that HWINFO writes to the registry?

Finally, I did the following test.
  1. Exported the registry to a backup file
  2. Opened HWINFO and changed ONE sensor item (Core 0 Distance to TjMAX) from SHOW to HIDE.
  3. Clicked Backup User Settings
  4. Loaded the backup complete reg file and the backup file that HWINFO generated into WinMerge.
There are a bunch of differences in the 2 files. Most of them (74) show a line in the Main reg file that says "Label "="" that does not exist in the HWINFO generated backup file. I am not sure what this means but I don't think it has anything to do with changing the one sensor item from SHOW to HIDE. There are also some differences that are just specific values (clock speeds, etc.). There is one difference that I think is due to changing the sensor item from SHOW to HIDE. It looks like this. The main reg file is on the left. The HWINFO backup reg file is on the right.

WinMerge Diff Core 0 Dist to TjMAX.jpg

From what I can decipher, it looks like changing the sensor item from SHOW to HIDE adds a dword and sets "Row" to ffffffe and "List" to 00000000. I think this is the smoking gun that reveals exactly what is added to the registry when an item is changed from SHOW to HIDE. This system has a 6-core processor.

I went back into HWINFO and changed all 6 to Hide, then made another backup file, then compared that file to the main reg file. I expected to now see the above difference 6 times but I didn't. As a final test, I changed 4 totally unrelated items from SHOW to HIDE, then made another backup file and compared that file to the main file. This time I did see the above in 4 different places. This leads me to suspect that it's not quite so straightforward. Changing 1 sensor or all 6 sensors in the Core x Distance to TjMAX both resulted in the above difference occurring once. Changing 4 sensors from completely different sensor groups from SHOW to HIDE resulted in the above difference occurring 4 times. So there is something else going on, based on how sensors are grouped.

This post got way longer than I intended, so apologies for that. Please let me know if my description of what your scripts do is correct. Any insights you may have into what I observed when comparing the reg files in WinMerge are appreciated. I will try adding your [-HKEY_CURRENT_USER\Software\HWiNFO64\Sensors] script to the HWINFO-generated backup file, then merge it and see what happens. I will back up the registry and make a restore point first.

Many thanks for your help with this.
 
Yes your description of [-HKEY_CURRENT_USER\Software\HWiNFO64\Sensors] etc. matches what I was trying to say. (To be fully explicit, it deletes the specified key itself and therefore everything underneath it - like deleting a folder on the disk.) The thing that makes me most nervous with this feature is how easy it would be to stick that innocuous '-' character in the wrong place and wipe out more than you intended.

Deleting the sensors data certainly seems like it may be necessary in order to get consistent results, but whether a complete reset (deleting everything under HWiNFO64, not just sensors) is necessary is less clear, it probably depends on exactly what you're trying to achieve with the script.

Items from the registry file will merge into the registry via insert or update. That is: if the item does not exist it is inserted, if the item does already exist it will be updated.

You said "and (theoretically) nothing gets written to the registry for defaults", which is a good way to put it. It's apparent that HWiNFO is writing some seemingly default values. From what I can gather, it seems that if it has a reason to write out a sensor entry (if any value for the sensor is non-default) then when it writes that sensor it will (in some cases but not all) also write some initial/default values for that sensor. There is probably a reason for this, but I don't know what it is ... although exporting of Label, Unit and DecimalDigits seems a bit random (I have some backups that have them and some that don't - perhaps related to the inconsistency I note at the bottom).

I tried your experiment directly. I did a Reset to Defaults and then started HWiNFO and hid the Distance to TjMAX for CPU 0 only. I made the change and then immediately did a backup - and my backup was effectively empty! This:

Code:
Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\HWiNFO64]

[HKEY_CURRENT_USER\Software\HWiNFO64\Sensors]

[HKEY_CURRENT_USER\Software\HWiNFO64\Summary]

[HKEY_CURRENT_USER\Software\HWiNFO64\Summary\Clocks]

I wonder if that is what you hit the first time? It appears that perhaps the backup is exporting from the registry but the registry may or may not have been updated at the time you did the export. I imagine you got a copy of the settings from the time that instance of HWiNFO started, so got all your existing settings but not the changed entry.

Note that in this instance (for the first time), I made the change by right-clicking on the entry in the sensor display and choosing Hide from the popup menu. All my previous work has been done in the "Sensor Settings" dialog itself (it's easier to make mass changes there). I just checked, and yes, when I did this over (Reset to Defaults etc.) but made the change in the Sensor Settings dialog, then I could immediately do a backup of the settings which included:

Code:
[HKEY_CURRENT_USER\Software\HWiNFO64\Sensors\F0000400_0\Temp12]
"Enabled"=dword:00000000
"Row"=dword:fffffffe
"List"=dword:fffffffe

I believe the Row and List entry are there for internal program logic because "hide" moves the value off the list.


Martin, it looks like you may need to fix your Backup User Settings so that all outstanding changes are written to the registry before the backup is done. In the mean time people should exit HWiNFO after making changes via the popup menu, then restart before doing the backup OR make the changes in the Sensor Settings dialog window.
 
Martin, it looks like you may need to fix your Backup User Settings so that all outstanding changes are written to the registry before the backup is done. In the mean time people should exit HWiNFO after making changes via the popup menu, then restart before doing the backup OR make the changes in the Sensor Settings dialog window.

This will be fixed in the next build.
 
Geoffw - I think you are exactly right. I hid the single and multiple sensors by selecting them in the main sensor status screen, then right-clicked and selected HIDE. Then I clicked on the gear icon on the bottom right side which opened the Sensor Settings window. From there I selected Main Settings and then Backup User Settings. What I did NOT do is Save and Close, then restart HWINFO, and then do the backup. If I had, I think the data telling HWINFO to Hide the selected sensor(s) would have been written to the registry.

Your latest test indicates that if the change to HIDE is done by right-clicking the sensor(s) and selecting HIDE, the Hide data is NOT written to the registry yet but if you open the Sensor Settings panel and go to the Layout tab and hide the sensors(s) there, the Hide data IS written to the registry. I can easily verify this by repeating my previous test except I will hide the sensor(s) from the Sensor Settings panel instead of right-clicking them and selecting HIDE from the context menu. I am 99.9% sure this will work as expected.

Since Martin has stated that this will be fixed in the next build, I assume your hypothesis is correct. When Backup User Settings is clicked, HWINFO should first write all changes to the registry, and then generate the backup reg file. Or it could write the new data to the registry each time something is changed in the right-click context menu. I defer to Martin on the best way to resolve this.

Circling back to the original goal of having Presets, the use of User Settings Backup reg files should work, but there is still the issue of adding the Delete Sensor Key script to the backup reg file. I will try it both ways and see what happens if I include the Delete Sensor Key script versus not including it. From your tests, I think I will have to include it but want to be sure because deleting the entire Sensor key is a rather brute-force solution and something I would prefer not to do unless I have to to get the Presets to work reliably.
 
SpeedyIV, I know what you mean about the delete seeming inefficient, but in the scheme of things (how much other stuff is constantly being written to the registry) I doubt it matters very much - it's not like we'd expect to run the script thousands of times a day.

More important is that the delete is also going to delete things like the window position information. Depending on your objectives, and exactly how you intend to use each profile, this may be good or bad. (It's mostly good for me, because I have very specific layout for my day-to-day monitoring mode.) The issue here is that it is difficult to delete just the sensor data (and not the sensor window values) ... that would involve writing some sort of script that first extracted out the list of sensor keys so that it could delete only them ... which all seems too hard.

It took me several tries to get a layout I liked and set up the registry script files as I needed, I imagine you will find the same. Which just emphasises (for me anyway) why it would be convenient to have this profile switching built-in.
 
You make a good point about also deleting window position info (and whatever else). I will try making 2 presets and see how it goes. At least Martin has acknowledged the issue with when the changes get saved to the registry relative to doing a manual backup, so that issue will be resolved. If he decides to add presets, I will happily use them. If it is a feature he does not want to support, then I will try making the presets as discussed. If it causes issues that are not easily resolved, then maybe I will give up on the idea. I have used HWFINO for many years without presets, so the world will keep turning.

Many thanks for all of your help and insights.
 
Hi, I am just logging in to say that I have long wanted the Profile ability, too. And pretty much for the same reason:

I want one profile to show EVERYTHING, and another to just show what I think is important. So having an Everything and a Custom would be good enough for me. Maybe an Everything with a good filter would accomplish this?

Thanks!
 
Back
Top