Where is SRUDB.dat located on Windows?
5/17/2026
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:
-
Forensic image (E01, raw, AFF4). The cleanest path. Mount read-only, copy the directory.
-
Volume Shadow Copy. On Windows 10 / 11 and Server 2016+, let
esentutltake 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.datRun from
C:\Windows\System32\sru,esentutl /y SRUDB.dat /vssrec sru . /d C:\triage\clean\SRUDB.datalso replays the logs inside the snapshot, so the copy comes out clean. Do not reach forvssadmin create shadow: it only exists on Windows Server. On client Windows, the other way to get a snapshot is WMI (theCreatemethod ofWin32_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. -
KAPE. The
SRUMtarget collects thesru\directory plus theSOFTWAREhive in one command. -
Velociraptor. Collect
Windows.Triage.Targetswith theSRUMtarget (older releases:Windows.KapeFiles.Targets, tickSRUM) to pull the same set across a fleet, from a hunt or an offline collector.Windows.Forensics.SRUMis a different artifact: it parses on the endpoint and returns rows, not the database file. -
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
TimeStampspan 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.