HWMonitor reads health and activity sensors exposed by a computer’s components and arranges them under a hardware tree. The readings can include temperatures, voltages, fan speeds, power, clock speeds, and utilization. HWMonitor observes these values; it does not set a fan curve, change a voltage, or stress the computer like a benchmark. Its job is to show what supported sensors report now and to record those values during a workload.
Sensor tree
Each top-level entry represents detected hardware, with sensor groups beneath it. A processor can expose package and core temperatures, clocks, powers, and utilization. A graphics card can expose its own temperatures and clocks. Storage devices may contribute SMART measurements, while batteries and memory modules appear only when their hardware exposes compatible data.
Two computers with the same processor can still show different motherboard, fan, or voltage rows because monitoring chips and firmware differ. A missing row does not mean the physical sensor has a zero reading. It means HWMonitor did not receive a supported value for that item. Comparing labels across unrelated machines therefore needs the underlying component identity.
Live graphs
A sensor row can enter the graph window through its context menu. HWMonitor groups sensors of the same type and allows up to eight curves on one graph. The settings can move a curve, change its color, or remove it. This makes a temperature rise easier to compare with another sensor while a workload runs.
The graph records the period during which the window and monitoring session remain active. It is not a permanent history by itself. Closing the program ends that live view, so a problem that appears after several hours needs logging or another recording method before the user can inspect it later.
CSV logging
Pressing F5 starts CSV logging and the status bar shows that logging is active. The file stores a time series that a spreadsheet can plot or compare after the workload ends. HWMonitor writes the reported sensor values; it does not add an explanation for a temperature spike or a clock drop.
Logging every visible sensor can create a wide file with labels that vary by system. A useful recording starts before the workload and stops after the machine returns toward idle. Without that interval, a single high value lacks the surrounding change needed to distinguish a brief peak from a sustained condition.
Unusual counters
HWMonitor can report processor activity above one hundred percent. Its documentation explains that it uses utility counters and does not apply the ceiling that Windows Task Manager uses. Turbo behavior can therefore produce a value that looks impossible if the reader assumes that both programs calculate the number in the same way.
An NVIDIA PEX recovery counter can also rise without proving a hardware fault. Speed changes, link-width changes, and other transitions can increment it. Other PCIe error counters have different meanings and should remain at zero according to the usage guide. Treating every counter as the same kind of error can send diagnosis in the wrong direction.
Portable files
The portable archive contains separate x64 and x32 executables. The x64 file is the ordinary choice on a 64-bit system, while the x32 file exists for 32-bit Windows. Running the wrong binary can stop at launch rather than displaying a partly compatible sensor list.
File and Save creates a text report that records the detected hardware and sensor information. CPUID requests this report when investigating a defect or undefined value. The report can contain detailed component identifiers, so it should receive the same care as other diagnostic files before public sharing.
