HWiNFO sensor logging turns a number you glance at into a record you can study. PortableApps published HWiNFO 32+64 Portable 8.54.6090 on October 7, 2026, and the workflow in that build is the one power users have relied on for years: start HWiNFO in Sensors-only mode, pick the rows you care about, press the logging button, and read the CSV afterward.
A single temperature readout tells you almost nothing. A CPU that touches a high number for two seconds during a game launch is fine. A CPU that sits at the same ceiling for twenty minutes while its clock speed sags is not. If you only check your CPU temperature once, you see the first case and miss the second. A log shows both, with timestamps, so you can line up heat, power, clocks and throttling flags on one timeline.
This tutorial walks through 13 steps and takes about 40 minutes. You will install HWiNFO, trim its sensor list, record a repeatable test session, open the CSV without corrupting it, and read throttling flags. Then you will run a Python analyzer that turns the log into a short report and a chart. We tested that script against a synthetic HWiNFO-style log, and every output block in this guide comes from that test run.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
Why HWiNFO Sensor Logging Beats Watching a Single Temperature
HWiNFO reads sensors across the whole machine: CPU package and per-core data, GPU core and memory readings, motherboard voltages, fan speeds, drive temperatures and more. Most monitoring tools show those values live. HWiNFO also records them, row by row, into a CSV file you can open anywhere. That difference matters because hardware problems are almost always problems of duration. Heat soak, power-limit clamping and slow fan ramps only show up when you watch a system for minutes, not seconds.
The tool is also still moving. The portable package PortableApps published on October 7, 2026 carries build 8.54.6090 and bundles both HWiNFO32 and HWiNFO64. One report dates the 8.54 final to September 30, 2026. Reported changes in that release include a fix for NVIDIA VRAM temperatures that appeared as negative numbers, an NVIDIA driver-update crash workaround, and the ability to add notes to JSON sensor logs. Beta builds of 8.55 are also reportedly circulating. Treat those version details as a snapshot and always compare against the build you actually download.
Logging pays off in four situations. First, burn-in testing a new build, where you want proof that the cooler holds up under sustained load. Second, A/B testing a change such as new thermal paste, a different fan curve or a power-limit tweak, where you need numbers from before and after. Third, chasing stutter that appears after twenty minutes of play. Fourth, checking a laptop during its return window, where power and thermal behavior vary from unit to unit. A log answers all four with data instead of impressions.
PortableApps describes HWiNFO as freeware for personal use. Other sources say commercial use needs the Pro edition, so check the terms on the vendor’s own site if you use it at work. The official HWiNFO forum also carries a CSV encoding thread covering Pro builds 8.48-5990 and 8.49-6005 Beta. We return to that bug in the troubleshooting section because it affects anyone logging on a non-English Windows install.
Prerequisites and Versions You Need Before Step 1
You need a Windows PC, administrator rights for the first launch, and about 40 minutes. The Python analyzer in Step 12 is optional, but it is the part that makes the log useful on day two, so install it now. The table below lists everything we used.
| Item | Version or requirement | Notes |
|---|---|---|
| Operating system | Windows 10 or Windows 11, 64-bit | HWiNFO64 is the build to use on 64-bit Windows |
| HWiNFO | 8.54 (portable build 8.54.6090, published October 7, 2026) or newer stable | Installer or portable package, both work for logging |
| Permissions | Administrator account | HWiNFO loads a kernel driver to read hardware sensors |
| Python | 3.10 or newer | Needed only for the analyzer script |
| pandas | 3.1.0 tested | Parses the CSV and computes statistics |
| matplotlib | 3.11.2 tested | Draws the temperature and power chart |
| Load generator | Any stress tool or a repeatable game scene | Same workload every run, or comparisons mean nothing |
| Disk space | A few hundred MB free for logs | Long sessions with all sensors enabled grow quickly |
Set up the Python environment first so you are not hunting for packages later. Open PowerShell in a folder you will keep, such as your Documents folder, and run the commands below. The first line creates an isolated environment, the second activates it, and the third installs the two libraries.
py -m venv hwlog-env
.\hwlog-env\Scripts\Activate.ps1
python -m pip install --upgrade pip
python -m pip install pandas matplotlib
python -c "import pandas, matplotlib; print(pandas.__version__, matplotlib.__version__)"If PowerShell refuses to run the activation script, run Set-ExecutionPolicy -Scope CurrentUser RemoteSigned once and try again. The last command prints the installed versions, which should match or exceed the ones in the table. Newer releases should work, because the script uses only long-stable pandas and matplotlib features.
Step 1: Decide What You Are Trying to Catch
Write down one question before you open the tool. Logging everything for no reason produces a pile of numbers and no answer. A good question is narrow: does my CPU throttle during a 15-minute render, does my GPU memory run hotter than the core in my favorite game, does the new fan curve actually lower package temperature after ten minutes at load.
Your question decides which sensors you keep. Thermal questions need package or core temperature, fan speeds and the throttling flags. Performance questions need effective clocks, package power and the power-limit flags. Stability questions need voltages and, on some boards, the VRM temperature. Game stutter questions need GPU clock, GPU power and the GPU performance-limit flags. Pick one category for your first log and add the others later.
Emulation and virtualization hosts are a good candidate for logging because their load pattern is long and uneven. If you run Android emulators, the factors listed in our guide on Android emulator performance on Windows 11 (CPU, RAM, GPU and virtualization) all show up as sensor rows, so a log lets you see which one saturates first.
Also decide your test protocol now. A reliable session has three phases: an idle baseline of about five minutes, a sustained load phase of 15 to 20 minutes, and a short cooldown. The idle phase gives you a reference to compare against, the load phase reveals throttling, and the cooldown shows how fast the cooler recovers. Keep the room, the case position and the background apps identical between runs. Without that discipline, a two-degree difference could come from an open window instead of your change.
Steps 2 and 3: Download, Verify, and Launch in Sensors-Only Mode
Step 2: download from the vendor. Get HWiNFO from the project’s own site and choose either the installer or the portable package. The installer suits a machine you tune regularly, while the portable zip suits a USB toolkit or a test bench where you do not want to leave anything behind. Avoid repackaged mirrors. Hardware monitors load a kernel driver, so you want the genuine binary. After downloading, right-click the executable, open Properties, and check the Digital Signatures tab for a valid signature. Compare the file version in the Details tab with the build number on the download page.
Antivirus tools sometimes flag hardware monitors because the kernel driver can read low-level system state. A warning is not proof of a problem, yet it is a reason to verify the signature and the source instead of clicking through. If a security product quarantines the driver, add an exception for the HWiNFO folder rather than disabling protection system-wide.
Step 3: launch with the right startup options. Run HWiNFO64 as administrator. The first window offers two checkboxes, Summary-only and Sensors-only. Tick Sensors-only and press Run. You skip the large hardware inventory and go straight to the live sensor window, which is the part you need for logging. The inventory is useful for a one-time spec check, so run it once without the checkbox if you want a record of your exact CPU, board and GPU names.
You should now see a long table with columns for Current, Minimum, Maximum and Average, grouped under bold headings such as your CPU model, per-core clocks, the motherboard sensor chip, the GPU and the drives. The Minimum and Maximum columns start counting from the moment the window opens, which is handy for a quick look but not a replacement for a log. If values show up as zero or dashes, wait a few seconds because some sensors need a poll cycle or two to settle.
Expected first launch checklist
1. Right-click HWiNFO64.EXE and choose Run as administrator
2. Tick Sensors-only, then press Run
3. Confirm the Sensors window lists your CPU, GPU and motherboard headings
4. Leave the window open and move on to Step 4Steps 4 to 6: Tame the Sensor Window, Polling, and Startup Behavior
Step 4: Learn the layout
The Sensors window is dense on purpose. Each bold heading is a hardware component, and each row beneath it is one reading. At the bottom sit a handful of small buttons. From left to right you will find the layout and customization control, a clock icon that resets the minimum and maximum values, a notepad icon that starts and stops logging, and a gear icon that opens the settings. Icons shift slightly between builds, so hover over each one to read its tooltip before you click.
Step 5: Trim what you do not need
Every sensor you leave enabled costs a little polling time and adds a column to your CSV. On a modern board with many fan headers, voltage rails and per-core readings, the log can end up with hundreds of columns. The HWiNFO author said in an October 2026 forum thread that disabling an entire sensor heading is generally the best way to reduce usage, though disabling single items can also work depending on the sensor type. Follow that advice. Open the gear icon, switch to the sensor selection list, and untick whole headings you do not need, such as unused motherboard chips or network adapters.
Keep the CPU heading, the GPU heading and your motherboard sensor chip. Keep the drive temperature entries only if your question involves storage. Do not remove a heading just because it looks unfamiliar. The throttling flags often live under the CPU or GPU headings, and you want those in the file.
Step 6: Set the polling period and startup options
In the settings dialog, find the polling period. Shorter periods catch brief spikes but create bigger files and slightly more overhead. A period of one second works well for 15 to 20 minute tests. For an all-day idle or overnight log, raise it to several seconds so the file stays manageable. Then look at the startup options: Show Sensors on Startup, Minimize Sensors on Startup, Minimize Main Window on Startup and Auto Start. For a test bench, tick the first and last so the sensor window appears automatically. For a daily driver, add the minimize options so HWiNFO stays out of the way.
One more setting deserves a look. Shared Memory Support lets other programs read HWiNFO values, which overlay tools and some Stream Deck plugins rely on. You do not need it for CSV logging, so leave it off unless you use an overlay. One third-party plugin listing says the free edition may switch shared memory off after 12 hours of continuous running and ask you to re-enable it, so treat that as a plugin-specific note, not a documented HWiNFO rule.
Step 7: Pick the Sensor Rows That Matter
With the sensor list trimmed, confirm that the key rows are present. Exact names vary with your CPU, GPU and motherboard, but the families are consistent. The table below maps each reading to what it tells you and what a worrying pattern looks like. We deliberately avoid fixed temperature limits here. Safe ranges depend on the specific chip, so look up the maximum operating temperature on your processor’s or card’s official spec page.
| Sensor row (typical name) | What it tells you | Worrying pattern |
|---|---|---|
| CPU Package or Tctl/Tdie temperature | Overall CPU heat, the value most boards and fan curves use | Flat ceiling for minutes while clocks fall |
| Core Max or per-core temperatures | Hot cores that the package average hides | One core far above its neighbors under light load |
| CPU Package Power | Watts the CPU draws, which shows power-limit behavior | Pinned at one value as clocks drop |
| Average Effective Clock | Real working frequency, lower than the requested clock when throttling | Sags during sustained load |
| Thermal Throttling (Yes/No) | Hardware confirmation that heat is cutting speed | Any Yes during normal use |
| Power Limit Exceeded (Yes/No) | The CPU hit its configured power budget | Yes immediately at load start on a laptop |
| GPU Temperature | Core temperature of the graphics chip | Steady climb with no plateau |
| GPU Hot Spot Temperature | Hottest point on the die, usually above the core reading | Gap to core temperature that widens over time |
| GPU Memory Junction Temperature | VRAM heat, a common limiter on fast memory | Memory far hotter than the core |
| GPU Power and GPU Clock | Board power draw and core speed | Clock drops while power stays pinned |
| Performance Limit flags (Power, Thermal) | Why the GPU is holding back | Thermal flag firing in a cool room |
| Fan speeds (RPM) | Whether cooling responds to heat | Fans idle while temperature climbs |
Newer HWiNFO builds expose more GPU memory detail. According to a TechTimes report from August 2026, AMD Navi GPU owners can now see individual VRAM chip temperatures in HWiNFO, following earlier per-chip readings for NVIDIA GDDR6X and GDDR7 memory. A later release reportedly added a hotspot temperature for NVIDIA Blackwell cards. If your log lacks those columns, update HWiNFO before assuming your card does not report them.
Finally, make sure the throttling and limit flags are visible and not filtered out. Scroll the CPU and GPU headings and look for rows that end in Yes/No. These flags are the cheapest diagnostic in the whole tool because they replace guesswork. A temperature curve suggests throttling. A flag confirms it, and a short GPU and CPU stress test will trigger one on demand if you want to see how your own hardware reports it.
Steps 8 and 9: Start Logging and Run a Repeatable Test Session
Step 8: start the log. Click the notepad icon at the bottom of the Sensors window. HWiNFO opens a save dialog and asks where to write the CSV. Choose a dedicated folder and use a descriptive name. A scheme like date, change under test and workload (for example 2026-10-23_stock-fan-curve_render) lets you sort and compare files months later. Once you confirm, the logging icon changes state and HWiNFO appends one row per polling period. Click the same icon again to stop.
If you test often, let PowerShell build the folder and filename so every session lands in a predictable place. The snippet below creates a timestamped folder and prints the exact path to type into the save dialog.
$root = "$HOME\HWiNFO-logs"
$stamp = Get-Date -Format "yyyy-MM-dd_HHmm"
New-Item -ItemType Directory -Force -Path "$root\$stamp" | Out-Null
Write-Host "Save the HWiNFO log as: $root\$stamp\baseline.csv"Step 9: run the session. Start logging first, then wait through the idle phase without touching the machine. Close browsers, chat apps and anything that wakes the CPU. After five minutes, start your load. For CPU and GPU together, a dedicated stress tool is easiest. Pick one, learn its safe limits first, and use the same settings every time. For a game test, use the same save file or benchmark scene every time and note the in-game settings.
Laptop owners should add two checks. Run the session once on AC power and once on battery, because power plans change the limits dramatically. Windows Forum published a 12-step gaming laptop return-window test that uses HWiNFO Sensors-only mode for exactly this purpose. Its core idea carries over to desktops too: capture power, thermals and real-world frame rates in one session so you can judge sustained behavior and not just the first minute.
After the load phase, stop the stress tool and keep logging for another five minutes. That cooldown tail shows how quickly fans spin down and temperatures fall, which tells you whether the cooler has headroom. Then click the notepad icon to stop the log. Do not close HWiNFO while logging, since an abrupt exit can leave the final rows incomplete.
Step 10: Open the Log Without Mangling It
The CSV opens in Excel, LibreOffice Calc or any text editor, but each has traps. The file uses commas as separators, writes dates in your Windows regional format and saves text in a legacy encoding that does not always match what a spreadsheet expects. The first row holds column names with units in brackets, such as a temperature in °C, a power in W or a clock in MHz. Every following row is one polling sample.
Here is how the top of a log looks. The values below come from the synthetic test log we generated to validate the analyzer, not from a real machine, and the real file has many more columns.
Date,Time,Total CPU Usage [%],CPU Package [°C],CPU Package Power [W],Average Effective Clock [MHz],Package/Ring Thermal Throttling [Yes/No],GPU Temperature [°C],GPU Power [W]
23.10.2026,10:00:00.000,3,40.6,15.0,800,No,45.0,30
23.10.2026,10:00:01.000,3,40.2,15.0,800,No,45.0,30
23.10.2026,10:05:00.000,90,40.0,140.0,4900,No,70.0,300To open it cleanly in Excel, use Data, then From Text/CSV, pick a comma delimiter and select the file origin that renders the degree symbol correctly. If Excel puts everything into one column, your regional settings use a semicolon as the list separator, so choose comma explicitly in the import dialog. In LibreOffice Calc, the text import window asks for the separator and the character set up front, which makes it the friendlier choice for logs from non-English systems.
Resist the urge to save changes back into the original file. Copy the log first and edit the copy. Spreadsheets reformat dates and decimals silently, and a re-saved log may stop parsing in the analyzer. Add a quick line chart of temperature and power while you are in the spreadsheet, because the visual shape of the curve often tells you more than any summary figure. A rising line that flattens into a plateau usually means a cooler reached equilibrium, and a plateau paired with falling clocks points to throttling.
Step 11: Read Throttling and Power-Limit Flags Like a Technician
Read a log in a fixed order and you will diagnose faster. Start with the temperature curve, then check clocks, then power, and only then look at the flags. The sequence matters because each layer explains the next. Heat explains clock drops, power ceilings explain clocks that drop without heat, and flags confirm which story applies.
Four patterns cover most real logs. Pattern A is thermal throttling: temperature climbs to a ceiling, the thermal throttling flag turns to Yes, and effective clock falls. The fix is cooling, such as re-pasting, better airflow or a more aggressive fan curve. Pattern B is power limiting: temperature is moderate, package power sits flat at one value, the power-limit flag reads Yes and clocks sag. The fix is a firmware or power-plan change, or acceptance if the design is a thin laptop. Pattern C is a GPU performance limit: the GPU clock drops while the Performance Limit flag for power or thermal switches on. Pattern D is the quiet one, where no flag ever fires yet performance disappoints.
Pattern D usually means the hardware is not the limit at all. If CPU usage is high on a few cores while the GPU sits well below its power ceiling, you are probably looking at a bottleneck, and our guide to fixing a CPU-GPU bottleneck picks up where the log leaves off. Logs also help rule out the opposite error. People often blame throttling for stutter that the flags prove is not throttling.
Laptops add a wrinkle. Intel mobile chips report dynamic PL1 and PL2 power limits, and the values shown can change between AC and battery and across Windows power plans. A thread on the official HWiNFO forum about dynamic PL1 and PL2 reporting on a Core Ultra 5 125H is one example of users puzzling over those numbers. When your own log shows limits that move mid-session, compare the timestamps against changes in power source or power mode before concluding something is broken.
Flags can also be misleading in short bursts. A one-sample Yes during the load ramp is normal because a CPU boosts hard for a moment and then settles. Count duration, not mere occurrence. A flag that fires for a second at the start is boost behavior. A flag that stays on for minutes is a limit you can feel. The analyzer in the next step reports both the number of events and the total seconds, so you can tell the two apart at a glance.
Step 12: The Working Project, a Python Log Analyzer
Spreadsheets get tedious once you have a dozen logs. The script below reads any HWiNFO sensor CSV, finds the relevant columns by name and unit, splits idle from load, counts throttling events and saves a chart. It matches columns with regular expressions instead of fixed names, since names differ between Intel and AMD systems and between GPU vendors. It also drops the footer rows HWiNFO sometimes writes, converts Yes and No flags to numbers and tolerates the legacy encoding that trips up other parsers.
Save the script
Save the following code as hwinfo_report.py in the same folder as your virtual environment.
#!/usr/bin/env python3
"""Summarize a HWiNFO sensor CSV log: temps, power, clocks, throttling."""
import argparse
import re
import sys
from pathlib import Path
import pandas as pd
import matplotlib
matplotlib.use("Agg")
import matplotlib.pyplot as plt
# Column groups matched by name fragment plus unit, because HWiNFO names vary by hardware.
GROUPS = {
"CPU temperature": (r"(CPU Package|CPU \(Tctl/Tdie\)|CPU Die|Core Max)", r"C\]$"),
"CPU package power": (r"CPU Package Power", r"\[W\]$"),
"CPU effective clock": (r"(Average Effective Clock|Core Clocks \(avg\))", r"\[MHz\]$"),
"GPU temperature": (r"^GPU Temperature", r"C\]$"),
"GPU hot spot": (r"GPU Hot Spot", r"C\]$"),
"GPU memory junction": (r"GPU Memory Junction", r"C\]$"),
"GPU power": (r"^(GPU Power|GPU Card Power|Total Graphics Power)", r"\[W\]$"),
"GPU clock": (r"^GPU Clock", r"\[MHz\]$"),
"Fan speed": (r"Fan", r"\[RPM\]$"),
}
FLAG_PATTERNS = [
r"Thermal Throttling",
r"Power Limit Exceeded",
r"Performance Limit - (Power|Thermal)",
r"Current Limit Exceeded",
]
def load_log(path, encoding, dayfirst):
df = pd.read_csv(
path, encoding=encoding, encoding_errors="replace",
low_memory=False, skipinitialspace=True,
)
df.columns = [str(c).strip() for c in df.columns]
if "Date" not in df.columns or "Time" not in df.columns:
sys.exit("No Date/Time columns found. Is this a HWiNFO sensor CSV log?")
df = df[df["Date"].astype(str).str.match(r"^\d")].copy()
stamp = df["Date"].astype(str) + " " + df["Time"].astype(str)
df["ts"] = pd.to_datetime(stamp, dayfirst=dayfirst, errors="coerce")
df = df.dropna(subset=["ts"]).set_index("ts").drop(columns=["Date", "Time"])
for col in df.columns:
if not pd.api.types.is_numeric_dtype(df[col]):
df[col] = df[col].astype(str).str.strip().replace({"Yes": "1", "No": "0"})
df[col] = pd.to_numeric(df[col], errors="coerce")
return df.dropna(axis=1, how="all")
def pick(df, name_re, unit_re):
return [c for c in df.columns if re.search(name_re, c) and re.search(unit_re, c)]
def runs(flag):
"""Return (count, total_seconds) of contiguous periods where a flag is 1."""
on = flag.fillna(0).astype(int)
starts = (on.diff().fillna(on.iloc[0]) == 1).sum()
step = flag.index.to_series().diff().dt.total_seconds().median()
return int(starts), float(on.sum() * (step if step == step else 0))
def main():
ap = argparse.ArgumentParser(description=__doc__)
ap.add_argument("log", type=Path)
ap.add_argument("--encoding", default="cp1252")
ap.add_argument("--dayfirst", action="store_true", help="dates are DD/MM/YYYY")
ap.add_argument("--idle-min", type=float, default=0, help="minutes of idle baseline at the start")
ap.add_argument("--temp-limit", type=float, default=90, help="flag samples above this temperature")
ap.add_argument("--png", type=Path, default=None)
ap.add_argument("--fail-on-throttle", action="store_true")
args = ap.parse_args()
df = load_log(args.log, args.encoding, args.dayfirst)
if df.empty:
sys.exit("The log has no usable rows.")
span = (df.index[-1] - df.index[0]).total_seconds() / 60
print(f"Log: {args.log.name} rows={len(df)} duration={span:.1f} min")
cut = df.index[0] + pd.Timedelta(minutes=args.idle_min)
idle, load = df[df.index < cut], df[df.index >= cut]
print(f"\n{'Metric':<54}{'idle med':>9}{'load med':>9}{'load p95':>9}{'max':>9}")
for label, (name_re, unit_re) in GROUPS.items():
for col in pick(df, name_re, unit_re)[:3]:
i = idle[col].median() if len(idle) else float("nan")
print(f"{label + ': ' + col[:30]:<54}{i:>9.1f}{load[col].median():>9.1f}"
f"{load[col].quantile(0.95):>9.1f}{df[col].max():>9.1f}")
hot = [c for g in ("CPU temperature", "GPU temperature", "GPU hot spot", "GPU memory junction")
for c in pick(df, *GROUPS[g])]
print(f"\nSamples above {args.temp_limit:.0f} C:")
for col in hot:
n = int((df[col] > args.temp_limit).sum())
if n:
print(f" {col[:50]:<52}{n} samples")
print("\nThrottling and limit flags:")
throttled = False
for col in df.columns:
if any(re.search(p, col) for p in FLAG_PATTERNS) and df[col].dropna().isin([0, 1]).all():
count, secs = runs(df[col])
if count:
throttled = True
print(f" {col[:56]:<58}{count} events, {secs:.0f} s total")
if not throttled:
print(" none triggered")
if args.png:
cols = pick(df, *GROUPS["CPU temperature"])[:1] + pick(df, *GROUPS["GPU temperature"])[:1]
pcols = pick(df, *GROUPS["CPU package power"])[:1] + pick(df, *GROUPS["GPU power"])[:1]
fig, (a1, a2) = plt.subplots(2, 1, figsize=(11, 6), sharex=True)
for c in cols:
a1.plot(df.index, df[c], label=c[:28])
for c in pcols:
a2.plot(df.index, df[c], label=c[:28])
a1.set_ylabel("deg C")
a2.set_ylabel("W")
a1.legend(loc="upper left")
a2.legend(loc="upper left")
fig.autofmt_xdate()
fig.savefig(args.png, dpi=120, bbox_inches="tight")
print(f"\nChart saved to {args.png}")
if args.fail_on_throttle and throttled:
sys.exit(2)
if __name__ == "__main__":
main()Run it on a log
With the environment active, point the script at your CSV. Use --idle-min 5 to match the five-minute baseline from Step 1. Add --dayfirst if your dates run day, month, year, and set --temp-limit to a value suited to your chip. The command below also writes the chart. If your log uses DD.MM.YYYY dates and you skip the flag, pandas prints a harmless UserWarning about the date format and still parses the file.
python hwinfo_report.py "$HOME\HWiNFO-logs\2026-10-23_1015\baseline.csv" --idle-min 5 --temp-limit 80 --png baseline.pngRead the output
This is the real output from our synthetic 20-minute log, which has a five-minute idle phase, a 15-minute load phase and a deliberately overheating CPU. The figures are test data, so treat them as an illustration of the format and not as benchmark results.
Log: baseline.csv rows=1200 duration=20.0 min
Metric idle med load med load p95 max
CPU temperature: CPU Package [°C] 40.5 83.9 85.0 85.0
CPU package power: CPU Package Power [W] 15.0 140.0 140.0 140.0
CPU effective clock: Average Effective Clock [MHz] 800.0 4900.0 4900.0 4900.0
GPU temperature: GPU Temperature [°C] 45.0 70.0 70.0 70.0
GPU hot spot: GPU Hot Spot Temperature [°C] 60.0 60.0 60.0 60.0
GPU memory junction: GPU Memory Junction Temperatur 70.0 70.0 70.0 70.0
GPU power: GPU Power [W] 30.0 300.0 300.0 300.0
GPU clock: GPU Clock [MHz] 210.0 2500.0 2500.0 2500.0
Fan speed: CPU Fan [RPM] 1400.0 1400.0 1400.0 1400.0
Samples above 80 C:
CPU Package [°C] 635 samples
Throttling and limit flags:
Package/Ring Thermal Throttling [Yes/No] 1 events, 443 s total
Package/Ring Power Limit Exceeded [Yes/No] 1 events, 900 s total
Chart saved to baseline.pngRead it top to bottom. The idle median is your baseline, the load median shows typical behavior under stress, the 95th percentile ignores brief spikes, and the max catches the worst moment. In this example the CPU idles well below the 80 degree threshold and climbs close to it under load, with many samples above the threshold and the thermal throttling counted as a single continuous event. That is Pattern A from Step 11. Run the script with --fail-on-throttle and it exits with code 2 whenever any flag fires, which lets a batch file or scheduled task catch regressions automatically.
Step 13: Automate Startup and Build a Before-and-After Habit
Automation removes the friction that kills monitoring habits. HWiNFO’s own Auto Start option, combined with Show Sensors on Startup, brings the sensor window up whenever you sign in. If you prefer Windows to manage it, create a scheduled task that launches the program at logon with the highest privileges. Run the command below in an elevated prompt and adjust the path to match your install or portable folder.
schtasks /Create /TN "HWiNFO Sensors" /SC ONLOGON /RL HIGHEST /TR "\"C:\Program Files\HWiNFO64\HWiNFO64.EXE\""The more valuable habit is the before-and-after comparison. Record a baseline log before any change, make exactly one change, then record a second log with the identical protocol. Keep the files side by side and run the analyzer over the whole folder. The loop below prints a report for every log it finds, so you can compare idle medians, load percentiles and throttling counts without opening a single spreadsheet.
Get-ChildItem "$HOME\HWiNFO-logs" -Recurse -Filter *.csv | ForEach-Object {
Write-Host "=== $($_.FullName)"
python hwinfo_report.py $_.FullName --idle-min 5 --temp-limit 85
}Change one variable at a time. If you swap thermal paste and adjust the fan curve in the same session, you cannot tell which change helped. Write a one-line note in the filename or a text file beside each log. After a few weeks you will have a small library that documents how your machine behaves, which is useful when a driver update or a dusty filter changes things. Apply the same logging method to every change you try.
Common Pitfalls That Ruin HWiNFO Logs
Most bad logs come from process errors rather than software bugs. These seven mistakes account for the majority of wasted test sessions. If you want more component walkthroughs to test with this method, the hardware section collects them.
- Logging without a baseline. A load-only log has nothing to compare against. Always include an idle phase so you can separate the effect of your workload from the machine’s resting state.
- Changing two things at once. A new fan curve plus a BIOS update plus a different game scene makes the result uninterpretable. Change one variable, then retest.
- Leaving every sensor enabled. Hundreds of columns slow polling, bloat the file and bury the rows you need. Disable whole headings you do not use, as the HWiNFO author recommends.
- Ignoring ambient conditions. A warm afternoon can add several degrees to every reading. Note the room temperature and run comparisons close together in time.
- Trusting a single reading. One high sample is boost behavior, not a fault. Judge by percentiles and event duration, which is why the analyzer reports both.
- Editing the original CSV. Spreadsheet programs reformat dates and numbers when they save. Work on a copy and keep the raw file intact for the script.
- Closing HWiNFO mid-log. Stop the log with the notepad icon first. Killing the process can leave a truncated final row that confuses parsers.
Troubleshooting: 10 Fixes for HWiNFO Logging Problems
When something breaks, match the symptom in the first column and work across. The causes below are the ones that come up most often with sensor logging and with the analyzer script.
| Symptom | Likely cause | Fix |
|---|---|---|
| HWiNFO fails to start or reports a driver problem | Not running as administrator, or a Windows security feature or antivirus blocks the kernel driver | Run as administrator, verify the file signature, add a security exception for the HWiNFO folder |
| Sensor rows show zero, N/A or dashes | Sensors need a poll cycle, or the board chip is not exposed | Wait a few seconds, update HWiNFO, then check the BIOS for monitoring options |
| Excel shows the whole log in one column | Regional list separator is a semicolon | Use Data, From Text/CSV, and select the comma delimiter |
| Degree symbols appear as strange characters | Legacy encoding read as UTF-8 | Choose the matching file origin in the import dialog, or pass --encoding utf-8 to the script |
| Dates parse in the wrong order | Log uses day first but the parser assumed month first | Add --dayfirst to the analyzer command |
| Non-English text in the CSV looks garbled | Known mixed-encoding issue reported on Pro builds 8.48-5990 and 8.49-6005 Beta | Update to a newer build, since the author said a fix would follow, and open the file with the right encoding |
| GPU hot spot or memory junction columns are missing | Older HWiNFO build or unsupported card | Update to the latest stable build and re-enable the GPU heading |
| Analyzer says no Date or Time columns | Wrong file type, such as a summary report, or a localized header | Log from the Sensors window, not the report export, and check the first row of the file |
| Throttle flags never register in the analyzer | Flags written in a localized language instead of Yes and No | Replace the words in the CSV with 1 and 0, or extend the replace map in the script |
| Fan RPM stays at zero | Fan plugged into a header the sensor chip does not report | Check other fan rows, move the plug to a monitored header, or confirm in BIOS |
Two extra checks solve a surprising share of the rest. First, if HWiNFO slows the machine, lengthen the polling period and cut more headings before you blame the program. Second, if overlay values do not appear in games, confirm that Shared Memory Support is on and that your overlay tool is running, and remember that a free edition limits how many overlay items you can show according to one source.
Advanced Tips for Power Users
Annotate your runs. The 8.54 change list mentions the ability to add notes to JSON sensor logs. If you log in that format, use notes to mark the moment you start the load, change a setting or open a specific game scene. Even with CSV, you can keep a parallel text file with timestamps. Annotations turn a raw curve into a story you can read six months later.
Pair HWiNFO with a frame-time tool. Temperatures explain why performance changes, while a frame-time capture shows how much. Run both during the same session and line the timestamps up. A dip in effective clock that matches a frame-time spike proves the link between throttling and stutter, whereas a spike with steady clocks points elsewhere.
Watch the beta channel carefully. Reports from October 2026 say a beta build of 8.55 added NVIDIA GPU ASIC quality readings, derived from NVIDIA’s SPEEDO metric, and that the value appears in the main hardware window and not in the Sensors-only view. If you want it, run once without the Sensors-only checkbox. Beta builds are still beta, so keep a stable build for your formal test logs.
Scale beyond one PC. A home lab or small office can ship CSV summaries into a central dashboard. If you already run an observability stack, the trade-offs in our comparison of Datadog, Dynatrace and New Relic help you decide where hardware metrics belong. Start simple, though. A scheduled task that runs the analyzer weekly and keeps the PNG charts in a folder already beats most ad hoc monitoring.
Extend the script. The analyzer is deliberately short. Add a column group for drive temperatures, export the summary to JSON for a dashboard, or compare two logs and print the difference in load percentiles. Because it matches columns by name and unit, new groups need only one line in the GROUPS dictionary.
FAQ: HWiNFO Sensor Logging
Is HWiNFO free to use?
PortableApps describes HWiNFO as freeware for personal use, and other sources say commercial use requires the Pro edition. Terms can change, so read the licensing page on the vendor’s site before deploying it at work.
Where does HWiNFO save the log file?
Wherever you choose. Clicking the logging icon opens a save dialog, and you pick the folder and filename. A dedicated folder with dated names makes later comparisons far easier.
What polling interval should I use?
One second suits tests of 15 to 20 minutes because it catches spikes without producing huge files. For overnight or all-day logs, use a longer period of several seconds.
Does logging hurt performance?
Polling adds a small load that grows with the number of enabled sensors and shorter intervals. The HWiNFO author recommends disabling whole sensor headings you do not need, which is the most effective way to cut that overhead.
How do I know if my CPU or GPU is throttling?
Look for the Thermal Throttling, Power Limit Exceeded and Performance Limit rows in the log. A flag that stays on for minutes while clocks drop confirms a limit, whereas a one-sample flag at load start is normal boost behavior.
Is the Python analyzer safe to run on my logs?
It only reads the CSV you point it at, prints a summary and optionally writes a PNG chart. It makes no network calls and does not modify the log, so you can read every line before you run it.
Can I use this method on an AMD or Intel system and any GPU brand?
Yes. HWiNFO supports both CPU makers and the main GPU brands, and the script matches columns by name and unit so it adapts to different sensor naming. If a column group comes back empty, check the exact header text in your CSV and add a matching pattern.
