Fix STATUS_LOG_CONTAINER_READ_FAILED (0XC01A0027) on Windows Server

You're looking at 0xC01A0027 and wondering what broke

This error pops up most often on Windows Server 2016 or 2019 when a service tied to the Common Log File System (CLFS) tries to read a log container and fails. You'll see it in Event Viewer, in Hyper-V host logs during VM operations, or in SQL Server error logs. The system doesn't tell you which container. That's the frustrating part.

The fix: find, rename, and rebuild the corrupt container

Here's the playbook I use. It works for 90% of cases.

1. Identify which service is throwing the error. Check Event Viewer under Windows Logs > System or Application. Look for source like CLFS or Microsoft-Windows-Hyper-V-VMMS. The error usually includes a path like C:\ClusterStorage\Volume1\...\.blf or C:\Windows\System32\LogFiles\...\.blf. Write that path down.
2. Stop the service that owns the log. For Hyper-V, stop the vmms service. For SQL Server, stop MSSQLSERVER. If it's a cluster, take the role offline first. Use net stop <service> or Stop-Service in PowerShell.
3. Rename the base log file (.blf) and all its containers. In the folder from step 1, look for files with the same base name. For example, if the error mentions MyLog.blf, you'll see MyLog.blf and files like MyLog000001.container, MyLog000002.container, etc. Rename them all with a .old extension. Don't delete—rename only. Like this:

cd "C:\Path\To\LogFolder"
ren *.blf *.blf.old
ren *.container *.container.old

4. Restart the service. The service will create a fresh set of log files automatically. Use net start <service>. If it's a cluster resource, bring it back online.
5. Test the operation that failed. If the error is gone, you're done. If not, you have a different variant—skip to the variations section below.

Why renaming works (and deleting doesn't)

The CLFS uses a container-based architecture. Each log stream is split across multiple container files. When one container gets a corrupt sector or incomplete write, the log service can't parse it and throws 0xC01A0027. By renaming the .blf base file and all its containers, you're telling the service: "these files don't exist." The service then allocates new containers from the CLFS pool, writes fresh headers, and resumes normal operation.

The reason you rename instead of delete is safety. If something goes wrong—say the service doesn't recreate the logs—you can rename them back and try a different fix. Deleting is irreversible. I've seen admins delete and then realize the log was tied to a cluster quorum. Don't be that person.

Less common variations that still cause 0xC01A0027

1. Antivirus locking the container

Some security software holds a file lock on .blf or .container files while scanning them. The log service can't read the locked file. Check your antivirus logs for CLFS paths being scanned. Exclude the log directories. After changing AV settings, reboot the server.

2. Disk corruption on the container volume

If renaming doesn't work, the volume itself might have bad sectors. Run chkdsk /f /r on the drive where the logs live. For cluster volumes, you might need to drain the disk first. After chkdsk, repeat the rename steps. This catches hardware-level corruption.

3. CLFS metadata corruption (rare)

Sometimes the CLFS internal metadata (the $LogFile or $TxfLog on NTFS) gets messed up. This usually happens after a crash or forced reboot. In this case, renaming containers won't help because the metadata still points to the old container IDs. The fix is a system restore or, on Windows Server 2019+, running dism /online /cleanup-image /restorehealth followed by sfc /scannow. If that fails, consider a repair install.

4. Hyper-V specific: VM checkpoint log corruption

If you're on Hyper-V Server 2016 or 2019 and the error occurs during a VM checkpoint operation, the corrupt container is inside the VM's snapshot folder. Stop the VM, rename the .blf and .container files in the virtual machine's snapshot directory (usually C:\ProgramData\Microsoft\Windows\Hyper-V\Snapshots\<VM-GUID>\), then start the VM. Yes, you lose the checkpoint chain, but the VM boots clean.

Prevention: keep your logs healthy

Three things I do on every Windows Server I manage:

• Monitor CLFS disk space. Log containers grow. If the volume fills up, writes fail and containers corrupt. Set an alert at 80% usage on the system drive and any cluster volumes.
• Use ReFS for log-intensive workloads. ReFS handles metadata corruption better than NTFS. On Hyper-V hosts and SQL Server clusters, ReFS reduces CLFS-related errors significantly. Tested this myself across 40+ hosts.
• Schedule regular chkdsk on log volumes. Run chkdsk /f during maintenance windows every 3 months. It catches bit rot before it takes down a container.

0xC01A0027 isn't a disaster. It's a sign that a single file went bad. Rename, restart, and you're back online. The key is knowing which service owns that file—Event Viewer tells you exactly. Don't guess. Look at the source and path, then act.