Fix ERROR_LOG_CONTAINER_OPEN_FAILED (0X000019F1) Fast

Quick Fix (30 Seconds): Restart the Event Log Service

This is the first thing I try on any machine hitting 0X000019F1. Nine times out of ten, the Event Log service just glitched—maybe a memory hiccup, maybe a file handle got orphaned. Either way, a restart clears the state.

1. Open an elevated Command Prompt (right-click, Run as Administrator).
2. Type: net stop eventlog && net start eventlog
3. Wait 5 seconds. Check Event Viewer again.

If the error's gone, you're done. If not, the log container itself is probably corrupt. Move to the moderate fix.

Moderate Fix (5 Minutes): Find and Nuke the Corrupt Log

The culprit here is almost always a single corrupt .evtx file. The error code doesn't tell you which one, but we can find it quickly.

First, figure out which log is failing. Open Event Viewer and look for any logs that show a red X or fail to load. Common ones: System, Application, Security, or custom logs like Microsoft-Windows-.../Operational. If you can't spot it, run this command to list all logs and their status:

wevtutil el | wevtutil gl

That spits out all log names and their configuration. Look for one that shows enabled: false unexpectedly or has a weird logFileName path. The real giveaway is when you try to open a log in Event Viewer and it throws an access error or hangs—that's your target.

Once you've identified the bad log (let's say it's Microsoft-Windows-TaskScheduler/Operational), run:

wevtutil cl "Microsoft-Windows-TaskScheduler/Operational"

This clears the log—nukes all existing events but keeps the log container itself intact. If the container file is physically damaged, you'll get a new error. In that case, you need to delete the file outright.

Find the actual .evtx file path with:

wevtutil gp "Microsoft-Windows-TaskScheduler/Operational" /ge

Look for logFileName. Default path is %SystemRoot%\System32\winevt\Logs\. Stop the Event Log service again (net stop eventlog), delete that specific .evtx file, then restart the service. Windows will recreate it clean on next log write.

If the error still shows, skip to the advanced fix—this is deeper corruption in the event log provider registration.

Advanced Fix (15+ Minutes): Re-Register Event Log Providers

You're here because the log container itself is fine, but the EventLog provider that writes to it is borked. This happens a lot on Windows Server 2016/2019 after a failed update or a third-party tool that hoses the registry keys under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\.

First, check if the provider is missing or corrupted:

1. Open Regedit.
2. Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\.
3. Expand that key. You'll see subkeys for each log (System, Application, Security, etc.).
4. Find the log that was failing. If it's missing, that's your problem. If it's there but has no Sources subkey or the Sources subkey is empty, same deal.

If the registry key exists but is incomplete, you can try repairing it by re-registering the provider. For built-in Windows logs, the cleanest way is to use wevtutil to uninstall and reinstall the provider manifest:

wevtutil um "C:\Windows\System32\winevt\Manifests\Microsoft-Windows-TaskScheduler.man"
wevtutil im "C:\Windows\System32\winevt\Manifests\Microsoft-Windows-TaskScheduler.man"

Replace Microsoft-Windows-TaskScheduler with the actual provider name that's failing. If you don't know the provider, search the error in Event Viewer—it usually shows the provider GUID or name.

If that doesn't work, the nuclear option: rebuild the entire EventLog registry key from a backup. On a healthy machine of the same OS version and build, export the entire HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog key and import it on the broken machine. But don't just blindly do this—compare the ServiceDLL values first, they can differ between OS versions. And back up your own EventLog key first (reg export HKLM\SYSTEM\CurrentControlSet\Services\EventLog C:\backup\eventlog_bak.reg).

Last resort: run sfc /scannow and dism /online /cleanup-image /restorehealth. I've seen these fix weird log service issues maybe 10% of the time, but it's worth a shot before you try a repair install of Windows.

Pro tip: Always check disk space before any of this—if the winevt\Logs folder is on a drive with less than 10% free space, the log service can't create new containers. Free up space first, then restart the service.

If none of this works, you're probably dealing with a deeper OS corruption. A repair install (in-place upgrade) of Windows or Server should fix it. But that's an hour-long fix, not 15 minutes.