BatteryInfoView has a sister. BatteryHistoryView, also by Nir Sofer of NirSoft and also freeware, answers a different question from the same author: not ‘what is my battery doing now?’ but ‘what has my battery been doing?’ Windows 10 and Windows 11 quietly record battery history in a system database, and BatteryHistoryView extracts and displays it. This guide covers what the tool reads, which fields it shows, and — most importantly — how to decide which of the two NirSoft utilities a given question calls for. If you do not yet have the live tool, it is on our download page as the official NirSoft file via /go/batteryinfoview; the companion topic map is the Battery Health hub.
Where the history comes from
BatteryHistoryView extracts the battery history information stored by Windows in the SRUDB.dat database file. That single fact explains both its reach and its limits. Its reach: the history already exists on a Windows 10 or Windows 11 system whether or not you ever installed a battery tool, so the record can extend back well before the day you first wondered about your battery. Its limit: the tool is a reader of that database, in the same spirit as BatteryInfoView is a reader of the battery’s live values — it surfaces what the system recorded, in a readable table, rather than generating new measurements of its own.
Compatibility follows from the source. The SRUDB-based history is a Windows 10/11 facility, and BatteryHistoryView is documented for those systems. BatteryInfoView, by contrast, works on any version of Windows from Windows 2000 up to Windows 11, because it reads the battery itself rather than this particular database. On the NirSoft utilities index checked for our fact base, BatteryHistoryView stood at version 1.06 — a small, stable, single-purpose tool in the usual NirSoft pattern, like its sibling.
The fields it shows
Per NirSoft’s index description, the extracted history includes the following for each recorded entry:
- Timestamp — when the recorded history entry applies.
- Cycle Count — the battery’s charge/discharge cycle count as recorded.
- Designed Capacity — the when-new design capacity, the same concept as BatteryInfoView’s field 9.
- Full Charged Capacity — the current full-charge capacity as recorded at that time, matching the concept of BatteryInfoView’s field 8.
- Charge Level / Percent — how charged the battery was in that record.
- Active and Connected Standby (CS) times, on both AC and DC — how the machine’s time was spent, split by active use and connected standby, and by plugged-in versus on-battery power.
- Energies — the recorded energy figures accompanying those entries.
The capacity pair deserves attention. Because Designed Capacity and Full Charged Capacity are exactly the two inputs to Battery Health — Full Charged ÷ Designed × 100, as derived in Battery Health % Explained — a history of Full Charged Capacity entries is, in effect, a history of your battery’s health over time. Where BatteryInfoView tells you today’s ratio, the history lets you see the slope: whether the decline has been gradual, or whether one period accounts for most of the loss.
When to use BatteryHistoryView, and when BatteryInfoView
The division of labour is clean. Reach for BatteryHistoryView when the question is retrospective: How fast has this battery actually been wearing? What did its capacity look like months ago? How much of the machine’s life is spent in connected standby versus active use, and on AC versus DC? Reach for BatteryInfoView when the question is live or prospective: What is the battery doing right now, at what charge/discharge rate, with what estimated time remaining — and can I log the next hour of behaviour, at 30-second intervals, to find out why it drains the way it does?
The two also differ in who creates the record. BatteryInfoView’s Battery Log (F8) is a log you start, control and export yourself — interval changeable in Advanced Options, savable to csv, tab-delimited, HTML or XML (see the Battery Log guide). BatteryHistoryView’s record was created by Windows, continuously and in the background, with no logging decision required from you — but also with no say from you over what was captured. For an incident last week that you did not think to log, only the Windows record can help; for an experiment you are about to run, only your own log captures exactly the period you care about, including suspend and resume lines.
A practical combined routine
Used together, the sisters cover a battery’s past and present in a few minutes. Open BatteryHistoryView first and scan the Full Charged Capacity column over time to establish the wear story and check the recorded cycle counts. Then open BatteryInfoView and compare today’s Designed and Full Charged values with the most recent history entries — they should tell a consistent story, and the live view adds what history cannot: the current Charge/Discharge Rate, the live percentage, the chemistry, serial number and manufacture date fields (see Battery Serial Number and Manufacture Date), and the four estimated time fields. If a discrepancy appears between the recorded history and the live reading, the live battery-reported values are the present-tense evidence; history explains how you got there.
For the systematic side-by-side — features, data sources and which tool wins which job — read BatteryInfoView vs BatteryHistoryView: Live Data vs Recorded History. It is the natural next step from this guide, and it sits alongside the other comparisons linked from the Battery Health hub.
Reading the history without over-reading it
A history table invites storytelling, and a little discipline keeps the story honest. Work from the columns outward: first confirm that Designed Capacity is stable across the entries you are comparing, because every health-style comparison built from these records assumes that fixed reference. Then follow Full Charged Capacity as a series rather than cherry-picking the best and worst rows — single entries can reflect the circumstances of one charge, while the direction across many entries is the wear signal. Use the recorded Cycle Count the same way, as a trend that should broadly agree with the capacity direction; where the two disagree sharply, treat that as a prompt to look again at the live battery-reported values in BatteryInfoView, not as proof that either tool is wrong. Finally, remember what the Active and Connected Standby times are for: they describe how the machine spent its time, on AC and on DC, which often explains a capacity story — a period of heavy on-battery use followed by a step in the record is a different finding from the same step appearing during months of desk-bound, plugged-in work. Read in that order — reference, capacity trend, cycle trend, usage context — the history becomes evidence you can act on, and it points cleanly back to the live checks elsewhere in the Battery Health hub, including How to Check Your Laptop Battery Cycle Count.
Frequently asked questions
Do I need to have been running BatteryHistoryView for it to have data?
No — that is its main attraction. It extracts history Windows itself recorded in SRUDB.dat on Windows 10/11, so the record predates your first run of the tool.
Does BatteryHistoryView replace the Battery Log?
No. The Windows history is fixed by what the system recorded; the Battery Log is yours — started when you choose, at a 30-second default interval, with suspend and resume lines and one-click export. They answer different tenses of question.
Is BatteryHistoryView from the same author?
Yes. Both tools are NirSoft utilities by Nir Sofer, and both are freeware — which is why this site treats BatteryHistoryView as the safest companion recommendation in the whole battery-tools landscape.