If you're staring at ERROR_LOG_READ_CONTEXT_INVALID (0X000019CE) in your Server Manager or event viewer, I know exactly how annoying this is. It usually pops up after a sudden power loss, a forced reboot, or when a third-party backup tool grabs a log file mid-write. The Event Log service is trying to read a marshaling area — think of it as a staging buffer for log data — but the read context is invalid. Translation: the log file is corrupted or the service state is out of whack.
Let's walk through fixes in order of effort. Stop when your logs work again.
Fix 1: Restart the Event Log Service (30 seconds)
This clears transient glitches. It's the digital equivalent of turning it off and on again — and it works more often than you'd think.
- Open PowerShell as Administrator.
- Run:
Restart-Service EventLog -Force
If that throws an error, use:
Stop-Service EventLog -Force
Start-Service EventLog
Then check if the error repeats. Open Event Viewer and look at the System log. If you still see the error or the log won't load, move on.
Fix 2: Clear the Corrupted Log (5 minutes)
The error usually names a specific log — like Application or System. If a single log file is corrupt, clearing it removes the bad data. The log will rebuild from new events.
- Note which log is causing trouble. Look in Event Viewer under Windows Logs, or check the error details for the log name.
- Open PowerShell as Administrator.
- Clear that log using
wevtutil:
wevtutil cl Application
Replace Application with the actual log name — could be System, Security, or something custom like Microsoft-Windows-PowerShell/Operational.
If wevtutil fails, try the archive-and-clear approach:
wevtutil archive-log Application /autobackup
wevtutil cl Application
This backs up the existing log to %SystemRoot%\System32\winevt\Logs before clearing. Once cleared, the service writes fresh. If the error persists or you can't clear the log, the file itself might need to be removed.
Fix 3: Rebuild the Event Log Files (15+ minutes)
When clearing fails, the log file is too damaged to repair. Here's the nasty-but-effective fix: delete the physical .evtx file. The service will recreate it on next start.
Backup first. You'll lose old events, so if you need them for compliance, copy the file before deleting.
- Stop the Event Log service:
Stop-Service EventLog -Force
- Navigate to the logs directory:
cd %SystemRoot%\System32\winevt\Logs
- Rename the problem file instead of deleting outright (safer):
rename Application.evtx Application.corrupt
Change Application.evtx to match your corrupt log. If you're not sure which one, look for files with recent write timestamps and a size that's oddly large or zero.
- Restart the service:
Start-Service EventLog
The service will create a fresh, empty log file. Check Event Viewer — the error should be gone. If not, you might have a deeper issue.
When This Fix Doesn't Work: Deeper Checks
If the error returns after rebuilding, the corruption might be systemic. Here's what to look at:
- Disk errors — Run
chkdsk /fon the drive hosting the logs. Bad sectors can corrupt files repeatedly. - Antivirus interference — Some AV software locks log files during scans. Exclude the
winevt\Logsfolder from real-time scanning. - Third-party log shippers — Tools like Splunk Universal Forwarder or Syslog agents can hold read contexts open. Update or reconfigure them.
My honest take: most people hit this once after a crash, clear the log, and never see it again. If you're seeing it daily, look at what's hammering the Event Log service — that's your real culprit.
One last tip: always test these commands on a non-production server first if you can. I've seen a mis-typed log name take down the whole Windows Event Log system, and that's a much bigger headache than the original error.