Amcache vs SRUM: presence vs long-window resource usage

If you have read Amcache vs Prefetch and Amcache vs ShimCache, the third Windows execution-evidence artefact to know is SRUM — the System Resource Usage Monitor.

SRUM and Amcache are even more different from each other than Amcache and Prefetch are. They overlap only in that both record "binaries that did something on this host." Beyond that they answer very different questions.

The headline differences:

SRUM records resource usage per application over a 30-60 day window. Amcache records presence with rich metadata, with a retention much longer than that.

For the broader Amcache reference, see the Amcache complete reference.

---

What SRUM is#

SRUM is the database backing the Windows System Resource Usage Monitor, the feature that powers the "Data usage" and "Power usage" panes in modern Windows settings. It lives at:

C:\Windows\System32\sru\SRUDB.dat

SRUDB.dat is an ESE database (the same format as mailbox.edb or the Active Directory database) with multiple tables, the most useful of which are:

Table	Contents
Application Resource Usage	CPU time, working-set bytes, I/O per application per hour.
Network Usage	Network bytes sent / received per application per hour.
Push Notification	Toast / push notification activity per application.
Energy Estimation	Power consumption estimates per application.

Each row is bucketed by hour and per application. The "application" is identified by an executable path or AppID. SRUM data is continuously updated by the SRUM service and rolled up daily into long-term aggregates.

SRUM's retention is typically 30–60 days but varies by build and configuration.

---

The fundamental difference#

Property	SRUM	Amcache
Storage	SRUDB.dat (ESE database)	Amcache.hve (registry hive)
Granularity	Per-application, per-hour	Per-file
Records hash?	No	Yes (SHA-1)
Records full path?	Yes	Yes
Records publisher?	No	Yes
Records executed?	Yes (implicitly — if usage > 0)	No (presence only)
Records CPU / network / I/O?	Yes	No
Records when it ran?	Yes — to the hour.	No (only inventory time).
Retention	30–60 days typical	Much longer (years on long-lived hosts).
Granularity of timestamps	Hour buckets	Second
Easy to parse?	Moderate (ESE — use SrumECmd)	Easy (use AmcacheParser)

The two artefacts are complementary, not overlapping. Use SRUM when you care about resource usage; use Amcache when you care about presence and metadata.

---

When SRUM wins#

"How much network did this binary send?"#

Amcache: no answer. SRUM: bytes-sent / bytes-received per application per hour. Critical for data-exfiltration investigations.

"Which applications ran in the last 30 days?"#

Amcache: no execution data. SRUM: every application with non-zero CPU or I/O in its hour buckets ran at that hour.

"Did this binary use the network at a suspicious time?"#

SRUM is the only artefact that gives you a per-hour breakdown of network activity per application. Cross-reference with VPN / firewall logs to identify exfiltration windows.

"What was the host's resource usage profile in the days before#

the incident?"

SRUM is the closest thing Windows ships to an "always-on performance recorder". Spikes in CPU, network, or I/O often point at attacker activity.

---

When Amcache wins#

"Was this binary present on the host?"#

SRUM only records binaries that did something. A binary that was on disk but never ran (or never used measurable resources) does not appear in SRUM. Amcache catches it.

"What is this binary's SHA-1?"#

SRUM does not hash binaries. Amcache does. You need Amcache for VirusTotal or TI-feed enrichment.

"Beyond the 30-60 day SRUM window"#

SRUM retention is short. Amcache routinely retains entries for months or years on long-lived workstations. For investigations covering events more than ~60 days ago, Amcache is often the only artefact with the data.

"Driver / device evidence"#

SRUM is about applications and resource usage. Amcache has dedicated InventoryDriverBinary and InventoryDeviceContainer schemas for kernel-mode and device artefacts.

"Cross-host hunt by hash or ProgramId"#

SRUM does not have hashes or ProgramIds. Amcache does. See Lateral movement and Amcache ProgramId pivoting.

---

The classic SRUM + Amcache pairing#

The combination is most powerful for exfiltration investigations:

1. From SRUM, find applications with anomalous network usage in the suspected exfil window (e.g. Network Usage rows showing gigabytes of bytes-sent for a binary that normally sends nothing).
2. From Amcache, take the same binary's path or executable name and look up its Hash, Publisher, LinkDate, and KeyLastWriteTimestamp. You now have a content hash to submit to VirusTotal and a first-seen approximation for when the binary arrived.
3. From Prefetch, confirm execution timestamps that align with the SRUM network spikes.

That three-way join — Prefetch (when did it run) + SRUM (what did it do) + Amcache (what is it) — is the canonical Windows execution- evidence workflow.

---

Quick decision table#

Your question	SRUM	Amcache
Was binary X on this host?	partial (only if used resources)	yes
What is binary X's SHA-1?	✗	✓
When did binary X first appear?	only if it used resources	✓
Did binary X use the network?	✓	✗
How many bytes did binary X send?	✓	✗
What was the host's CPU profile last week?	✓	✗
Long-window presence (>60 days)?	✗	✓
Driver / device evidence?	✗	✓
Cross-host hunt?	✗	✓

---

See also#

• Amcache complete reference — the artefact in full.
• Amcache vs Prefetch — execution evidence comparison.
• Amcache vs ShimCache — the other presence-evidence artefact.
• Amcache for malware investigation — how all four artefacts combine in a real intrusion playbook.

For a quick browser-side look at your hive, drop a file on the parser home page — it parses entirely in your browser.