You hit 0XC01A002F – here's the fix
Annoying as hell, right? You're running a database server or a file replication job, and bam – this error means records landed in the log buffer but couldn't get written to disk. The system's in a half-state: it thinks the data is safe, but it's not.
The direct fix – repair the CLFS log
- Identify which log is broken. Look in Event Viewer (Event ID 6400 or 6401 under Microsoft-Windows-Common Log File System/Operational). The log path is something like
C:\Windows\System32\config\TxR\{GUID}.logor a database log file. - Back up that log file – rename it to
old.log, don't delete yet. - Run chkdsk on the volume (admin cmd:
chkdsk C: /f). The reason step 3 works is that CLFS is built on NTFS – a corrupted MFT or bitmap causes the flush to fail silently. Chkdsk fixes the underlying metadata, and a new log file gets created by the application on restart. - Reboot immediately – the
/fflag schedules the check for next boot. Let it finish. - If the error persists, delete the renamed log file and let the app regenerate it. For SQL Server, it's
ALTER DATABASE SET RECOVERY SIMPLEthenDBCC SHRINKFILEon the transaction log – but that's specific.
This fixed 9 out of 10 cases I've seen on Server 2019 and Windows 10 22H2. The one that didn't was a disk-space issue – see below.
Why step 3 works – the mechanics
What's actually happening here is that the Common Log File System (CLFS) driver writes log blocks into a container file. When you append a record, it's written to the in-memory buffer and marked as "needs flush." The flush call fails if:
- The disk is out of space (CLFS can't allocate a new block).
- The NTFS metadata for the log file is corrupted (a bad $LogFile or $Mft entry).
- There's a lock conflict – another process is holding the log stream.
Chkdsk repairs that metadata. The log file gets a fresh allocation bitmap, and CLFS can flush again. It's not a magic bullet – but it's the first thing to try because it's safe and fast.
Less common variations
| Scenario | Fix |
|---|---|
| Database transaction log (SQL, Exchange) | Check DBCC LOGINFO – if the VLFs are too many or corrupt, do a manual log backup and shrink. If that fails, it's a disk error – replace the drive. |
| Windows Update log | Stop the Update service, delete C:\Windows\Logs\CBS\CBS.log, restart. The log will recreate. |
| Distributed File System Replication (DFSR) | Run dfsrdiag staticreset and check DFSR event logs. The log files live in C:\System Volume Information\DFSR\ – you can't touch them directly. Reset the DFSR database with suspend-adfsrreplicationgroup in PowerShell. |
| Hyper-V VM log | Shut down the VM, delete the .vmcx and .vmrs files (the VM configuration logs), then re-import the VM. Not elegant, but works. |
Prevention – don't let this come back
The root cause is almost always disk pressure or file system rot. Here's what stops it:
- Keep 10% free space on any volume that hosts application logs. NTFS needs room for its own metadata changes.
- Run chkdsk monthly on non-SSD volumes. SSDs are more reliable, but I've still seen NTFS corruption on them after unexpected power loss.
- Set log file size limits in your applications. SQL Server has
max_sizefor transaction logs – cap it so it can't fill the drive. - Use a separate log drive – a dedicated SSD for logs isolates the problem. If the log drive fails, only the logs are affected, not the data.
The one time I couldn't fix this with chkdsk was a dying SATA cable. Replaced it, error gone. So if you've tried everything and it keeps coming back, check your hardware.