SRUM: the System Resource Usage Monitor, table by table

SRUM is not a log that can be watched in real time. Each provider is an "extension" registered under HKLM\SYSTEM\CurrentControlSet\Services\SRUM\Extensions\{GUID}, and it keeps the current hour's running counters in the registry. The SRUM service — part of the Diagnostic Policy Service — flushes those counters into SRUDB.dat periodically (about once an hour) and at shutdown, aggregating them into hourly windows: one row per application, per user, per hour, per interface.

That two-stage design has a direct forensic consequence: SRUM survives a reboot, but it is never perfectly live. The most recent activity may still be sitting in the registry buffer, not yet written to the database — so the last hour before an image was taken can be incomplete on disk.

The Extensible Storage Engine (ESE, historically "JET Blue") is Microsoft's embedded, transactional, indexed-sequential database engine. It is not SQL — it is a low-level B-tree store that Windows uses wherever it needs a fast local database: Windows Search, the certificate store, and SRUM all sit on it. Three names appear for essentially the same thing — they are defined side by side below.

An ESE database is a set of tables whose definitions live in an internal catalog, MSysObjects. SRUM's tables are named by provider GUID (e.g. {D10CA2FE-…}), plus the SruDbIdMapTable and a SruDbCheckpointTable. Large values are stored out-of-row as long values. The engine keeps a checkpoint (SRU.chk), a flush map (SRUDB.jfm) and transaction logs (SRU*.log) so an unclean shutdown can be recovered.

Two practical consequences follow. First, the file is locked on a running system — the DPS service holds it open, so it cannot simply be copied. Second, a database that was not cleanly closed is "dirty" and must be recovered (log replay) or repaired before it will open — which is exactly why forensic tooling reaches for the native ESE engine or a dirty-tolerant reader rather than a naive parser.

Each hourly window is a wide row of counters. Across the providers, SRUM captures CPU cycle time (foreground and background), disk bytes read and written, network bytes sent and received per interface, connection windows, focus / keyboard / mouse seconds, and battery / energy state. Multiply that by every application and every user, once an hour, for weeks, and SRUM becomes one of the densest behavioural records on the machine — often tens of megabytes of SRUDB.dat holding many thousands of rows.

The cost of that density is that the database is a rolling window. Once activity ages past the retention period (roughly 30–60 days), the oldest hourly buckets are purged to make room. SRUM answers "the last month or two," not "the life of the machine" — so it is a time-limited artifact, best collected promptly.

Why a case often holds far less than 60 days. That range is a typical ceiling, not a guarantee — retention is bounded by volume, not by a timer counting down days. A busy machine with many applications and several user accounts writes wide hourly rows quickly, fills the window, and starts overwriting its oldest hours sooner — heavy use can shrink real coverage to a couple of weeks. A lightly used machine can hold longer. And anything that resets the store cuts it shorter still: stopping the SRUM service, deleting or clearing SRUDB.dat, a corruption-triggered rebuild, or reimaging. So the earliest row present is the floor of what this machine kept, not as proof of when activity began.

A provider row does not store an app name or a user name. It stores small integers — an AppId, a UserId, an interface id. The SruDbIdMapTable maps each IdIndex to its real value in IdBlob, tagged by IdType:

• IdType = 3 → a binary SID — decoded structurally into S-1-5-… so it joins cleanly against the registry's user list. (Decoding it as a string via the wrong API yields a broken PySID: value that never matches — a real trap.)
• IdType = 0 / 1 / 2 → an application identity, a UTF-16LE string. Two forms appear: a device path (\Device\HarddiskVolume3\…\svchost.exe [DcomLaunch], used by the resource and network tables) and the timeline's !!svchost.exe!2054/02/06:15:19:25!1642e![netsvcs] [Winmgmt] form.

