Windows · Event Log · SRUM

Fixing the SRUJet event log flood

Tens of thousands of ESENT errors a day, quietly shredding your Application log — and why the fix most people are given is worse than the problem.

The symptom

Your Windows Application event log fills with ESENT errors logged by svchost as SRUJet. Usually one of these four:

Each ID marks a different stage of the same failure, and ESENT is a shared provider — not every ESENT error is SRUM. The ESENT SRUJet error reference covers what each one means, how to tell SRUM apart from Windows Update and Search, and how to count them.

Why it matters more than it looks

On the machine this was written from, the fault produced 40,899 errors in four days — one roughly every eight seconds.

The Application log is circular and capped at 20 MB by default. At that rate it rolls over in days. On the reference machine the Application log retained just 5 days of history while the System log still held 11 months. Every application crash record older than that was gone.

That is the real damage. SRUM itself — the System Resource Usage Monitor — only backs Task Manager's App History tab and per-app network usage stats. Nothing important depends on it. The flood is the problem, not the missing feature.

The cause

C:\Windows\System32\SRU is either missing, or exists with only inherited permissions from System32.

Inherited System32 rights give BUILTIN\Users read-only access. The Diagnostic Policy Service (DPS) runs as NT AUTHORITY\LocalService, which falls under Users — so it cannot write its database. DPS retries every eight seconds, and that retry loop is the flood.

There is a second wrinkle. sc qsidtype DPS reports RESTRICTED, meaning the service's token is access-checked against its service SID. Granting LocalService is not sufficient — the grant has to name DPS itself.

The fix

Grant the DPS service SID inheritable full control on one folder:

icacls C:\Windows\System32\SRU /grant "*S-1-5-80-2970612574-78537857-698502321-558674196-1451644582:(OI)(CI)F"

Service SIDs are derived deterministically from the service name, so that literal is the same on every Windows install. Using the SID rather than NT SERVICE\DPS also makes it locale-proof — the friendly form is translated on non-English Windows.

Why this shape is right

It mirrors what Windows already does for other service-owned data folders. Look at the event log's own directory:

C:\Windows\System32\winevt\Logs   NT SERVICE\EventLog:(OI)(CI)(F)
                                 NT AUTHORITY\SYSTEM:(OI)(CI)(F)
                                 BUILTIN\Administrators:(OI)(CI)(F)

The EventLog service also runs as LocalService, yet Windows grants its service SID — not LocalService — inheritable full control on its own data folder. This fix follows that convention rather than inventing one.

Verifying it worked — the trap

Do not verify with a fixed lookback window such as "errors in the last hour". That window spans the moment you applied the fix, so it is still full of pre-fix events and will report a successful repair as a failure.

Anchor instead to when the repair actually took effect. SRUDB.dat's creation time is the precise answer: DPS cannot create that file until permissions are right, so its birth is the success. On the reference machine:

last SRUJet error   01:08:55
SRUDB.dat created   01:08:56

Two further details worth knowing:

• Don't filter on event ID 483 alone. Creating the folder silences 483, but the fault simply moves to 488/413 if permissions are still wrong. A check watching only 483 reports a half-finished repair as complete success.
• Get-WinEvent -StartTime truncates to whole seconds, so anchoring exactly on a creation timestamp sweeps in retries logged milliseconds before it. A two-second guard fixes this.

The script

Repair-SrumDatabase.ps1 does all of the above — diagnosis, repair, and anchored verification. It is read-only by default; -Fix and -Revert are opt-in and require elevation.

# Read-only diagnosis. Changes nothing.
.\Repair-SrumDatabase.ps1

# Diagnose, repair, verify. Requires elevation.
.\Repair-SrumDatabase.ps1 -Fix

# Undo the permission grant.
.\Repair-SrumDatabase.ps1 -Revert

Get it on GitHub →

Honest caveats

• This is not an official Microsoft fix. No Microsoft documentation specifies the correct default ACL for System32\SRU. The grant is reasoned from how Windows treats comparable service-owned folders, plus the RESTRICTED service SID type. It is minimal in scope and reversible.
• Microsoft's own first-line advice is to ignore these errors if the system is otherwise fine. That's reasonable for a handful of stray events. It is not reasonable at 40,000 a day, when the flood is destroying your log history.
• Developed and tested on Windows 10 22H2 (build 19045). Should apply to Windows 8.1 through 11, but is untested there.
• If you'd rather not touch ACLs at all, stopping the Diagnostic Policy Service also stops the flood — at the cost of Task Manager's App History and some troubleshooters.

While you're here

The default 20 MB Application log is small for any busy machine. Whatever you decide about SRUM, this is worth doing:

wevtutil sl Application /ms:209715200   # 200 MB