← Back to parser

Where is SRUDB.dat located on Windows?

SRUDB.dat lives at the same path on every supported Windows version since 8. The acquisition story is what catches people — the Diagnostic Policy Service holds an exclusive handle while the system is up, and half the recent activity is sitting in the transaction logs rather than the main file.

The path

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

Plus everything else in that directory:

C:\Windows\System32\sru\
  SRUDB.dat        # the ESE database
  SRU.log          # current log
  SRU0000xxxx.log  # rotated logs
  SRU.chk          # checkpoint file

Same path on Windows 8, 8.1, 10, 11, and Server 2012 R2 onward.

Why you need the whole directory

ESE is a write-ahead-log engine. Recent transactions live in the SRU*.log files until the engine flushes them into the database. If you grab only SRUDB.dat, you miss:

  • Rows that were committed in the last hour or two of activity.
  • The "clean shutdown" marker that lets a read-only parser open the file without warnings.

Pull the entire sru\ tree. Pull the SOFTWARE registry hive at the same time — it carries the NetworkList\Profiles GUID-to-SSID mapping you need to render network names in Network Data Usage. The registry parser renders that hive without effort.

Acquiring the file

The file is locked while DPS is running. Options that work:

  1. Forensic image (E01, raw, AFF4). The cleanest path. Mount read-only, copy the directory.

  2. Volume Shadow Copy. On Windows 10 / 11 and Server 2016+, let esentutl take the snapshot and copy the file out of it, from an administrator prompt:

    esentutl /y C:\Windows\System32\sru\SRUDB.dat /vss /d C:\triage\SRUDB.dat
    

    Run from C:\Windows\System32\sru, esentutl /y SRUDB.dat /vssrec sru . /d C:\triage\clean\SRUDB.dat also replays the logs inside the snapshot, so the copy comes out clean. Do not reach for vssadmin create shadow: it only exists on Windows Server. On client Windows, the other way to get a snapshot is WMI (the Create method of Win32_ShadowCopy, e.g. from PowerShell), then copy from the \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopyN\ device it creates. Either way the snapshot is not blocked by the lock.

  3. KAPE. The SRUM target collects the sru\ directory plus the SOFTWARE hive in one command.

  4. Velociraptor. Collect Windows.Triage.Targets with the SRUM target (older releases: Windows.KapeFiles.Targets, tick SRUM) to pull the same set across a fleet, from a hunt or an offline collector. Windows.Forensics.SRUM is a different artifact: it parses on the endpoint and returns rows, not the database file.

  5. FTK Imager / X-Ways / Magnet AXIOM Process. Direct-disk reads bypass the lock.

Copying SRUDB.dat from a live host without VSS does not work — the file handle is FILE_SHARE_READ | FILE_SHARE_WRITE denied. PowerShell Copy-Item will fail. robocopy /B does not help either: backup mode (SeBackupPrivilege) bypasses file ACLs, not the sharing mode of a handle another process holds open, so it hits the same sharing violation. A snapshot copy, on the other hand, is usually in Dirty Shutdown state (the database was open when the snapshot was taken): bring the logs along and replay them, or use /vssrec.

When you opened a dirty database

esentutl /mh SRUDB.dat reports state. Anything other than Clean Shutdown means the logs in the same directory carry uncommitted transactions:

esentutl /r sru /l <log_dir> /s <checkpoint_dir>

Run it on a copy, from the folder that holds the copied SRUDB.dat together with its SRU*.log and SRU.chk files (cd there first and point /l and /s at that same folder). Then check with esentutl /mh SRUDB.dat that the copy now reports Clean Shutdown.

See how to fix a dirty SRUDB.dat for the full sequence.

When the file does not exist

  • Windows 7 and earlier. No SRUM. The service was introduced in Windows 8 / Server 2012.
  • Stripped Windows images. Certain kiosk and locked-down enterprise builds disable DPS. The directory exists but the database may be empty or stale.
  • Custom server builds with telemetry minimised. Same story — empty SRUDB.dat. Verify by checking the TimeStamp span in Application Resource Use; a one-hour window means the service was recently re-enabled.

Further reading

Frequently asked questions

What is the full path of SRUDB.dat?

C:\Windows\System32\sru\SRUDB.dat on all Windows versions from 8 through 11. It is accompanied by transaction logs (SRU*.log) and a checkpoint file (SRU.chk) in the same directory.

Can I copy SRUDB.dat while Windows is running?

No. The SRUM service (Dps) keeps an exclusive handle on the file. Copy it out of a Volume Shadow Copy (`esentutl /y ... /vss` as admin), use a forensic imager such as FTK Imager, or collect it with KAPE or Velociraptor, which read the raw NTFS volume.

Does SRUDB.dat exist on Windows Server?

Yes, on Server 2012 R2 and later when the Diagnostic Policy Service is running. The file may be smaller because consumer workloads (Modern apps, energy tracking) are absent.

Is SRUDB.dat encrypted?

No. SRUDB.dat is a plain Extensible Storage Engine (ESE) database. Rows are sometimes XPRESS-compressed but never encrypted at rest.

What other files do I need to grab with SRUDB.dat?

For a complete acquisition: the entire C:\Windows\System32\sru\ directory (logs and checkpoint replay any uncommitted transactions), plus the SOFTWARE registry hive if you want to resolve network profile GUIDs to friendly names.