SRUM on Windows 11: Reconstructing App, Network and Power Use

What SRUM Answers That Nothing Else Does

Every other execution artifact tells you a program ran. SRUM tells you how much data it moved.

The System Resource Usage Monitor was built so Windows could show you the Data Usage screen in Settings. As a side effect it maintains roughly 30 days of per-application, per-user, roughly-hourly records of CPU cycles consumed, bytes sent, bytes received, and which network interface was in use.

For two questions in particular there is no substitute:

• Was this thing exfiltrating data? A background process with gigabytes in the sent column is not ambiguous.
• What was hammering the CPU at 3am last Tuesday? SRUM has an hourly bucket for it.

The Database

C:\Windows\System32\SRU\SRUDB.dat is an ESE (Extensible Storage Engine) database — the same engine behind Exchange and the Windows Search index. Alongside it sit SRU*.log transaction logs.

The tables are named by GUID rather than anything readable, and the mapping from GUID to meaning lives in the SOFTWARE registry hive, not in the database. This is why every SRUM parser asks for SOFTWARE as a second input — without it, application IDs stay as numbers instead of resolving to executable paths.

The tables that matter:

| Table | Contents | |---|---| | Network Data Usage | Bytes sent/received per app, per interface, per hour | | Network Connectivity | Which network the machine was on, and when | | Application Resource Usage | CPU cycles, foreground/background time, disk I/O per app | | Energy Usage | Battery drain per app (laptops) |

Step 1: Collect the database, its logs, and the SOFTWARE hive

All three, or the parse will be incomplete or unreadable:

robocopy C:\Windows\System32\SRU C:\cases\srum /E
robocopy C:\Windows\System32\config C:\cases\srum SOFTWARE SOFTWARE.LOG1 SOFTWARE.LOG2

SRUDB.dat is locked on a running system. If robocopy fails, work from a disk image or use a raw-access copy tool — do not try to force it on a live machine that matters.

Step 2: Parse with the SOFTWARE hive supplied

SrumECmd.exe -f C:\cases\srum\SRUDB.dat -r C:\cases\srum\SOFTWARE --csv C:\cases\out

-r points at the registry hive. Skip it and the output is populated with unresolved IDs.

You get one CSV per table. Open *_NetworkUsages.csv first.

Step 3: Sort network usage by bytes sent

BytesSent descending, and read down the ExeInfo column.

The top of that list on a normal machine is a browser, a cloud sync client, Windows Update, and a mail client. What draws attention:

• An executable running from AppData, Temp, or ProgramData with meaningful volume
• A system-sounding binary with a sent/received ratio the real component would never produce
• Sustained transfer during hours the machine's user was not present
• Any process you cannot account for at all

Note the ratio, not just the total. Normal browsing is heavily received-weighted. A process with far more sent than received is moving data off the machine, which is a different shape entirely.

Step 4: Pin down the timing

The Timestamp column buckets to roughly an hour. Filter to a single suspicious executable and sort chronologically. You are looking for:

• When transfer started — often the clearest available estimate of when a compromise became active
• Whether it is continuous or periodic — regular hourly or daily buckets suggest scheduled beaconing rather than a person
• When it stopped, if it did

Step 5: Establish which network it happened on

Cross-reference *_NetworkConnections.csv for the same time window. This resolves whether the transfer happened on the corporate LAN, home Wi-Fi, or a tethered phone — which materially changes what it means and who else needs to know.

Step 6: Corroborate

SRUM shows volume, not content. Before drawing conclusions, confirm the process itself:

• Prefetch for run count and history
• Amcache for the SHA-1, so you can identify the binary
• The firewall log for destination addresses, if it was enabled

Limits Worth Knowing

Roughly 30 days, and that is not guaranteed. Retention depends on activity and available space. Check the oldest timestamp in your parse before treating absence as meaningful.

Data is buffered in the registry before it is committed. Recent activity — up to about an hour — may sit in HKLM\SYSTEM\CurrentControlSet\Services\rdyboost\Parameters\Srum rather than in the .dat. On a live capture you can miss the most recent hour.

No destinations. SRUM records volume per application, not the IP addresses it talked to. For destinations you need firewall logging, Sysmon Event ID 3, or a network capture.

Hourly granularity. Fine for "when did this start", useless for correlating events seconds apart.

Related

• Windows 11 forensic artifacts overview
• Reading the Windows firewall log
• Consumer guide: removing cryptominer malware — SRUM's CPU history is how you confirm the timeline there

FAQ

Why does my SRUM parse show numbers instead of program names?

You did not supply the SOFTWARE registry hive. The mapping from SRUM's internal application IDs to executable paths lives in the registry, not in the database. Re-run with -r pointing at a copy of C:\Windows\System32\config\SOFTWARE.

Does SRUM record which IP addresses a program connected to?

No. It records bytes sent and received per application, per interface, per hour — volume only. For destination addresses you need the Windows firewall log with logging enabled, Sysmon Event ID 3, or packet capture. SRUM tells you something moved and roughly when; it cannot tell you where.

Can SRUM be cleared?

SRUDB.dat can be deleted with administrator rights, and Windows will recreate it empty. As with other artifacts, that is conspicuous: a machine with months of uptime and a SRUM database starting yesterday is anomalous on its face. There is no supported way to selectively remove individual entries.

Is SRUM present on desktops, or only laptops?

Present on both. The Energy Usage table is only meaningful on battery-powered devices, but Network Data Usage and Application Resource Usage populate on desktops exactly the same way.