Fix XACT_S_LASTRESOURCEMANAGER (0x0004D010) Fast

What triggers this error

You're running a distributed transaction across two SQL Server instances (or SQL and another resource manager like MSMQ). The transaction starts fine, but when it tries to commit, you get 0x0004D010 XACT_S_LASTRESOURCEMANAGER. This means the transaction coordinator can't talk to the last resource manager in the chain. I've seen it most often when someone moves a database to a new server and forgets to configure MSDTC. Also happens after a Windows update resets DTC security.

Fix 1: The 30-second check — verify network name resolution

1. Open Command Prompt as Administrator on the server where the error occurs.
2. Type ping and hit Enter. Replace with the name of the remote server involved in the transaction.
3. Look at the response. You should see Reply from . If you get Ping request could not find host, that's your problem.
4. If ping fails, open C:\Windows\System32\drivers\etc\hosts in Notepad as Administrator.
5. Add a line like this at the bottom: 192.168.1.100 SQLSRV2 (replace IP and name with your remote server's details).
6. Save the file, close Notepad, and run the transaction again.

After saving, the ping should work. If the error goes away, you're done. If not, move to the next fix.

Fix 2: 5-minute fix — check MSDTC configuration and firewall

This is the real fix for most people. The Distributed Transaction Coordinator (MSDTC) needs specific settings.

Step 1: Enable network DTC access

1. Press Win+R, type dcomcnfg, hit Enter.
2. In Component Services, expand Component Services > Computers > My Computer > Distributed Transaction Coordinator.
3. Right-click Local DTC, choose Properties.
4. Go to the Security tab.
5. Check these boxes: Network DTC Access, Allow Inbound, Allow Outbound, No Authentication Required.
6. Also check Enable XA Transactions if you're using Oracle or other XA-compliant resources.
7. Click Apply. A message says MSDTC will be restarted. Click Yes.

After restarting, you should see Local DTC status shows Started. If it doesn't start, check the Windows Event Viewer under Applications and Services Logs > Microsoft > Windows > MSDTC for errors.

Step 2: Open firewall ports for DTC

1. Open Windows Defender Firewall with Advanced Security.
2. Click Inbound Rules, then New Rule.
3. Choose Port, then TCP. Enter 135 in the port box.
4. Allow the connection, apply to Domain and Private profiles.
5. Name it DTC RPC Endpoint Mapper.
6. Repeat steps 2-5, but this time enter 5000-5100 as the port range. Name it DTC Communication Ports.
7. Also create an outbound rule with the same port settings.

These ports are what MSDTC uses for communication. Without them, the transaction coordinator can't reach the remote resource manager.

Fix 3: 15-minute fix — registry and transaction timeout tuning

If the first two fixes didn't work, something deeper is wrong. I've seen cases where the transaction coordinator times out before the resource manager responds. Also, sometimes the system waits too long for a dead resource.

Step 1: Increase transaction timeout in SQL Server

1. Open SQL Server Management Studio (SSMS).
2. Connect to the server where the transaction originates.
3. In Object Explorer, right-click the server, choose Properties.
4. Go to Advanced page.
5. Under Miscellaneous, set Remote transaction timeout (seconds) to 300 (5 minutes). Default is 10 seconds — that's way too short for distributed transactions.
6. Click OK.

Step 2: Force MSDTC to use specific ports (if you have strict firewall rules)

1. Open Registry Editor as Administrator.
2. Go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTC.
3. Right-click in the right pane, choose New > DWORD (32-bit) Value. Name it ServerTcpPort.
4. Double-click it, set the value to 5000 (or any port in your allowed range).
5. Now go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\Internet. If the Internet key doesn't exist, create it. Inside, create two DWORDs: Ports (value 5000-5100) and PortsInternetAvailable (value Y).
6. Restart the MSDTC service: open Command Prompt as Admin, type net stop msdtc && net start msdtc.

After restarting, check if the service started by running sc query msdtc. You should see STATE: 4 RUNNING.

Step 3: Verify the transaction coordinator is reachable

1. On the remote server, open Component Services and check Local DTC is started.
2. From the originating server, test the connection using PowerShell: Test-NetConnection -ComputerName -Port 135. It should return TcpTestSucceeded : True.
3. Then test your specific DTC port: Test-NetConnection -ComputerName -Port 5000. Same result expected.

If any of these tests fail, go back to your firewall rules and double-check them. Also make sure the remote server's MSDTC is configured the same way as in Fix 2.

When all else fails

Sometimes the error is caused by a damaged MSDTC database. Run this as Admin from Command Prompt to reset it:

msdtc -uninstall
msdtc -install
net start msdtc

This removes and reinstalls the transaction coordinator. It will lose any in-flight transactions, so only do this during a maintenance window. After reinstall, reconfigure MSDTC from Fix 2 again.

One last thing: check your application logs for any MSDTC Connection Manager warnings. If you see them, the remote server might have a different version of MSDTC (like an old Windows Server 2008 talking to 2019). In that case, you may need to enable Allow Remote Administration in the DTC properties under the Security tab — but that's a security risk, so weigh that carefully.