Fix ERROR_LOG_CONTAINER_READ_FAILED 0x19EF

The 30-Second Fix: Check If the Log Service Is Running

What's actually happening here is that the Windows Event Log service (EventLog) can't read one of its container files — those are the .evtx files in C:\Windows\System32\winevt\Logs. A stopped service or a bad file handle can trigger 0x19EF. Run this in an admin terminal:

sc query EventLog | find /i "STATE"

If the state isn't RUNNING, start it:

net start EventLog

Then check the Application log for related errors. If the service starts but the error persists, move on.

The 5-Minute Fix: Find and Isolate the Corrupted Log

The error message in the Event Viewer will name the specific log container that failed. It looks like: "The log service encountered an error when attempting to read from a log container. The exact error code is: 0X000019EF. Container: Security". That Container: Security tells you which .evtx file is busted.

Use wevtutil to verify the log's health. For example, if the Security log is the culprit:

wevtutil gl Security

Look at the logFileName path. Then check the file's permissions — the EventLog service account (NT SERVICE\EventLog) needs Read access. Right-click that .evtx file, go to Properties > Security, and verify that the service account is listed. If it's missing, add it and give it Read. Then restart the service.

If permissions are fine, the file itself is corrupted. You can try archiving it:

wevtutil epl Security C:\backup\Security_old.evtx

This exports whatever readable events remain. Then clear the log:

wevtutil cl Security

That deletes the current corrupted container and starts a fresh one. If clearing succeeds, the error goes away. But if wevtutil cl fails with 0x19EF, the file is too damaged to even delete — that's the 15-minute fix territory.

The 15+ Minute Fix: Manually Replace the Corrupted Container File

When wevtutil cl also throws 0x19EF, you're dealing with a deeply corrupt container. The reason step 3 works is that we're bypassing the Event Log service entirely and replacing the file while the service is stopped.

1. Stop the Event Log service — this releases the file handle:

net stop EventLog

Don't forget: stopping this service will also stop the System event log, which might cause some tools to complain. That's fine — we're only down for a minute.

2. Rename the corrupted .evtx file. For the Security log:

ren C:\Windows\System32\winevt\Logs\Security.evtx Security_corrupted.evtx

3. Create an empty replacement file. The Event Log service expects the file to exist. A zero-byte file works:

type nul > C:\Windows\System32\winevt\Logs\Security.evtx

If you're on Server Core, use copy nul Security.evtx.

4. Restart the Event Log service:

net start EventLog

At this point, the service creates a fresh container structure inside that empty file. Your log will be empty, but the error is gone. If you need the old events, you can try loading the renamed _corrupted.evtx file into a tool like EvtxeCmd or FullEventLogView — those tools don't use the Event Log service and can sometimes salvage data from damaged containers.

When to Rebuild the Log Manually

I've seen this error on Windows Server 2019 and 2022 after an unexpected power loss or a disk write failure. The container's header gets corrupted in a way that the service can't parse. Renaming and replacing is the nuclear option, but it's also the only reliable fix I've found after years of dealing with this exact code.

One more thing: if you're running a domain controller, the Security log is critical for auditing. You'll want to set the log size to something reasonable (like 1GB) after the fix to prevent future corruption from excessive writes:

wevtutil sl Security /ms:1073741824

That's 1GB in bytes. The default is often 20MB, which fills up fast on a busy server and can trigger container read errors as the log wraps.