XACT_E_XA_TX_DISABLED (0X8004D026) — XA Transactions Disabled

When does this happen?

You're running a distributed transaction through a linked server — maybe from SQL Server to Oracle, or SQL Server to DB2. The query hits a two-phase commit, and instead of completing, it throws XACT_E_XA_TX_DISABLED (0X8004D026). You might also see this in an application using the System.Transactions namespace with an XA-compliant resource manager like the Oracle .NET provider.

I've seen it most often on Windows Server 2016 and 2019 boxes where the DTC (Distributed Transaction Coordinator) defaults to a locked-down config. Another common trigger: someone disabled XA transactions intentionally for security, then a new app needed them.

What's actually happening here?

The error code 0X8004D026 lives in the MSDTC subsystem. Windows DTC has two separate knobs for transaction types: one for network transactions (the typical XACT_E_NETWORK_TX_DISABLED), and one specifically for XA transactions. XA is the X/Open standard for distributed transaction coordination — it's older than COM+ and uses a different protocol than the default DTC protocol.

When DTC receives an XA request (like the xa_open call), it checks a registry value under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTC\XADLL. If that path has no value, or the XADLL key doesn't exist, DTC refuses the request with this exact error. Microsoft stripped the default XA DLL in some Windows versions starting with Server 2012R2, citing security concerns. The fix is restoring that DLL registration and toggling the config.

The reason step 3 works is that the registry key tells DTC which DLL to load for XA support. Without it, DTC can't service the request — it's not that XA is broken, it's that the DLL isn't mapped.

The fix: enable XA transactions in MSDTC

You need admin rights on the machine. Do these steps in order — skipping the registry check is the most common mistake.

1. Open Component Services — run dcomcnfg from an admin command prompt. Expand Component Services > Computers > My Computer > Distributed Transaction Coordinator > Local DTC. Right-click Local DTC and choose Properties.
2. Enable XA transactions in the UI — go to the Security tab. Under Transaction Manager Communication, check Allow Inbound and Allow Outbound. Then in the bottom section, check Enable XA Transactions. Click OK. A dialog will ask about stopping and restarting the DTC service — say Yes.
3. Verify the registry key exists — open regedit and navigate to:

   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTC\XADLL

   If the key doesn't exist, create it (String Value, no data needed — the name alone tells DTC to load the default library). If it exists and has a value, it should point to msdtcprx.dll (the default DTC proxy). Don't change it unless you know what you're doing — third-party XA providers like Oracle's xaoradb.dll sometimes set this. In that case, leave the vendor's value.
4. Restart the DTC service — run as admin:

   net stop msdtc && net start msdtc

   Then verify it's running with sc query msdtc.
5. Test your distributed transaction — retry the linked server query or the app call that threw the error.

If it still fails

A few things to check when the error persists after the above:

• Windows Firewall — DTC needs port 135 (RPC Endpoint Mapper) and dynamic port range 49152-65535 open between both machines. On older Windows versions, the range was 1024-65535. Use netsh advfirewall firewall show rule name="Distributed Transaction Coordinator" to see your rules.
• Network DTC access — open Local DTC Properties > Security tab again. Under Transaction Manager Communication, make sure Allow Remote Clients is checked if you're hitting a remote machine.
• Authentication mismatch — if both machines are not in the same domain, you might need to check No Authentication Required in the DTC security settings. That's a security downgrade, so do it only in controlled environments.
• Third-party XA DLL registration — if you're using Oracle's XA library or another vendor's, they often require you to run a setup utility (like Oracle's oraxa or msdtcsetup) that registers a specific DLL path into HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTC\XADLL. Check the vendor docs for that step.
• Event log clues — check Event Viewer > Applications and Services Logs > Microsoft > Windows > MSDTC for error details. If you see MSDTC encountered an error (HR=0x8004d026), it confirms the same root cause but might give a more precise sub-system hint.

One last thing: if you're on a container or a nano server, MSDTC and XA support might not even be installed. You'd need to add the MSDTC Windows feature, and even then, XA is an optional component inside it. Stick to full Windows Server for reliable distributed transactions.