How to Use SrumECmd to Parse and Analyze SRUDB.dat Files

Intro

The Windows operating system maintains various logs and databases for performance monitoring, user activity tracking, and resource usage statistics. One such database is the SRUDB.dat file — System Resource Usage Database. For forensic analysis, performance troubleshooting, and security auditing, parsing and analyzing this database can provide valuable insights.

Eric Zimmerman's tool SrumECmd (currently v0.5.0.1) is designed to facilitate extraction and analysis of data from SRUDB.dat. It parses the database, optionally cross-references the SOFTWARE registry hive to resolve network names, and outputs clean CSV files ready for analysis in Timeline Explorer.

One underappreciated forensic advantage: SrumECmd can surface evidence of applications that no longer exist on disk. Because SRUM records execution data independently of whether the executable is still present, deleted malware or removed tools still leave traces in the database. If it ran, SRUM recorded it.

Section 1 — Prerequisites

Before you start, ensure you have the following:

SrumECmd — Download from Eric Zimmerman's official toolkit at ericzimmerman.github.io. Use the .NET 6 or Net 9version. Extract to a convenient location such as C:\Tools\ZimmermanTools\. No installation required.

SRUDB.dat — Located at C:\Windows\System32\sru\SRUDB.dat. On a live running system this file is locked by Windows — you cannot copy it with File Explorer. Use a forensic imager or live triage tool. Always work on copies, never originals.

SOFTWARE hive — Located at C:\Windows\System32\config\SOFTWARE. This is optional but strongly recommended. Without it, L2ProfileId values in the network tables remain as raw numbers and network names won't be resolved. Collect it at the same time as SRUDB.dat.

KAPE (Optional) — Available free for non-commercial use from Kroll at kroll.com. Automates the entire collection and parsing workflow and handles locked file access on live systems.

Section 2 — Running SrumECmd: Verified Command Syntax

There are two primary modes — file mode (-f) and directory mode (-d).

• Use -f when you know the exact path to your copied SRUDB.dat.

• Use -d when pointing at a folder, which is the mode used with KAPE — it recursively scans the directory and locates both SRUDB.dat and the SOFTWARE hive automatically.

You only need one or the other, not both.

In either case, --csv is required and must be a full path in double quotes. The -r flag for the SOFTWARE hive is optional but strongly recommended for any network investigation — without it, you'll have unresolved numeric network IDs throughout your output.

Open the command prompt as Administrator before running. Both modes are shown below with exact syntax taken from the official README.

Section 3 — Dirty Database: Official Repair Process

When you run SrumECmd against a SRUDB.dat copied from a live machine, you will almost certainly encounter this error:

"Error processing file! Message: Object reference not set to an instance of an object."

This means the database is dirty — it wasn't cleanly shut down before you copied it. This is the norm in incident response, not an exception.

The fix is a two-command esentutl repair process.

Section 4 — Output Files and Data Retention

After a successful run, navigate to your output directory. You'll find several CSV files — one per SRUM table parsed. Open them in Timeline Explorer for filtering, date ranges, and column pivoting.

Data retention is not uniform across tables.

• Application and process data is kept for approximately 30 days.

• Network usage data is retained for approximately 60 days.

This difference matters for your collection timeline — network evidence may extend twice as far back as application evidence, so don't assume they share the same window.

The application resource usage CSV is particularly valuable for malware hunting. SRUM records application execution independently of whether the file still exists on disk. Deleted executables still appear with their full path, the user SID that ran them, and execution timestamps. This is frequently the only remaining evidence of tools that were run and then cleaned up.

Section 5 — KAPE Integration (Corrected Syntax)

The correct KAPE syntax uses two separate flags: --tdest for where collected raw files are saved, and --mdest for where parsed module output is written.

.\kape.exe --tsource C: --tdest "F:\Output for testing" --target SRUM --gui

Additionally, there is a second KAPE module worth knowing about: PowerShell_SrumECmd_SRUM-RepairAndParse.

This module uses a PowerShell script (SRUM-Repair.ps1) to automatically handle the dirty state repair and then run SrumECmd in a single step. This is particularly useful when you know your source database is likely dirty and you want to automate the entire collect → repair → parse workflow.

Section 6 — Correlating with Other Windows Artifacts

SrumECmd CSV output becomes significantly more valuable when you correlate it against other Windows artifacts in Timeline Explorer. No single artifact tells the whole story — building a reliable timeline means cross-referencing multiple sources.

Prefetch is the most natural first check. If AppResourceUseInfo shows an executable running at a specific time, Prefetch should confirm the same execution. Discrepancies between the two are worth investigating — if SRUM has it but Prefetch doesn't, the executable may have been run in a way that bypasses Prefetch tracking.

UserAssist in the registry records interactive application launches via Explorer. If SRUM shows execution but UserAssist has no record, the application was likely launched programmatically rather than by the user clicking on it directly — relevant for distinguishing manual from automated actions.

Event Logs (specifically logon events 4624 and 4634) let you confirm which user accounts were active during time windows that show up in SRUM. Combining these with the UserId field in SRUM output builds a strong attribution chain.

Browser history and web artifacts explain the destination of high-volume network transfers recorded in SRUM network tables. If SRUM shows a browser process sending 800MB outbound, browser history tells you where it went.

Conclusion + Quick Reference

Eric Zimmerman's SrumECmd is a powerful tool for parsing and analyzing SRUDB.dat files, providing detailed insights into system resource usage and user activity. Whether you use it standalone or integrate it with KAPE for automated workflows, SrumECmd can significantly enhance your forensic and troubleshooting capabilities.

--------------------------------------------Dean--------------------------------------------------