STATUS_LOG_GROWTH_FAILED 0XC0190019: Log space creation failed

Quick answer for advanced users

Check disk free space, then run fsutil resource info C:\ (replace C: with your volume) to see log size and free space. If the log is near its maximum (typically 20 MB on NTFS) and the volume is full, free space or grow the log via fsutil resource setlog C:\ 1048576 (sets to 1 MB). If corrupt, use chkdsk /f.

What's actually happening here

Windows uses a transactional resource manager (TxF, deprecated but still active on some system files) to coordinate writes to NTFS. It maintains a dedicated log file per volume — \$Extend\$RmMetadata\$TxfLog\$TxfLog.blf and .jrs files. When an application (like SQL Server, a backup tool, or even Windows Update) starts a transaction, the resource manager writes to this log. If the log can't grow — because the disk is full, the volume's log size cap is hit, or a corrupt log block prevents expansion — you get 0XC0190019.

The real trigger? I've seen this most often on systems where a Windows Update or a large database backup kicked off simultaneously, and the transaction log hit its 20 MB ceiling on a volume with less than 100 MB free. The log can't expand because there's no contiguous space, or the quota prevents it.

Fix steps

1. Check disk space immediately. Run fsutil volume diskfree C: (adjust drive letter). If free space is under 5% of total volume size, that's your bottleneck. Free space by deleting temp files (del /q /f %TEMP%\*), clearing the Recycle Bin, or moving large files off the volume. Transactions need room for log expansion — the log can grow up to 20 MB on NTFS, but it needs contiguous free space. If you have 50 MB free but it's fragmented, the growth still fails.
2. Run CHKDSK. A corrupt log block can stall growth. Run chkdsk C: /f /r (requires reboot). This scans for bad sectors and fixes $TxfLog metadata corruption. After reboot, the log is rebuilt if needed.
3. Reduce the transaction log size via registry. If the volume always runs tight, you can shrink the default max log size. Open Regedit, go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem. Add a DWORD NtfsMaxLogSize, set it to 1048576 (1 MB, decimal). Reboot. This caps growth at 1 MB, reducing the chance of hitting disk limits. Caveat: some apps (heavy SQL workloads) may fail if they need larger transactions. Set to 4194304 (4 MB) as a middle ground.
4. Disable TxF if you don't need it. TxF is deprecated since Windows 10 v1809. If no app relies on it (check with fltmc instances — look for TxF filter), you can disable it via fsutil behavior set disabletxf 1. Reboot. This eliminates the transaction log entirely. Caution: SQL Server 2019+ doesn't use TxF, but older versions and some backup tools might. Test first.
5. Increase free space to at least 10% of volume size. This is defensive. The log grows in 64 KB chunks up to the max (20 MB). With 10% free, fragmentation is less likely to block contiguous allocation.

Alternative fixes if the main steps don't work

• Check disk quota. If the user account running the transaction has a quota on the volume, the log can't grow. Run fsutil quota query C:. If quota is enabled for that user, increase it or disable quota for that volume. See fsutil quota disable C: (requires admin).
• Repair the TxfLog files directly. As a last resort, you can delete the log files (they're recreated on next transaction). Boot from a Windows recovery drive, navigate to C:\$Extend\$RmMetadata\$TxfLog, delete $TxfLog.blf and all .jrs files. Reboot. Windows recreates them with default sizes. Risky — any in-flight transactions are lost, which could corrupt open files. Only do this if you've backed up the volume first.
• Run SFC and DISM. Corrupted system files might be causing the transaction manager to misreport space. Run sfc /scannow then dism /online /cleanup-image /restorehealth. Reboot.

How to prevent this from coming back

Keep at least 500 MB free on any volume that hosts active transactions (system drive, database drive). For SQL Server specifically, move the SQL transaction log to a separate volume — SQL uses its own log, not TxF, but the OS-level log still exists on the system drive. Monitor free space with a scheduled task that alerts below 1 GB. And on any production server running old software that depends on TxF (rare today), set NtfsMaxLogSize to 4 MB — big enough for most operations but small enough to avoid hitting disk limits on tight volumes.

The root cause is almost always disks running too full for transactional file system metadata to expand. Address that, and 0XC0190019 won't rear its head again.