What's actually happening here
The error 0X000019F0 (ERROR_LOG_CONTAINER_WRITE_FAILED) means the Event Log service couldn't commit data to one of its log container files. Those are the .evtx files in C:\Windows\System32\winevt\Logs. When a write fails, the service usually stops logging or the event viewer shows this error instead of event data.
I've seen this on Windows Server 2016 and 2019 most often, but it can hit any modern Windows. The root causes are usually one of three things: a corrupted container file, a full disk, or the service's account losing write permission on the log folder. Sometimes it's a combination—disk filled up, service crashed, and now the file is in a weird state.
Here's a troubleshooting flow. Start with fix 1, test, and only move on if it doesn't work. You can stop at any point where events start logging again.
Fix 1: Restart the Event Log service (30 seconds)
This sounds too simple, but temporary glitches happen. The service might have hit a transient I/O error—a disk hiccup, antivirus locking the file, or a backup tool grabbing the handle. Restarting clears the in-memory state and forces a fresh attempt.
- Open PowerShell as Administrator.
- Run:
Restart-Service EventLog -Force - Check if the error still appears in Event Viewer under Windows Logs > System.
If the error doesn't come back, you're done. If it does, move on. The reason a restart sometimes fixes it: the service reopens each container file with a clean handle, which can bypass a stale lock left by a crashed subprocess.
Fix 2: Clear the affected log (5 minutes)
The container file itself might be corrupted. A partial write during a power loss or an abrupt shutdown can leave the .evtx file in an inconsistent state. The Windows event log format is a binary structure with checksums—once a checksum mismatches, every subsequent write fails.
First, find which log is failing. In Event Viewer, look at the details of the error event. The message says "a log container" but doesn't name it. You need to check each log's status:
- Run in PowerShell:
Get-WinEvent -ListLog * | Where-Object {$_.IsEnabled -eq $true} | Select-Object LogName, RecordCount, FileSize - Look for a log with a file size that seems stuck—maybe 0 bytes or exactly 68MB (the max default). Also check for logs that show errors when you open them.
- Once you identify the log (say, "Application"), clear it with:
wevtutil cl Application
If wevtutil fails because the container is corrupted, you'll need to delete the file directly. But first stop the service:
Stop-Service EventLog -Force
Remove-Item "C:\Windows\System32\winevt\Logs\Application.evtx"
Start-Service EventLogWindows will recreate the file automatically when the service starts. Note: you'll lose historical events in that log. For a production server, that's not ideal, but it's better than a broken log. Back up the file first if you need it for compliance—copy it to another drive before deleting.
Fix 3: Check disk space and file permissions (15 minutes)
If clearing the log didn't help, the problem is likely environmental. Here's the deeper inspection.
3a. Disk space
The event logs have a default max size, but the container write can also fail if the disk is completely full. Windows doesn't reserve space for the event log service. Check the volume where the logs live (usually C:):
Get-PSDrive C | Select-Object Used, FreeIf free space is under 1GB, that's your problem. The service needs room to create temporary files and write new entries. Clear temp files, expand the volume, or move the logs to another drive. To move logs, you can change the log path via registry, but that's a separate article—simpler to free space first.
3b. Permissions on the winevt folder
The Event Log service runs under the LocalService account. If that account lost access to the log folder—maybe a security policy pushed changed ACLs—every write fails. Check the folder's permissions:
icacls C:\Windows\System32\winevt\LogsYou should see an entry for NT SERVICE\EventLog with (OI)(CI)F or at least M. If it's missing, grant it:
icacls C:\Windows\System32\winevt\Logs /grant "NT SERVICE\EventLog":(OI)(CI)MThat gives Modify permission, which is enough for the service to create and write container files. Don't grant Full Control unless you have a specific reason—least privilege applies even to system services.
3c. Antivirus interference
Real-time scanning of .evtx files can cause write conflicts, especially on Server 2016 with older AV engines. I've seen this twice in production—the AV would hold the file open for scanning while the log service tried to write. If you suspect this, add the winevt folder to your AV's exclusion list. Most enterprise AVs allow path-based exclusions.
3d. Corrupted system files
If none of the above worked, the event log service itself may be damaged. Run an SFC scan:
sfc /scannowThat checks system files. For a deeper check, run DISM /Online /Cleanup-Image /RestoreHealth. These take 10-15 minutes but can fix underlying corruption that manifests as log write failures.
When to escalate
If you've cleared the log, verified disk space, fixed permissions, and still see the error, it's time to look at the physical disk. Check the system event log for disk errors like Disk or Ntfs entries. Run chkdsk /f on the volume during a maintenance window—it'll require a reboot. Bad sectors on the disk can cause exactly this error: the log service tries to write, the disk returns an I/O error, and you get 0x19F0.
Also, consider the time zone and event log wrapping. Some third-party monitoring tools that read event logs can interfere. I've seen an old agent cause this error because it was holding the container file open with a read lock that didn't respect the sharing mode. If you have such tools, update them or contact the vendor.
The bottom line: this error is rarely about the log service itself. It's a symptom of something blocking that write. Work through these steps, and you'll find the culprit in most cases. If not, you're looking at a hardware issue or a conflict that needs vendor support.