As many know HWINFO64 and other tools expose a lot of sensor's information in your PC. The CPU is not an exception and as such you have a plethora of things to measure and track using such software. One of which is the VIDs for each CPU rail, the actual provided VCore, and on better motherboards, actual voltage for other rails too.

But people misunderstand these measurements. HWINFO has a polling rate by default of 2000ms and most sensors are instantaneous values. This means, HWINFO will show that sensor's value at the specific instant the polling happens.. Even if you lower the polling rate to say 100ms, data may seem to 'even out' as you multiplied the sampling by 20x, but this is not enough on processors that change PStates and VID requests at nanoseconds. Other values are weighed down, so the sensor already samples it internally and calculates an average before sending the value, so they cant be trusted either with this matter.

Because of this, I see lots of folks saying 'hey my Raptor Lake CPU doesnt go beyond 1.4v, so I am safe. NO, that is not how this works, your CPU may or may not go beyond that voltage and here is an example below

I have a stock 13600K, am on 107 microcode, no undervolt for now, ICCMax 260A, MCE disabled, IA CEP enabled, AC/DC LL to 1.1mOhms each. Only modification is a very tight PL1/PL2 just because my ITX cooler cannot handle more.

My VCore on HWINFO doesnt go beyond 1.3v, and VID just a little bit below at 1.29ish volts. So one would think I am on the safer side. But no. The actual way to know if your CPU hits a given voltage at any point in time is by using IA VR Voltage Limit* setting in your bios. This setting hard caps the voltage the VRM will feed to your VCore rail, and the neat part of it, is that HWINFO and other tools also track if performance is limited by this specific limit called IA: Electrical Design Point/Other (ICCMax, PL4, SVID, DDR RAPL). The other SoC domains have this sensor too (Ring, iGPU/GT)

After setting this value to 1.325v, I realized my CPU was constantly hitting 'Yes' on this limit while before it wasnt at all. Then I tried 1.35v, much less frequently but still hitting 'Yes' on this limit, specially on single core/light load workloads.

So my suggestion is this, for people that have HWINFO/other tools report under 1.4v peak VID/VCore at any given time:

1. Check whether on lightly threaded scenarios it hits 'Yes'. Why lightly threaded? Because ICCMax is another cause of this limit triggering, as this value is projected and not actual Current. You can disable E Cores momentarily to rule ICCMax out if you want.

2. (If it hits 'Yes') Check your ICCMax, if its still lowish and your VRM can handle it, increase it a little bit until the sensor goes 'No' at lightly threaded workloads (eg a single thread benchmark). Otherwise skip this step. If you are already on insanely high ICCMax, say >400A. Go for the bolded suggestion at the bottom of this post straight away and ignore steps 3-9

3. (If it stays on 'No') Set your IA VR Voltage Limit To something barely above your highest reported VCore. In my case I was getting 1.3v, I set it to 1.325v. I would say anything below or equal 1.4v should be good, but no one knows for certain really.

4. Save your changes and reboot.

5. Repeat the workload you used to measure your peak VID/VCore.

6. Check whether IA: Electrical Design Point/Other (ICCMax, PL4, SVID, DDR RAPL) changes to 'Yes', and how often it cycles between 'Yes' and 'No'

7. (If it does frequently) Repeat steps 3 but with a little HIGHER voltage (always staying under 1.4v).