• Execution with a cost. Where Prefetch says a program ran, SRUM says how much CPU, disk and network it used, hour by hour — and keeps it for weeks after Prefetch has rolled over.
• Data exfiltration. bytes_sent per application, per hour, is often the cleanest evidence that a process moved gigabytes off the machine, and exactly when.
• Human presence. In the Application Timeline, a non-NULL keyboard_input_s or mouse_input_s is strong evidence a person was physically at the keyboard in that window. A service accrues CPU for hours and never sees a keystroke, so NULL there means "no such activity," not a decode failure.
• Attribution. Every row carries the resolved user SID, tying the activity to an account.

• Time-boxed. ~30–60 days only. Older activity is gone — collect SRUM early.
• Hourly, not instant. A row dates the window, not the exact second an event happened (except the precise FILETIME columns).
• Can be disabled. The SRUM service can be stopped or its providers disabled; deleting SRUDB.dat destroys history (though the current hour may still be in the registry buffer, and file recovery may recover the deleted database).
• Sparse by design — and why NULL is meaningful. SRUM writes a value only when that activity actually occurred, so an empty cell is a positive fact, not a gap in the data. A background service that never had a window on screen shows NULL keyboard and mouse seconds — that reads as "no human interaction," which is exactly what happened. A desktop with no battery shows NULL energy — "there was nothing to measure." The distinction that matters forensically: NULL here means "this did not happen," not "the parser failed to decode it." So a NULL is evidence in its own right — energy columns are populated mostly on laptops, and timeline input columns only on windows with real user interaction.
• Dirty databases. An uncleanly-closed SRUDB.dat needs ESE recovery or repair before it opens — a naive reader will fail or return partial data.

The evidence file is opened read-only and never written to; recovery for a dirty database is handled by the ESE engine itself. The live path uses the Windows native JET API through ctypes; the offline path prefers dissect.esedb because it tolerates dirty databases better, falling back to pyesedb / libesedb and, in the worst case, an esentutl /p repair. The result is one queryable SQLite database, srum_data.db.

Every native column, nothing dropped. Crow-Eye reads every column each provider table defines — not a fixed subset. That includes the battery-health columns (designed_capacity vs full_charged_capacity is battery wear), the network wake_count, and the Application Timeline's full set of *_timeline and *_breakdown packed counters. Every metric is stored as a raw integer; formatting is left to the display layer so sorting and range filters stay correct.

Nothing left in the logs. Because the newest activity is committed to SRU*.log before it is flushed into SRUDB.dat (see section 2), Crow-Eye records what state the database was in: a clean database reports db_state = clean with the ESE header's “Clean Shutdown, Log Required 0-0” proof — meaning everything was already flushed and there was nothing in the logs to recover. A dirty database (an image captured mid-write) reports recovered, because the logs were replayed to fold in exactly that unflushed activity. Either way the metadata row states plainly whether any data was still pending.

The finished srum_data.db is a first-class citizen of the case: Timeline plots its window timestamps alongside every other artifact, Database Search queries it directly, Eye AI reads it to answer questions like “what sent data the night of the incident?”, and the activity dashboard charts it interactively — the same evidence, seen four ways.

Why five heat-maps but only four timelines

A heat-map counts records, and all five providers write records — so there are five heat-maps. The timeline below is different: it plots one bubble per app per hour and sizes each bubble by a magnitude. Only four metric families give an app a per-hour magnitude worth sizing — network bytes, CPU cycles, disk bytes and presence seconds — so there are four timeline modes.

Network Connectivity and Energy have no per-app activity magnitude to size a bubble: connectivity is about when an interface was up, and energy is a battery charge level, not an amount an app “did”. They still earn a heat-map (record volume still shows when they were active), and Energy's charge shows up as the battery % line inside an app's pop-up — just not as a timeline mode.

The three regions

Left — the five heat-maps, then the day section for whichever day is selected: the bubble timeline above, and below it Activity by hour (stacked bars, one colour per provider), Top applications (each app's bar split by provider), a Records by provider breakdown for that day, and user-presence tiles (keyboard / mouse / in-focus).

Right — the overview, scoped to the whole selected date range rather than one day: totals tiles (active days, distinct apps, bytes sent, bytes received, CPU cycles, user presence); a Network activity card (bytes sent vs received per day, plus the top apps by network); Most active applications and Activity by user, both bars split by provider colour; and a Records by provider total.