Fix SQL Server Error 0XC0190012 – STATUS_TRANSACTION_SUPERIOR_EXISTS

Yeah, that error code looks intimidating, but don't panic. I've walked into this exact 0XC0190012 headache on half a dozen servers over the years — SQL Server 2016, 2019, even a 2012 legacy box. The common thread is always a transaction that thinks it's still alive but its session has gone walkabout. Here's how you kill it.

Step 1: Find the Zombie Transaction

Open SSMS and run this query straight away:

DBCC OPENTRAN;

This will spit out something like:

Transaction information for database 'YourDatabase'.
Oldest active transaction:
    SPID (server process ID): 78
    UID (user ID)           : -1
    Name                    : distributed_transaction
    LSN                     : (123:456:7)

Write down the SPID. That's your target. If DBCC OPENTRAN returns nothing, try this:

SELECT session_id, transaction_id, is_user_transaction, is_local
FROM sys.dm_tran_active_transactions
WHERE is_user_transaction = 1
AND transaction_id NOT IN (
    SELECT transaction_id FROM sys.dm_tran_session_transactions
);

That second query catches transactions with no session attached — classic superior exists behavior. The transaction is alive in the log but the session is gone.

Step 2: Kill It

Once you have the SPID from DBCC OPENTRAN or the session_id from the DMV, kill it:

KILL 78;  -- Replace 78 with your SPID

If the kill hangs or you get a message like "KILL 78 — only users with special permissions can kill this", you might need to run it as sysadmin. Do that. Then try your operation again — the error should vanish.

If KILL doesn't work, you need to find the distributed transaction GUID. Run:

SELECT dt_tran.distributed_id, dt_tran.transaction_id, dt_tran.state
FROM sys.dm_tran_active_transactions dt_tran
WHERE dt_tran.transaction_type = 2;  -- Distributed transactions

Take the distributed_id GUID, then:

KILL '<GUID>' WITH COMMIT;

That tells SQL Server to mark the transaction as committed in the log, even if the coordinator is gone. This is your nuclear option — use it during a maintenance window.

Why This Happens

Here's the short version: STATUS_TRANSACTION_SUPERIOR_EXISTS means SQL Server still has a reference to an old transaction that was started by a higher-level coordinator — usually MSDTC or a linked server. That transaction never got a proper commit or rollback. Maybe the client app crashed. Maybe the network dropped during a distributed transaction. Maybe a linked server query timed out but the transaction stayed open.

SQL Server refuses to start a new transaction in that database until the old one is resolved — because the old one is technically still in the log. The error code says "superior exists" because from SQL's perspective, there's a superior (the old coordinator) that hasn't released the lock.

Killing the SPID forces SQL to roll back that orphaned transaction. The distributed GUID kill with WITH COMMIT tells SQL to treat it as committed — but only do that if you're sure the actual work was already done. If you're not sure, roll it back with WITH ROLLBACK instead.

Less Common Variations

Sometimes the fix above doesn't work because the problem is at the MSDTC level, not SQL Server. You'll see the error but DBCC OPENTRAN returns nothing, and sys.dm_tran_active_transactions is clean. In that case:

Open Component Services (dcomcnfg).
Navigate to Component Services > Computers > My Computer > Distributed Transaction Coordinator > Local DTC.
Right-click and select Properties.
On the Tracing tab, enable Transaction Manager Tracing.
Check the logs in %SystemRoot%\system32\msdtc\Trace for GUIDs of stuck transactions.
Use msdtc -resetlog to clear MSDTC's log (needs a service restart).

Another rare case: linked server queries that use SET XACT_ABORT ON can leave orphaned distributed transactions. If you see the error right after a linked server query fails, check sys.dm_tran_locks for locks from SPID -2 (the distributed transaction coordinator ghost).

SELECT * FROM sys.dm_tran_locks WHERE request_session_id = -2;

This session -2 is the MSDTC shadow. If you see locks here, kill the corresponding distributed transaction from the previous steps.

Prevention

You can't stop apps from crashing, but you can stop the mess they leave behind.

Set a transaction timeout in your application connection string: Transaction Binding=Explicit Unbind or set Transaction Timeout to 30 seconds in the app's config. This prevents long-running distributed transactions.
Use SET DEADLOCK_PRIORITY LOW on linked server queries — it reduces the chance of a transaction surviving after a deadlock victim kill.
Monitor with an alert on the error 0XC0190012. Set up a SQL Agent job that runs DBCC OPENTRAN every 5 minutes and emails you if it finds anything older than 10 minutes.
Reboot MSDTC regularly on busy linked server hosts. A monthly net stop msdtc && net start msdtc during maintenance clears stale GUIDs.
Avoid distributed transactions if you can. Use OPENQUERY with SET REMOTE_PROC_TRANSACTIONS OFF for read-only linked server calls. Distributed transactions are the root cause 95% of the time.

That's it. Find the ghost, kill it, move on. You'll see this error again — now you know exactly what to do.