Quick answer: The Event Log service lost its place in a .evtx file mid-read. Back up the logs, clear or repair the corrupt one with wevtutil, restart the Event Log service, and update or remove any third-party tool that reads Windows logs aggressively.
Why you're seeing 0X000005DF
Windows keeps every event log as a file on disk, usually in C:\Windows\System32\winevt\Logs. When Event Viewer, a monitoring agent, or a script opens one of those files, it takes a snapshot of the file's identity and position. If the underlying file gets rotated, cleared, or swapped while the reader still holds the handle, Windows returns ERROR_EVENTLOG_FILE_CHANGED with code 0X000005DF. The reader is looking at a file that no longer matches what it opened.
You'll hit this most often in three real situations. First, someone clears an event log in Event Viewer while a monitoring agent like Splunk Universal Forwarder, Datadog Agent, or an old version of SolarWinds is tailing it. Second, a scheduled task runs wevtutil cl on the same log a service is reading. Third, the .evtx itself is corrupt after an unclean shutdown, and the Event Log service can't reconcile the header with the record stream. I've seen it dozens of times on servers that log heavily and get cleared on a tight retention schedule.
The error isn't fatal to Windows. It's a reader-side failure. But if you ignore it, you'll lose log data you probably needed, and the same API call will keep failing every time the reader reconnects.
Main fix: repair the event log and restart the service
Do these in order. Don't skip the backup step. If the log is corrupt, you want the original file around in case you need to pull records later.
- Open an elevated Command Prompt. Click Start, type
cmd, right-click Command Prompt, and choose Run as administrator. You'll see a black window with an admin title bar. If you don't, close it and try again. - Stop the readers first. Any tool currently tailing the log needs to stop. Stop the Windows Event Log service and your monitoring agent. Run:
net stop wevtutil-service
net stop <YourAgentName>
sc stop eventlogIf the agent service name isn't obvious, run sc query state= all | findstr /i "event log" to list candidates. You should see "The following services are dependent on the Windows Event Log service" if anything else is holding it.
- Back up the log folder. Copy the whole Logs directory somewhere safe. This preserves every .evtx file in case you need to extract records with a tool like EvtxECmd later.
robocopy "C:\Windows\System32\winevt\Logs" "D:\evtx-backup" /E /R:1 /W:1You'll see a summary at the end listing files copied. If any file is locked, robocopy will report it, and that's a signal the reader is still running.
- Check the specific log for corruption. The
wevtutiltool can query a log's metadata without fully opening it. Run:
wevtutil gli Application
wevtutil gli System
wevtutil gli SecurityYou should get a block of XML showing the file path, creation time, last access time, max size, and retention. If wevtutil errors out on one of them, that's your corrupt file. Note the exact filename from the <channel> and <file> lines.
- Clear the corrupt log. This deletes the records but rebuilds a clean file. If you've already backed up (step 3), you're safe.
wevtutil cl Application /bu:D:\evtx-backup\Application.evtx
wevtutil cl System /bu:D:\evtx-backup\System.evtx
wevtutil cl Security /bu:D:\evtx-backup\Security.evtxOnly clear the log that's actually throwing 0X000005DF. Clearing everything wipes audit trails you may need for compliance. After each command, you should see no output. Silence means success. An error like "The parameter is incorrect" means the file is locked or the path is wrong.
- Start the service and readers. Bring things back online one at a time and watch Event Viewer for the error to return.
sc start eventlog
net start <YourAgentName>Within a few seconds you should see new records populating in Event Viewer. If 0X000005DF comes back immediately, the problem isn't the log file. It's the reader. Jump to the alternative fixes.
Alternative fixes if the main one fails
If clearing and restarting didn't do it, the corrupt file isn't your problem. Something else is.
Rebuild the .evtx from scratch
Sometimes wevtutil cl leaves a file the Event Log service can open but readers can't. Stop the Event Log service, rename the .evtx file, and let Windows recreate it on service start.
sc stop eventlog
ren "C:\Windows\System32\winevt\Logs\Application.evtx" "Application.evtx.bad"
sc start eventlogAfter the service comes up, you should see a brand-new Application.evtx in the Logs folder. The old one stays as Application.evtx.bad until you delete it. This works when the file header is damaged but the disk is fine.
Rule out third-party readers
Anti-malware products with behavior monitoring, endpoint detection tools, and log shippers are the usual suspects. I've seen McAfee Endpoint Security 10.7 and an outdated Splunk forwarder both trigger 0X000005DF on Windows Server 2016 after security log rotation. Update the agent to its current release, or set its log-read interval higher than the log's retention window. If you can't update, uninstall the agent and confirm the error stays gone for 24 hours. That tells you where the fault lives.
Check the registry keys for the log
Each log has a registry entry that defines its file path, size, and retention. A wrong value here throws the same error.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Application
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\System
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\SecurityLook at the File value under each. It should be a relative path like %SystemRoot%\System32\winevt\Logs\Application.evtx. If it points somewhere unexpected, fix the path and restart the Event Log service.
Run a disk check
If the error keeps coming back on different logs, the underlying disk may be the issue. Bad sectors will corrupt .evtx files faster than the service can rebuild them.
chkdsk C: /scanYou should see "Windows has scanned the file system and found no problems" if the disk is healthy. If it reports bad sectors, replace the drive before you chase this error further.
If you're on a virtual machine and see 0X000005DF across multiple logs, check the host's storage. I've watched ESXi datastores with thin-provisioned LUNs throw this error when they hit capacity mid-write.
Prevention tip
Don't clear event logs on a schedule that overlaps with your monitoring agent's read cycle. If your agent polls every minute, and you clear logs every hour on the hour, you'll eventually catch a reader mid-handle. Set log retention with the MaxSize and Retention registry values instead of clearing manually, and let Windows roll the file when it hits the cap. That keeps readers happy because the file is renamed, not truncated underneath them. Also bump the size from the default 20 MB. On a busy server, System and Application logs fill 20 MB in a couple of hours, and constant rolling is exactly the condition that triggers 0X000005DF in the first place.