8. (If it doesn't at all anymore) Repeat step 3 but with LOWER voltage.

9. Repeat steps 4-6.

10. (Optional) Track performance with benchmarks as the more you hit 'Yes' on this limit, the more limited boosting behavior will be, going for lower Pstates/clocks which will result in lower performance. I stopped checking when I felt I was hitting 'yes' very seldomly and single core performance was within 1% of my unlimited results.

People that are on values already higher than 1.4V can instead use this setting to hard cap your voltage to a safer value like 1.4v or below (no value is 100% safe, everything is conjecture as we dont know the design goals with this architecture, only Intel knows this). This will mean you will most likely lose performance, as you wont be able to reach the Boost PStates that required >1.4v at a given thermals/current as often. To regain the ability to hit these PStates again, you will most likely need to undervolt with IA CEP disabled to avoid clock stretching/losing performance

With this way, you will eventually narrow your actual peak VCore to a very small range, so you actually know for certain the CPU doesn't go beyond this value, in order to make better undervolting/RMA/etc decisions. Not everyone has oscilloscopes at home so I think this can help people out.

so what exactly is going on with this situation ? I just found out about it today, but I updated hwinfo like 4 days ago. Its worth mentioning i updated it from the program itself, I didn't click on any reddit links or anything like that. Do I have to wipe my ssds now ? I only use my computer for gaming and i barely have time to do that. There's really nothing I'd consider sensitive on there like credit card info or any saved logins. Just trying to find out how much factual information is related to this malicious code update I've been reading about and how worried I should be.

UPDATE from 12th April 2026: This problem is fixed by the owner of the website. It's not a virus anymore.
But this post should be a example for the future to always be careful with downloading software from the internet. Even if you've trusted a website for years, you can still have bad luck like I did and download malicious software. Hackers always find a way to harm others. Unfortunately, such people do exist.

Post from 10th April 2026:

I want to warn you guys.
After a long time, i opening HWMonitor again on my PC.
it is version 1.42
i checked in the application if there was any update and yes.
the application told me to update to 1.63
i clicked on update and the official cpuid page open

i followed the page to download the latest version.
the file was called "HWiNFO_Monitor_Setup.exe"
after the download my Windows Defender instantly detecting a virus.
(because i am often working with programms which triggering the defender i just ignored that) i start the exe and a russian install programm opening...
i was confused and i canceld the installation.

i upload the file on virus total and i got this results:
https://www.virustotal.com/gui/file/eefc0f986dd3ea376a4a54f80ce0dc3e6491165aefdd7d5d6005da3892ce248f

i delete the exe after it.

a friend of me send me version 1.61 called "hwmonitor_1.61.exe"

no virus detected on my system and on virus total.

i checked the version history.
when i try to download 1.62 then the server gives me this "hwmonitor_1.62.exe"

after that i tried to change the download link from
cpuid.com/downloads/hwmonitor/hwmonitor_1.62.exe
to
cpuid.com/downloads/hwmonitor/hwmonitor_1.63.exe

and the download link was valid and seems be the original link!!! i got "hwmonitor_1.63.exe"
when i upload the "hwmonitor_1.63.exe" on virus total then there is also no virus..

So please guys be very careful what you download on the internet.
Even the most trustworthy websites can contain nasty traps.

If anyone knows how to contact the site operators as quickly as possible, I would be very grateful.

I saw that there's a contact form on the website...

But after what happened, I'm reluctant to enter my data like my email address on the website.

Shared memory support now works only 12 hours(

I usually leave HWINFO on all the time as I like to look at stats and make sure that my peak temps are fine when gaming (they always are). However, I can't help but once in a while, a microstutter could be caused by constantly monitoring so many variables, even though I reduced the polling rate to every 3 seconds. Any thoughts on this?

When you double click any of the values it opens this really cool graph and you can measure different values and how they change over time!!
I had no clue, and I cant believe I never tried something as basic as double clicking something in there.

Hey PC Games, I hope you all are doing well. I am sharing my HWINFO of the PC, which have everything, I just want to know does everything is fine based on this screenshot, or there something which I need to worry about.
This is the screenshot.

I wanted to download hwinfo for the first time so i went to its website and for the download options there were dAppCDN, SourceForge, Local (U.S.), SAC ftp (SK) which one should I choose for a person who is using Windows 11 and Living in not America

Hi, so I just installed HWiNFO64 on my new laptop, and was copying over my settings from my Desktop, when I looked at the "Driver Management" tab only to realize my Desktop never installed the HWiNFO driver... Yet HWiNFO seems to have worked fine for me for years?

I can't seem to find info anywhere on what the driver actually does, all I can find are posts from people not being able to install it. Does it improve sensor accuracy? Does it let HWiNFO run before login? Does it give access to more sensors or hardware information? And it says it automatically installs and uninstalls the driver unless "persistent driver" is selected, but I'm not sure if it's ever been installed on my systems?

Closest thing I can find to anyone else asking this question is another reddit post where someone asked what the Driver Management tab is for, but they never got any responses.

Currently reading information about temperature, voltage, power draw, fan speed ect on Linux can be quite spotty and almost always less detailed than on HWiNFO on Windows such as with power draw (as far as I can tell there is no easy way to view the wattage consumption of different components in the system).

My understanding is that sensor data is generally exposed through /sys/ files by kernel drivers which communicate with the hardware directly under the hood. Running lm_sensors on my laptop mentions that "thermal management is [often] handled by ACPI rather than the OS" so this also indicates to me that some sensors are interfaced through ACPI. I'm not sure if there are any other sources of sensor data is may or may not be used.

There are two parts to reaching parity with software like HWiNFO on Linux:

Sensor Data Parity

The first is of course to be able to get access to all of the same sensors. Throwing around some ideas, keep in mind I know very little about what I am talking about so please correct me or provide more context:

• If a kernel driver itself has the information but isn't exposing it then we can patch the driver to expose /sys/ files to userspace. This was briefly mentioned here: https://community.frame.work/t/responded-sensors-availability-linux-vs-windows/47416/8. My initial thought would be that there would be a bunch of info for components that are commonly used in enterprise (such as certain CPUs). I suspect this approach is probably more viable for components such as CPUs or GPUs.

• In a lot of cases there may just not be any vendor support or documentation, I suspect this is the problem for a lot of things like fans. In this case we may have to make use of the work HWiNFO has done on Windows. This could be done by reverse engineering how HWiNFO works (either by snooping communication with hardware or looking at decompiled software) but I suspect this would be a tedious and manual process that is just fighting an endless uphill battle, far from a solution that could "just work" like HWiNFO does. I imagine software such as WINE is out of the question since HWiNFO likely calls Windows only drivers that do not exist on Linux or ACPI calls that probably are impossible to get working for some reason.

• Request hardware companies to better support Linux. I think this is unlikely for most cases where there isn't already an expansive effort to support linux by these companies.

• Some kind of communication bus fuzzy search (such as by using i2cdetect). I think lm-sensors does this to an extent but I don't think it does much in most cases and can potentially cause issues.

• In some cases a kernel driver does exist but is obscure and not enabled by default or lacks support by frontend software. I experienced this with my laptop 7535U of which I can use the zenergy (amd_energy fork since I couldn't figure out how to easily install amd_energy) driver to view per core energy usage. I had to install this driver myself and no frontend software that I used seemed to support it.

A comprehensive frontend

While there are a couple frontends for different sensors there is none nearly as comprehensive as HWiNFO on Linux. This is in part due to the aforementioned lack of sensor data but possibly also because the software that I've seen is often targeted at specific types of sensors rather than as a centralized hub for nearly all of them (also see point about zenergy above). Getting the above done seems to be the biggest bottleneck but I'd be willing to write a GUI (with CLI fallback) myself if it comes to it (probably in the iced toolkit).

What can we do as a community to improve the situation?

Is what I said earlier correct?

If so how could I or anybody else get started with say reverse engineering a sensor or creating a patch for a kernel driver. What resources are available to get started?

DISCLAIMER: No, this is not LLM written. I handwrote it in VIM in like 40 minutes then spellchecked it. I also made a post in the Arch Linux subreddit with a different title which I changed in this post because I think it made people think that my post was LLM written.

I'm new to HWinfo as I just recently downloaded it. Im confused on which sensor tells the actual CPU temp, so which one really is it?

Thanks in advanced

Sorry if this is a dumb question, but when I hover over the free download button, it pops up with scourgeforge, local, sac ftp, and old versions. Which one am I supposed to pick?

Edit: and what’s the difference between installer and portable? Which do I pick for that?