When this error hits
You'll see ERROR_LOG_APPENDED_FLUSH_FAILED (0X000019F7) when Windows or an application wrote new data to a log file — typically a Common Log File System (CLFS) log or a database transaction log — but then couldn't flush that data from memory to disk. The error text is: "Records were appended to the log or reservation changes were made, but the log could not be flushed."
This shows up in Event Viewer under System or Application logs, often while Microsoft SQL Server, Exchange, or Hyper-V replica VSS writer is running. Real-world trigger: you're about 10 minutes into a heavy batch insert on SQL Server, the disk queue spikes, and suddenly the backup fails with this code. Or your Hyper-V replication job stops mid-stream. The flush didn't complete, so it's stuck.
What's actually happening here
The Common Log File System (CLFS) driver (clfs.sys) manages transaction logs for several Windows components and applications. When an app appends records, CLFS marks the append as complete in a memory buffer. The app then calls FlushToLsn or FlushLogBuffers to tell CLFS "write this to disk now." If the underlying storage device fails to issue that write — because of a flaky disk, a full disk, a write-cache battery dying, or a SAN timeout — CLFS returns ERROR_LOG_APPENDED_FLUSH_FAILED.
The error is saying: "Hey, I accepted your data, but I can't guarantee it's on disk. It might be, it might not be." The log is now in an inconsistent state. You can't safely continue writing to it until the flush issue is resolved. This is CLFS being conservative — better to fail loudly than silently corrupt data.
The fix
Step 1 — Check disk space on the log volume
Open Explorer or run fsutil volume diskfree C: (replace C: with the drive holding the log). If the volume is at 99% or full, CLFS can't flush new records. The log needs room to write. Free up space — delete temp files, move old backups, or extend the volume. This is the most common cause for this exact error code.
Step 2 — Run a disk integrity health check
The disk might have bad sectors or an I/O controller issue. Open an admin Command Prompt and run:
chkdsk /f D:Replace D: with the log drive. /f fixes filesystem errors. If chkdsk finds corruption, schedule it for next reboot with chkdsk /f D: /scan on Server 2016+. Real-world: I've seen this error pop when a RAID controller entered recovery mode and started returning delayed writes.
Step 3 — Check write-cache policies on the disk
Open Device Manager → expand Disk drives → right-click the log drive → Properties → Policies tab. Look at "Write-cache policy." If you have Enable write caching on the device checked AND Turn off Windows write-cache buffer flushing checked, that's a problem. The battery on the RAID controller or the SSD's capacitor may be dead. Uncheck "Turn off Windows write-cache buffer flushing" if you don't have a UPS or battery-backed cache. On a SAN volume, also check the SAN management interface — sometimes the LUN's write-back cache gets disabled during a failover, and this error follows.
Step 4 — Verify the log file itself isn't corrupt
If the log is from a SQL Server database, run DBCC CHECKDB on that database. For CLFS logs (like those used by Hyper-V or Windows backup), you can use clfswb.exe from the Windows SDK to dump and verify the log. But the simplest route: if the application that owns the log can rebuild it (e.g., SQL Server log file recreation via backup/restore), do that. Don't manually delete .blf or .log* files — you'll break things.
Step 5 — Look for antivirus interference
Some antivirus products (I'm looking at you, McAfee and Symantec Endpoint Protection) lock log files during real-time scanning and cause flush failures. Add the entire log folder as an exclusion in your AV software. Then reboot the server. I've fixed this error twice by just killing the AV scan process on the log directory.
If it still fails
If the error persists after all that, the storage subsystem is the root cause. Check the disk's S.M.A.R.T. data with wmic diskdrive get status — if it says "Bad", replace the drive. On a SAN, contact the storage admin and ask them to check the controller logs for I/O timeouts or bus resets. Also check the Windows System event log for any Event ID 129 (reset to device) or Event ID 153 (IO operation terminated) warnings — those are direct evidence of a failing disk path.
One last thing: don't ignore this error. If you clear it and keep running, the log might have silent corruption that shows up hours later as a failed database recovery or a corrupt VSS backup. Fix the flush path first, then clean up the log.