Fix STATUS_NO_TXF_METADATA (0X80190029) on SQL Server

What Actually Triggers This Error

You're looking at a database file that SQL Server can't open because the transaction metadata—the info that tells SQL Server where the file's transactions left off—is missing. I've seen this most often after a VSS (Volume Shadow Copy) backup that crashed mid-stream. Last month a client in a legal office had this across 12 databases after their backup software hung during a snapshot. The other common culprit: a corrupted NTFS transaction log on the file system itself. Happens when a server crashes during a file copy or a dedup job goes sideways.

Cause 1: Corrupted or Interrupted VSS Backup

This is the top reason. VSS takes a snapshot of your SQL Server data files to back them up. If that snapshot fails—say the backup software times out or the server loses power—the transaction metadata (stored in the file's alternate data stream or a separate tracking structure) gets left in an inconsistent state. Next time SQL Server tries to read that file, it hits 0X80190029.

The Fix

Skip the VSS recovery tools—they rarely work here. Instead, restore from a known good backup. Not your last VSS snapshot; that's what broke it. I mean a full database backup from before the error appeared.

1. Check your backup history in SQL Server Management Studio (SSMS) or via msdb.dbo.backupset to find a clean backup.
2. Restore using RESTORE DATABASE [YourDB] FROM DISK = 'path' WITH REPLACE, RECOVERY.
3. If you don't have a backup, try running DBCC CHECKDB ('YourDB', REPAIR_ALLOW_DATA_LOSS)—but know this can delete data. I've had to use it twice, and it worked once.

After restoring, check your backup software's VSS writer. If it's not registering correctly (use vssadmin list writers in an admin command prompt), update or patch the backup tool. Had a client using an old version of Veeam that caused this every week until they updated.

Cause 2: NTFS Transaction Corruption

SQL Server uses NTFS transactions to ensure atomic writes to data files. If the NTFS transaction log (stored in $LogFile on the volume) gets corrupted—power loss during a write, disk driver bug, or a dedup operation that went haywire—SQL Server can't find the metadata it expects.

The Fix

First, confirm the issue is NTFS-level. Check the System event log for Event ID 55 or 51 from the disk driver. Also look for NTFS errors in chkdsk output.

1. Run chkdsk /f on the volume containing the database files. This repairs the NTFS transaction log. You may need to schedule it at the next reboot—use chkdsk /f C: (replace C: with your drive letter).
2. After the chkdsk completes and the system reboots, try to attach or bring the database online again. If it still fails, the file metadata is likely beyond repair.
3. In that case, restore from a backup as in Cause 1. No backup? Try DBCC CHECKDB with REPAIR_ALLOW_DATA_LOSS, but expect row loss.

One trick I've used: copy the database file to another NTFS volume, then attach it. Sometimes that forces SQL Server to reinitialize its transaction metadata. Works maybe 30% of the time, but it's worth a shot if you're desperate.

Cause 3: File System-Level Corruption from Disk or Deduplication

Less common, but when it hits, it's ugly. A bad disk sector or a deduplication job (like Windows Server Data Deduplication) can damage the file's metadata streams. I saw this on a dedup-enabled volume storing database backups—the dedup engine corrupted the MFT entry for the database file.

The Fix

1. Run chkdsk /r on the volume to scan for bad sectors and recover readable data. This takes hours for large drives.
2. If dedup is involved, disable it on the volume: Disable-DedupVolume -Volume D: (PowerShell). Then try a file-level copy using robocopy D:\Source E:\Backup /B /R:3 /W:10 to copy with backup semantics, which may skip corrupted sectors.
3. If the file is still bad, again, backup restore is your friend.

Had a client who ran dedup on their SQL data volume—bad idea. After I turned it off and restored from backup, we never saw 0X80190029 again.

Quick-Reference Summary

Look, the real fix is almost always a clean backup. If you don't have one, you're in for a rough day. I keep a spare drive with full backups for exactly this reason. Get that sorted first, then worry about the cause.