STATUS_TRANSACTIONS_NOT_FROZEN (0XC0190045) fix for VSS backups

What's going on with 0XC0190045?

You're trying to thaw frozen transactions in SQL Server, but nothing was frozen in the first place. This error code STATUS_TRANSACTIONS_NOT_FROZEN (0XC0190045) usually shows up in Windows Application event logs during VSS backups. I've seen it on SQL Server 2016, 2017, and 2019, mostly when third-party backup tools (like Veeam, Backup Exec, or even Windows Server Backup) kick off a volume snapshot.

The short story: SQL Server's VSS writer gets confused. It thinks the backup tool sent a "freeze" command wrong, or the freeze never happened. The backup job then tries to thaw—and fails with this exact code.

30-second fix: Check if the backup tool is stuck

Before anything else, restart the Volume Shadow Copy service. This clears out stuck VSS writers and often fixes the problem in seconds. I've had a client whose nightly backup failed for a week because of a hung writer. One restart fixed it.

1. Open Command Prompt as Administrator.
2. Run net stop vss then net start vss.
3. Or just reboot the server if you're short on time.

After restarting, check if the error repeats. If it does, move on.

5-minute fix: Re-register SQL Server VSS writer

If the quick restart didn't help, the VSS writer for SQL Server might be corrupted or misregistered. This is common after SQL Server patches or cumulative updates. Here's how to fix it:

1. Open an elevated Command Prompt.
2. Run cd \Program Files\Microsoft SQL Server\[instance number]\Tools\Binn\. Replace [instance number] with your SQL instance ID (like MSSQL13.MSSQLSERVER for SQL 2016 default instance).
3. Run sqlwriter.exe -unregister then sqlwriter.exe -register.
4. Restart the Volume Shadow Copy service again: net stop vss && net start vss.
5. Test your backup.

This re-registers the SQL VSS writer without reinstalling anything. I've used this on at least 5 servers where the error popped up after a Windows Update.

15+ minute fix: Manual transaction freeze and thaw

If the error keeps happening, the VSS backup tool isn't sending the proper freeze commands. You can manually freeze and thaw the SQL Server transactions using the T-SQL commands below. This bypasses the VSS writer entirely for that backup session.

Warning: Only do this during a maintenance window. Freezing transactions stops all writes to the database. If you freeze and don't thaw, you'll lock up the server.

-- Freeze transactions
ALTER DATABASE YourDatabaseName SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
CHECKPOINT;
-- Now run your VSS backup manually
-- After backup completes, thaw:
ALTER DATABASE YourDatabaseName SET MULTI_USER;

This forces the database into single-user mode, freezes it, then lets you thaw by setting it back to multi-user. Works like a charm when the VSS writer is completely hosed. But it's a manual step—don't put this in a script without careful testing.

When to call in the big guns

If none of that works, check the SQL Server error log and Windows Application log for additional VSS writer errors. Look for event ID 8193 from source MSSQL$INSTANCENAME. That'll tell you if the writer is failing due to permissions or a corrupted database.

Also make sure the SQL Server VSS Writer service is running. It's usually disabled by default on newer SQL Server versions. Set it to Automatic and start it.

Had a client last month whose entire backup chain broke because the VSS writer service was set to Manual. Changed it to Automatic, rebooted, and backups started working again. Drove them crazy for three weeks.

The real takeaway

This error is almost always a VSS writer miscommunication. The 30-second restart fixes most cases. The re-register fix handles the rest. The manual freeze is your last resort. Don't overthink it—start simple, escalate as needed.

And if you're using a third-party backup tool, check with their support too. Some tools have known issues with SQL Server VSS writers on certain builds. But that's a story for another day.