Reference · ESENT · SRUJet

ESENT SRUJet error reference

Event IDs 483, 488, 413 and 490, logged by svchost as SRUJet with system error 5 (0x00000005): "Access is denied." — what each one actually means, and which stage of the same underlying failure it represents.

All four errors come from SRUJet, the ESE (Extensible Storage Engine) instance behind Windows SRUM — the System Resource Usage Monitor. They share a single root cause: the Diagnostic Policy Service cannot write to C:\Windows\System32\SRU.

Which ID you see tells you how far the service got before being denied. That makes them a useful diagnostic ladder rather than four separate problems.

Read the fix →

The failure ladder

Event	Blocked at	State of your machine
483	Creating the folder	`SRU` directory does not exist at all
488	Creating a log file	Folder exists; permissions still wrong
413	Writing the log	Companion to 488 — same cause, same moment
490	Opening the database	`SRUDB.dat` exists but cannot be opened read/write

Fixing 483 alone is a trap

Simply creating the missing folder silences 483 — and the fault moves straight to 488 and 413 if permissions are still wrong. A check watching only 483 will report a half-finished repair as complete success. Watch all SRUJet error IDs, not one.

The errors in detail

ESENT Event ID 483 — cannot create the folder

svchost (2120,P,98) SRUJet: An attempt to create the folder "C:\Windows\system32\SRU\" failed with system error 5 (0x00000005): "Access is denied. ". The create folder operation will fail with error -1032 (0xfffffbf8).

Means: The SRU directory is missing entirely, and the Diagnostic Policy Service is not permitted to create it under System32.
Typical cause: A privacy/debloat script or aggressive cleanup tool deleted the folder.
Volume: By far the loudest of the four. DPS retries roughly every 8 seconds, which is what produces floods in the tens of thousands per day.

ESENT Event ID 488 — cannot create the log file

svchost (2120,R,98) SRUJet: An attempt to create the file "C:\Windows\system32\SRU\SRUtmp.log" failed with system error 5 (0x00000005): "Access is denied. ". The create file operation will fail with error -1032 (0xfffffbf8).

Means: The folder now exists, but DPS still cannot write inside it. This is the error you get if you create the folder without granting the service access.
Typical cause: The folder carries only inherited permissions from System32, which grant BUILTIN\Users read-only.
Note: Usually appears once or twice, not in a flood — DPS tends to give up retrying after this stage. Silence here is not proof of success.

ESENT Event ID 413 — cannot write to the log drive

svchost (2120,R,98) SRUJet: Unable to create a new logfile because the database cannot write to the log drive. The drive may be read-only, out of disk space, misconfigured, or corrupted. Error -1032.

Means: The generic ESE consequence of the 488 above. It is logged in the same second and describes the same denial.
Do not be misled: The message suggests a read-only, full, or corrupted drive. In the SRUM case the drive is fine — it is a permissions failure. Check the ACL before you go hunting for disk problems.

ESENT Event ID 490 — cannot open the database

svchost (####,R,98) SRUJet: An attempt to open the file "C:\Windows\system32\SRU\SRUDB.dat" for read / write access failed with system error 5 (0x00000005): "Access is denied. ". The open file operation will fail with error -1032 (0xfffffbf8).

Means: The database file itself exists, but DPS cannot open it for read/write. The furthest along the ladder — everything is in place except the permission.
Typical cause: The ACL on SRUDB.dat or its parent folder was altered, often by a migration, restore, or a manual permissions change.

Is your ESENT error even SRUM?

This matters, because ESENT is a shared provider. Many Windows components use ESE databases, and they all log under the same source with the same event IDs. Event ID 490 on its own tells you almost nothing.

The instance name in the message is what identifies the owner. SRUJet means SRUM. Other common instances include:

Instance	Owner
SRUJet	SRUM — System Resource Usage Monitor (this page)
wuaueng.dll	Windows Update (`DataStore.edb`)
Windows.edb	Windows Search indexer
catroot2	Cryptographic services catalogue database
TxR / Rm	Transactional registry / Resource Manager

To see which one is actually flooding your log, group the last day's ESENT errors by ID and show a sample of each message:

Get-WinEvent -FilterHashtable @{
    LogName      = 'Application'
    ProviderName = 'ESENT'
    Level        = 1,2
    StartTime    = (Get-Date).AddDays(-1)
} -MaxEvents 60000 -EA SilentlyContinue |
  Group-Object Id | Sort-Object Count -Descending |
  Select-Object Count, Name, @{n='Sample';e={
      $m = ($_.Group[0].Message -replace '\s+',' ')
      $m.Substring(0, [Math]::Min(70, $m.Length))
  }} | Format-Table -AutoSize

Real output from the machine this reference was written on:

Count Name Sample
----- ---- ------
 8602 483  svchost (2120,P,98) SRUJet: An attempt to create the folder "C:\Window
    7 413  svchost (2120,R,98) SRUJet: Unable to create a new logfile because the
    7 488  svchost (2120,R,98) SRUJet: An attempt to create the file "C:\Windows\

That distribution is the ladder in miniature: 8,602 attempts to create the missing folder, then a handful of 488/413 from a repair attempt that created the folder but not the permissions.

Counting just the SRUM errors

Because ESENT is shared, filter on the message to isolate SRUJet:

$since = (Get-Date).AddHours(-24)
@(Get-WinEvent -FilterHashtable @{
    LogName      = 'Application'
    ProviderName = 'ESENT'
    Level        = 1,2
    StartTime    = $since
} -MaxEvents 60000 -EA SilentlyContinue |
  Where-Object { $_.Message -like '*SRUJet*' }).Count

Whatever you do, not this

The most widely circulated fix for these errors tells you to take ownership of C:\Windows as the group Everyone, applied to all subcontainers and objects. It hands every account on the machine control of your Windows directory. It is a serious security hole and it is not necessary — the real fix touches one folder.

Why it is worth fixing

SRUM itself is minor — it backs Task Manager's App History tab and per-app network usage statistics, and nothing else depends on it. Microsoft's own first-line advice is to ignore these errors if the machine is otherwise healthy.

That advice is reasonable for a handful of stray events. It is not reasonable at 40,000 a day. The Application log is circular and capped at 20 MB by default; at that rate it rolls over in days, destroying the application crash history you would otherwise use to diagnose real problems. On the reference machine the Application log retained just 5 days while the System log still held 11 months.

The flood is the damage — not the missing feature.

The fix, in full →