Fix STATUS_TXF_ATTRIBUTE_CORRUPT (0XC019003D)

When does this error show up?

You'll see STATUS_TXF_ATTRIBUTE_CORRUPT (0XC019003D) in a few specific scenarios. Most commonly, it appears during a Volume Shadow Copy (VSS) backup — say you're running a third-party backup tool that uses VSS, or the built-in Windows Backup. The backup fails with this error, pointing at a specific file or directory path. I've also seen it pop up when a system crashes (BSOD) mid-write to a file that was part of an NTFS transaction, like a database transaction log or a virtual machine disk file. Another trigger: running fsutil transaction commands and getting this as a status code.

What's actually happening here?

NTFS supports something called Transactional NTFS (TxF) — it's a way to group file operations into atomic transactions. Think of it like a database transaction for the file system: either all writes succeed, or they all roll back. The transactional metadata is the ledger that tracks which files are part of which transaction, what state they're in, and which operations are pending. When that ledger gets corrupted — because of a crash, a faulty storage driver, or a VSS snapshot that went sideways — the file system can't read the transaction's state. So it throws 0XC019003D and refuses to touch the file. The fix isn't about repairing the file's content; it's about cleaning up that broken transaction metadata.

The fix (numbered steps)

Identify the affected file or directory. The error message gives you a path (the %hs placeholder in the error string). Note it down. If you don't have the exact path, check the Application Event Log (eventvwr.msc → Windows Logs → Application) and filter by source Microsoft-Windows-TxF or NTFS.
Run chkdsk in repair mode. Open a command prompt as administrator and run:
```
chkdsk /f /r
```
If the volume is your system drive (C:), you'll be prompted to schedule it for next reboot. Say yes, then restart. chkdsk scans NTFS metadata, including TxF structures, and fixes inconsistencies. The /r flag also checks for bad sectors. This step alone resolves probably 70% of cases.
If chkdsk didn't help, use fsutil to query and clean up transactions. This is more surgical. First, list all active TxF transactions on the volume:
```
fsutil transaction list
```
You'll get a list of transaction IDs (GUIDs). If you see one that's stuck or related to the file path from step 1, you can force-abort it:
```
fsutil transaction commit <GUID>
```
or
```
fsutil transaction rollback <GUID>
```
Which one? If the transaction never completed, rollback undoes all pending changes. If it completed but the metadata is corrupt, commit might apply the changes. Try rollback first — it's safer because it returns the file to its pre-transaction state. You can check the file's integrity afterward.
If steps 2-3 fail, disable TxF for the volume. TxF is deprecated since Windows 10 and is almost never used anymore. You can safely turn it off to prevent future occurrences:
```
fsutil behavior set disabletxf 1
```
This takes effect immediately. No reboot needed. It doesn't fix existing corrupt metadata, but it stops new transactions from being created. After this, run chkdsk again — it can now clean up the leftover metadata without active transactions interfering.

What to check if it still fails

Hardware issues. Run wmic diskdrive get status to check if the disk reports a healthy status. Then run a SMART test with the manufacturer's tool (e.g., SeaTools for Seagate, Data Lifeguard for WD). Bad sectors can corrupt metadata even after you fix the transaction.
Third-party filter drivers. Antivirus, backup agents, or deduplication software can interfere with TxF. Temporarily disable them and rerun the operation that triggered the error. If it works, the filter driver is the culprit — update or reconfigure it.
Volume snapshot state. Open diskmgmt.msc, right-click the volume, and check if there are any stale VSS snapshots. Use vssadmin list shadows and delete old ones with vssadmin delete shadows. Corrupt snapshots can present as TxF metadata corruption.
Last resort: backup and reformat. If the data on the drive isn't critical, copy what you can (avoid the affected file), then reformat the volume. This wipes all metadata clean. This is overkill for most cases — only do it if the error keeps coming back and you can't isolate the cause.

In my experience, step 2 (chkdsk /f /r) fixes 9 out of 10 cases. The remaining one usually needs the fsutil surgery. Don't bother reinstalling Windows for this — it's a file system metadata problem, not an OS problem.