SRUM: The Digital Detective in Windows

Intro

In this article on SRUM we covered the basics — what the database is, why it matters for digital forensics, and a few real-world cases where it changed everything. But if you're doing serious incident response or forensic analysis, the basics only take you so far.

The deeper you go into SRUM, the more useful it becomes — and the more edge cases you run into. What does SRUM actually track? Where does the data live before it's written to the database? What changed between Windows 8 and Windows 11? Why do all your SRUM entries have the same timestamp — and what does that actually mean? And what do you do when the database file comes back corrupted?

This article answers all of those questions. Let's get into the technical side of SRUM.

System Resource Usage Monitor (SRUM), a powerful tool that has become a game-changer in digital forensic investigations.

Section 1 — What SRUM Actually Records (All Four Categories)

SRUM doesn't just log one thing — it maintains four distinct categories of data, each tracked separately and each telling a different part of the story. Understanding what lives in each category is key to knowing which one to focus on during an investigation.

The most valuable for most investigations are the three big ones: what applications ran (and who ran them), what happened on the network, and how the system connected to networks. Energy usage rounds things out and is often overlooked, but it has its own unique value — especially when you need to prove whether a device was powered on and active during a specific window of time.

Section 1.1 - Accessing and Managing SRUM Data

Users can get a glimpse of SRUM data through the Task Manager's "App history" and "Details" tabs, showcasing performance statistics and approximately 30 days of historical data. However, a mere click on "Delete usage history" doesn't erase SRUM data immediately, requiring further investigation into data retention and purging policies.

Section 2 — Where the Data Lives and When It Gets Written

This is one of the most important technical details to get right — and one that trips up a lot of analysts on their first few SRUM investigations. SRUM doesn't write data instantly. It batches everything and flushes it out on a schedule.

In Windows 8 and 8.1, SRUM performance data was first staged in the Windows registry under

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SRUM, 

and then transferred into the SRUDB.dat database approximately once per hour, or when the system properly rebooted or shut down. Think of the registry as the short-term buffer.

Windows 10 and 11 changed this. Data is still written to SRUDB.dat every 60 minutes, but the registry staging step is largely gone. The SOFTWARE registry is now only referenced to look up the names of the SRUM database tables — the actual pre-write buffer doesn't live there anymore.

There's also an important quirk discovered in Windows 10 Version 2004 and carried through Windows 11: SRUDB.dat is not always written on shutdown.

Testing showed that if a system is shut down twice within 10-minute intervals, data may not be flushed until the third reboot — specifically, once the system has been running for more than 60 minutes since the last SRUM entry. This matters a lot in live forensics scenarios where you're racing against a reboot.

Section 3 — How Long Does SRUM Keep Data?

The standard answer you'll hear is that SRUM keeps about 30 days of data — and that's largely true for most tables. But the full picture is more nuanced, and there's one major exception that's incredibly useful.

For most SRUM tables, data is retained for 30 days under normal operation. It's not uncommon to find 60 days worth of historical records though — Windows doesn't always purge aggressively. Data beyond 60 days is typically gone. One important operational note: if a system is powered off for an extended period (weeks), when it boots back up, SRUM may immediately purge anything older than 30 days. So the clock on that older data can run out fast when a device comes back online.

The exception is the Energy Usage LT table — that "LT" stands for Long-Term. This table operates on a completely different retention schedule. In Some cases, the Energy Usage LT table has contained data going back more than four years. The trade-off is that it only tracks high-level information: whether the system was running on AC or DC power, and for how long. But in the right case, four years of "was this laptop plugged in or on battery at this time" data can be surprisingly powerful.

There's also one more lifeline worth knowing about: SRUM is one of the artifacts that gets captured inside Volume Shadow Copies. If shadow copies are available on the system, you can potentially pull historical versions of the SRUDB.dat database from earlier points in time — effectively extending your forensic window even further.

Section 4 — Dealing With a Dirty or Corrupted SRUM Database

Here's a practical reality of incident response: most of the time, systems don't get cleanly shut down before investigators get to them. Someone pulls a power cable, a system crashes, or the machine is seized while running. This means the SRUDB.dat file you're working with may be in a "dirty" state — the ESE database wasn't properly closed and the file could be partially corrupted.

The good news is Windows has a built-in tool for exactly this situation: esentutl.exe. This utility handles defragmentation, recovery, integrity checking, data dumping, and repair of ESE databases. It's already on the machine — you just need to know the right commands.

There are two important rules when using esentutl to repair a SRUM database.

First:

always run the repair on the same version of Windows as the system the dirty database came from. ESE database formats have version differences, and repairing a Windows 11 database on a Windows 10 machine (or vice versa) can make things worse.

Second:

always check the database header first before attempting repair — this confirms it's actually dirty before you do anything to it.

If deleted records have been removed from the SRUM database, there's also a recovery path worth knowing about.

A utility called EseCarve can potentially recover deleted entries from the ESE database file through carving techniques — the same general approach used for file carving during traditional forensics.

Section 5 — SRUM Extensions: The Table GUIDs Explained

Under the registry key

 SOFTWARE\Microsoft\Windows NT\CurrentVersion\SRUM, 

there are three subkeys: Extensions, Parameters, and Telemetry. The Extensions subkeys are particularly useful for analysts because they map directly to the tables inside the SRUDB.dat database — each GUID corresponds to a specific table and tells you what kind of data to expect there.

In Windows 10 (from version 1803 onwards) and Windows 11, there are nine extension subkeys. Not all of them have equal forensic value — the research community consistently finds that the three most valuable tables are the Network Connectivity Usage Monitor, the Network Data Usage Monitor, and the Application Resource Usage Provider. These are the ones you should prioritize in an investigation.

Windows 11 made only one change to the table structure: the Energy Usage Provider table gained two additional columns — "Battery Count" and "Battery Charge Limit." Neither has proven particularly useful in analysis so far, but it's worth knowing they're there.

The SRUM extension subkeys have also evolved across Windows versions, particularly the Energy Estimation Provider which changed its GUID three times between Windows 10 versions 1511, 1607, and 1803. If you're analyzing systems across different Windows versions, you need to be aware that the same table may be stored under different GUIDs depending on the OS version.

Section 6 — How SRUM Evolved Across Windows Versions

SRUM has been in constant evolution since it first appeared in Windows 8. For forensic analysts working across multiple systems running different versions of Windows, understanding these changes is genuinely important — what you find in SRUDB.dat on a Windows 8 machine looks different from what you'll find on a Windows 11 system, and the tools and techniques need to account for that.

Conclusion

SRUM is one of those artifacts that rewards the analyst who takes the time to understand it properly. The basics are straightforward — but once you dig into the write timing behavior, the table structure, the version differences, and the database repair workflow, it becomes a genuinely powerful tool in your arsenal.

---------------------------------------------------Dean------------------------------------------------