What is SRUM and why forensic analysts care

SRUM is one of those Windows subsystems that nobody at Microsoft talks about loudly but that quietly logs months of per-process resource use into an ESE database. For DFIR it is the closest thing Windows ships to a built-in EDR audit log: which process ran when, under which user, on which network, how many bytes it pushed and pulled, and whether the machine was on battery while doing it. None of that is in Prefetch, Amcache, or any single EVTX channel.

What SRUM actually is

SRUM — System Resource Usage Monitor — is a Windows feature introduced in Windows 8 and present on every consumer and server SKU since. It runs as part of the Diagnostic Policy Service (DPS) and persists its samples into an Extensible Storage Engine (ESE) database at C:\Windows\System32\sru\SRUDB.dat.

The cadence is roughly:

• Per-application activity sampled every 60 minutes.
• Energy events (AC plug/unplug, sleep transitions) sampled on every state change.
• Network connectivity sampled on every network attach/detach.

Retention runs ~30 days for short-term tables and up to about a year for the long-term (LT) siblings, depending on activity volume. See SRUM data retention.

What you get out of it

The database holds several tables identified by GUID. The ones that matter:

Plus SruDbIdMapTable, which translates the integer AppId/UserId foreign keys on every data table back to a real application path or a Windows SID. Without it, every row says AppId = 47. With it, 47 becomes C:\Users\<suspect>\AppData\Local\Temp\loader.exe, and your investigation has a name.

The dedicated tables post walks the columns.

Why analysts reach for it

Specific questions SRUM answers that nothing else on disk answers as cleanly:

• Which process exfiltrated data, and how much? BytesSent per AppId per UserId per network. EDR often does not retain this long; SRUM does.
• Was this program running on a specific date? Application Resource Use rows survive months after Prefetch has rolled.
• Which user account was logged in when it ran? The UserId resolves to a SID, which the registry ProfileList maps to a user name.
• Was the device on AC or battery during the event? Energy Usage pins this to the second.

The overlap with modern EDR is real — and that is precisely why it matters. On hosts where EDR is missing or where the suspicious window predates EDR coverage, SRUM is often the most defensible per-process activity record available.

Where it lives, what you collect

C:\Windows\System32\sru\SRUDB.dat plus the entire sru\ directory (transaction logs SRU*.log, checkpoint SRU.chk). The acquisition guide covers the lock and the recovery story.

You also want the SOFTWARE registry hive — without it, network profile GUIDs do not resolve to friendly SSID names.

Common pitfalls before you trust the data

• Dirty database. If you copy SRUDB.dat from a live host you almost always catch it mid-flush. The header is marked dirty and a reader will skip recent pages. Replay logs first; see how to fix a dirty SRUDB.dat.
• Hourly bucketing. A five-minute browser session shows up as one 60-minute row. Do not claim minute-level precision from short-term tables.
• Tampering with SYSTEM. A privileged adversary can stop DPS and overwrite the file. Check the file's MFT entry on MFT for unexpected modification timestamps.

Further reading

• Where is SRUDB.dat located on Windows?
• SRUM tables explained
• How to parse SRUDB.dat without installing anything
• Using SRUM in a forensic investigation
• The ESE database format that powers SRUDB.dat
• SRUM vs Prefetch vs Amcache
• How to fix a dirty SRUDB.dat
• How long does SRUM keep data?
• Detecting data exfiltration with SRUM