How long does SRUM keep data? Retention and registry settings

SRUM retention is not "30 days" or "60 days" — it is whatever the machine actually has, which is a function of pruning policy, activity volume, and whether anyone disabled the service. The first thing to do on any case where SRUM matters is verify the real window, not assume.

The practical answer

• Short-term tables (Application Resource Use, Network Data Usage, Network Connectivity, Energy Usage, Push Notifications): roughly 30 days of hourly-bucketed rows.
• Long-term tables (the {…}LT siblings): up to roughly a year, aggregated weekly.

Neither figure is a hard guarantee. Retention emerges from age-based pruning plus row volume.

What governs it

There is no single "keep SRUM for N days" checkbox. Retention is controlled by several moving parts:

1. The Diagnostic Policy Service (DPS). Schedules the periodic flush — hourly by default, every ~10 seconds on AC/DC power-state change. Stopping DPS halts new sampling.
2. The SRUM extension registry. HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SRUM\Extensions lists each GUID-named extension and its parameters. The registry parser renders this cleanly.
3. Pruning passes. Old short-term rows are dropped as the database is maintained; the LT tables receive aggregated rollups before the originals age out.
4. Database size. ESE has its own pruning thresholds when the file grows beyond expected sizes.

What this means for an investigation

• An incident older than ~30 days likely only survives in the LT tables. Expect weekly aggregates, not hourly detail. Check both short-term and LT for the same GUID prefix.
• A gap in the TimeStamp sequence where you would expect activity is itself evidence: the service was stopped, the machine was off, or someone tampered with the database. Cross-check with Energy Usage's power-state events and EVTX service events (Microsoft-Windows-Diagnosis-DPS/Operational).
• Do not over-claim precision. A single 30-minute session can appear as one hourly bucket. See using SRUM in a forensic investigation for the resolution caveats.

Verifying retention on a sample

Do not trust the FAQ — read the database. In any parser:

1. Open Application Resource Use.
2. Sort by TimeStamp ascending. Read the earliest row.
3. Sort descending. Read the latest row.
4. That span is the actual short-term window for this specific host.

Repeat against the LT sibling for the long-term window.

A typical office workstation shows 28-32 days short-term and 8-11 months LT. A laptop that has been turned off for weeks will show fewer days of short-term coverage even though the database itself spans longer.

Tampering and gaps

A privileged adversary can:

• Stop DPS to halt sampling. EVTX Microsoft-Windows-Diagnosis-DPS often records the stop.
• Delete SRUDB.dat. The file will reappear at next service start but with zero history. The MFT entry records the recreation.
• Selectively delete rows. Harder; requires opening the ESE database directly. Detectable by gaps in TimeStamp continuity against expected uptime.

The most common adversary move is the lazy one: stop DPS, do the work, restart DPS. The gap shows up as a hole in the Application Resource Use timeline against the same window in Energy Usage (which records the AC events independent of process activity, until the service is gone).

Further reading

• What is SRUM and why forensic analysts care
• SRUM tables explained
• How to fix a dirty SRUDB.dat