Fix ERROR_LOG_RESTART_INVALID (0X000019CF) on Windows Server

I've seen this error pop up on a handful of Windows Server machines — mostly 2012 R2 and 2016, but it can hit 2019 too. The exact scenario: you reboot a server after a dirty shutdown — maybe a power outage or a hard crash — and the event log service won't start. You check System Log (the one that's still running) and see ERROR_LOG_RESTART_INVALID (0X000019CF). Or you're trying to open a specific log and get a blank screen or a popup with that hex code. Had a client last month whose file server did this after a UPS failure — the logs were toast.

The root cause is straightforward: the restart area of an .evtx log file got corrupted. Each Windows event log has a header and a restart area that tells the service where to start reading after a restart. When that area gets trashed — due to a crash during a write, a bad sector on the disk, or a forced shutdown mid-flush — the log service can't parse it. The error is the service saying "I can't find a valid starting point."

What you need before starting

Administrator access on the server
A backup of the corrupt log file — just in case
At least 20 minutes of downtime. This is not a hotfix

Step-by-step fix

Step 1: Identify the corrupt log

Open Event Viewer as admin. Look at the Application and Services Logs section. If a log is corrupt, it'll either show the error when you click it, or the service won't start. In my experience, it's usually System, Application, or Security — but I've seen it on DNS Server logs too. Check the System log (if it's still running) for event ID 0 from source Microsoft-Windows-Eventlog with the 0X000019CF code. That event tells you the log file path.

Step 2: Stop the Windows Event Log service

net stop EventLog /y

This kills the service and all its subprocesses. Note: you'll lose access to the GUI for a minute. That's fine. You can run this from an elevated Command Prompt or PowerShell.

Step 3: Locate the corrupt log file

The default location is C:\Windows\System32\winevt\Logs. Look for the file matching the corrupt log name — System.evtx, Application.evtx, etc. Right-click it, go to Properties, and uncheck Read-only if it's ticked (sometimes Windows locks these files). Then rename it to something like System.old.evtx. Don't delete it yet — you might want to inspect it later.

Step 4: Run chkdsk on the system drive

Corruption like this often signals a disk problem. Run this:

chkdsk C: /f

You'll get a prompt to schedule it on next reboot. Say Y and reboot the server. Let chkdsk run — it'll scan and fix any file system errors. On a large volume this can take 10-20 minutes. Don't interrupt it. After the reboot, stop the Event Log service again.

Step 5: Let Windows rebuild the log file

Restart the Event Log service:

net start EventLog

Windows will automatically create a new, empty .evtx file in the same folder. Wait 30 seconds, then open Event Viewer. The corrupt log should be gone, and the new one should show "0 events" or just system boot events. If the error reappears, the issue is deeper — see "If it still fails" below.

If it still fails

Three things to check:

Disk health — run wmic diskdrive get status in PowerShell. If you see "Bad" or "Pred Fail", replace the drive. The corruption is a symptom, not the root.
Registry corruption — open HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog in regedit. Look for any value under the corrupt log's key that points to a non-existent file. Delete that value. I've seen a stale registry reference keep the error alive after a log rename.
Third-party log shippers — if you run something like Snare or Winlogbeat, temporarily disable it. These tools can lock or corrupt log files during writes. Restart the Event Log service, check if the error clears, then reconfigure the shipper to buffer writes properly.

If none of that works, you're looking at a Windows repair install or a full reinstall. But I've fixed this exact error at least a dozen times with steps 1-5. The chkdsk step catches most people off guard — they skip it and wonder why the error comes back after a week.