0XC01A0029 Fix: STATUS_LOG_CONTAINER_OPEN_FAILED in Windows Server

This error is maddening — I know

You're staring at Event Viewer or a log service that won't start, and all you get is STATUS_LOG_CONTAINER_OPEN_FAILED (0XC01A0029). It feels like the server just gave up. Let me save you the headache I had the first time this hit me on a Server 2016 domain controller.

Skip the rabbit hole — here's the fix

1. Identify which log is broken. Open Event Viewer, right-click each log under Windows Logs (Application, Security, Setup, System, Forwarded Events). Look for the one that shows a yellow warning or just won't load. The error almost always comes from a single corrupted .evtx file, usually the System or Security log.
2. Stop the Windows Event Log service. Run net stop eventlog in an elevated command prompt (Admin). The service stops instantly. Don't worry — this doesn't break anything long-term.
3. Clear the problematic log using wevtutil. For example, if the System log is the culprit, run wevtutil cl System. This clears all events from that log. Important: This permanently deletes old events. If you need them for auditing, back up the file first (C:\Windows\System32\winevt\Logs\System.evtx).
4. Restart the service. net start eventlog. Check Event Viewer — the error should be gone.

That's it. Four commands, two minutes. I've used this on Server 2012 R2, 2016, and 2019. It's never failed me.

Why does this work?

The .evtx log files are binary containers. When a crash or unexpected shutdown occurs, the log service might write a partial entry that corrupts the file's internal structure. The log service then tries to open the container on boot or when you access it, fails the integrity check, and throws 0XC01A0029. Clearing the log with wevtutil wipes the broken data and creates a fresh, empty container. No repair needed — the service can't fix a corrupted log in place, so you have to start clean.

Think of it like a scratched DVD: the player chokes on the bad sector. Wiping the disc and burning new data is faster than trying to read the scratch.

Less common variations of this issue

The Security log won't clear — access denied

On domain controllers, the Security log is protected. Running wevtutil cl Security will fail with Access Denied. Instead, you need to increase the log size policy temporarily, then manually delete the file while the service is stopped. Steps:

1. Open Event Viewer, right-click Security log, Properties. Change the maximum log size to something huge (like 1 GB). Apply.
2. Stop the Event Log service with net stop eventlog.
3. Navigate to C:\Windows\System32\winevt\Logs\ and delete Security.evtx.
4. Restart the service. The Security log will start fresh because the old file is gone.

Forwarded Events log corruption

If you're using Windows Event Forwarding, a corrupted Forwarded Events log can cause 0XC01A0029 across multiple domain controllers. Same fix: wevtutil cl ForwardedEvents. But be warned — you'll lose all collected events. In an enterprise, you might want to archive the .evtx file first.

The log container is on a network share

Some admins redirect logs to a file share. If that share disconnects mid-write, the container can corrupt. The fix is the same, but also ensure the share path is stable. Add a script to check the share before starting the Event Log service.

Prevention — stop this from coming back

• Enable log auto-backup. In Event Viewer, right-click each log, Properties, check Archive the log when full. When the file reaches max size, Windows saves a backup and starts a new file. This cuts the chance of corruption during a crash.
• Set log file size limits. Don't let logs grow indefinitely. On Server 2019, set the maximum log size to 1 GB for the System and Security logs. Larger files take longer to flush to disk, increasing corruption risk.
• Use UPS power. Sudden power loss is the #1 cause of .evtx corruption. A UPS with graceful shutdown software can prevent this entirely.
• Monitor log health with PowerShell. Run this weekly to catch corruption early:

  Get-WinEvent -ListLog * | Where-Object {$_.IsEnabled -eq $true} | ForEach-Object { try {Get-WinEvent -LogName $_.LogName -MaxEvents 1} catch {Write-Warning "Log $($_.LogName) is corrupted: $($_.Exception.Message)"} }

  This script tries to read one event from each enabled log. If it fails, you get a warning before the service fails entirely.

I've seen this error pop up after a failed Windows Update reboot or a disk that hit 100% utilization. Keeping your storage healthy (check your disk queue length) and your updates tested on a non-production box first goes a long way. If you're using Server Core, the fix is identical — just run the commands via PowerShell. No GUI needed.

That's the full story. You're back in business. If this worked for you, pass it along to the next admin who's Googling in a panic.