Fix XACT_S_SOMENORETAIN 0x0004D003 SQL Error

This SQL Server error means a transaction was aborted but resources aren't retained. Usually caused by connection drops or timeout during distributed transactions.

Quick answer: Restart the MSDTC service, check network connectivity between servers, and increase the transaction timeout via Registry if it keeps happening.

What's going on here?

Error 0x0004D003 shows up when SQL Server kills a transaction but doesn't keep any locks or resources around. That's what "SomeNoRetain" means — no retained resources. It's almost always a distributed transaction (DTC) that failed mid-way. The transaction aborted cleanly, but your app didn't handle the abort gracefully, so you see this error in the logs or in a catch block.

I see this most often with linked server queries across SQL Server instances, or when using BEGIN DISTRIBUTED TRANSACTION with an Oracle or Sybase linked server. Network blips, MSDTC service crashes, or firewall drops are the usual triggers. One specific scenario: a nightly ETL job that copies data from ServerA to ServerB via a linked server — the connection drops for two seconds, MSDTC aborts the transaction, and you get this error.

Fix steps

Check MSDTC is running. Open Services.msc, find "Distributed Transaction Coordinator". If it's not Running, start it. Set startup to Automatic if it's not already.
Verify network connectivity. From the SQL Server machine, run telnet [remote_server_ip] 135 (RPC endpoint mapper). Also test port 445 for SMB and the dynamic RPC port range (default 49152-65535 on modern Windows). If telnet fails, firewall rules are blocking DTC traffic.
Increase transaction timeout. MSDTC default timeout is 60 seconds. For long-running distributed queries, bump it up. Open Component Services (dcomcnfg.exe), go to Component Services > Computers > My Computer > Distributed Transaction Coordinator > Local DTC. Right-click, Properties, then the Transactions tab. Set the timeout higher — 120 or 300 seconds — depending on your query duration.
Adjust registry timeout (if the UI doesn't stick). Sometimes the Component Services change reverts on reboot. For a permanent fix, set this registry value:
```
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTC]
"TransactionTimeout"=dword:0000012c
```
That's 300 seconds (0x12c). Reboot the server or restart MSDTC after changing it.
Enable network DTC access. In the same Local DTC Properties window, on the Security tab, check Network DTC Access, Allow Inbound, Allow Outbound, and No Authentication Required (if both servers are in the same domain, use "Mutual Authentication Required" instead). Apply and restart MSDTC.

Check SQL Server linked server configuration. Run this query to see if the linked server is set up for RPC out:

SELECT * FROM sys.servers WHERE is_linked = 1;

Update the linked server to enable RPC:

EXEC sp_serveroption 'YourLinkedServer', 'rpc', 'true';
EXEC sp_serveroption 'YourLinkedServer', 'rpc out', 'true';

If the main steps don't work

Reboot both servers

Yeah, it's the sysadmin cliché, but with MSDTC, reboot often clears stuck transaction states. If the DTC log is corrupted, a reboot won't fix it — you'll need to stop MSDTC, delete the log file (usually in %SystemRoot%\System32\MSDTC), and restart the service. That should rebuild the log clean. Only do this if you're sure no other distributed transactions are active.

Switch to a single-server solution

If you keep hitting this, consider avoiding distributed transactions altogether. Use Service Broker for asynchronous messaging between SQL instances, or bulk-copy data instead of using linked server queries. Distributed transactions are brittle — they fail in ways normal transactions don't.

Update SQL Server and Windows

Old builds of SQL Server 2012 and 2014 had known MSDTC bugs. Install the latest cumulative update for your SQL version. Same for Windows — apply all critical patches, especially KB articles related to MSDTC.

Prevention tips

Set transaction timeouts high enough. Your ETL or migration queries will vary — profile them first, then set the timeout to 2x the slowest run.
Monitor network stability. Use something like PRTG or SolarWinds to ping both servers every minute. If packet loss exceeds 0.5%, you'll see this error regularly.
Avoid linked server queries that span multiple databases. If you must, wrap them in SET XACT_ABORT ON — it helps SQL Server clean up faster, but doesn't prevent the error itself.
Use explicit error handling in your app code. Catch XACT_STATE() = -1 after a transaction fails, and retry the whole operation. Don't try to reuse the same connection — open a new one.

The real fix is usually the MSDTC timeout registry key or enabling network DTC access. Start there, and you'll knock out 80% of these errors on the first try.