XACT_E_TRANSACTIONCLOSED (0x8004D083) Fix: Log Discarded Error

You're stuck on this error, and I get it — it's maddening.

The transaction you were in the middle of just evaporated. The logs are gone, and you're staring at 0x8004D083 with no clue why. Let's cut to the chase.

The Direct Fix

Two things cause this: either your transaction timed out or something explicitly rolled it back. Here's what to do right now:

1. Check your transaction timeout. In MSDTC (Microsoft Distributed Transaction Coordinator), the default timeout is 60 seconds. If your operation takes longer — say, a batch insert on SQL Server 2019 with 50,000 rows — it kills the transaction and dumps the log. Open Component Services, go to Component Services > Computers > My Computer > Distributed Transaction Coordinator > Local DTC, right-click Properties, and under the Security tab, uncheck "Enable XA Transactions" if you don't need them, then under the Transaction Manager tab, set the timeout to 0 (unlimited) or a higher value like 300 seconds.
2. Audit your code for explicit rollbacks. I've seen this happen when a try-catch block catches an exception but doesn't handle the transaction properly. In C# with System.Transactions, if you call Transaction.Current.Rollback() or let using block exit without committing, you'll get this exact error on the next attempt to use that transaction scope. Wrap your transaction in a using block and make sure Complete() is called before it disposes.

Why This Works

The error code 0x8004D083 translates to "The transaction has completed, and the log records have been discarded from the log file." Once a transaction commits or rolls back, MSDTC flushes its log buffers. Any subsequent call to that transaction object is dead — the log data is physically gone from the file. By extending the timeout, you prevent premature termination. By fixing your code, you stop accidental rollbacks. Simple as that.

// Example: C# code that triggers this error
try
{
    using (var scope = new TransactionScope())
    {
        // Do work
        // If an exception happens before scope.Complete(),
        // the transaction rolls back and logs are discarded.
        // Next call to Transaction.Current will fail.
    }
}
catch (Exception ex)
{
    // The transaction is already dead here
    // Don't try to access it again
}

Less Common Variations

This error pops up in a few other scenarios:

• COM+ with pooling enabled. If you're using COM+ components with object pooling, a transaction that's completed might be reused but the log is gone. Solution: disable pooling for that component in Component Services, or re-enlist the transaction correctly.
• Cross-machine DTC. When a transaction spans two SQL Server instances on different machines, network latency can cause the transaction to timeout on one side while the other still holds it. Check your firewall rules — port 135 (RPC Endpoint Mapper) and the dynamic port range (default 49152-65535, but configurable) must be open for MSDTC. On Windows Server 2019, run netsh advfirewall firewall add rule dir=in name="MSDTC" program=%SystemRoot%\system32\msdtc.exe action=allow for each node.
• Log file corruption. Rare, but if the MSDTC log file itself is corrupted (usually after a crash), you'll see this. In that case, stop the MSDTC service, delete the log file at C:\Windows\System32\MSDTC\MSDTC.LOG, and restart the service. It creates a fresh one. Only do this if you're certain no pending transactions matter, because you'll lose them all.

Prevention

Here's how to keep this from coming back:

• Set realistic timeouts. For long-running batch jobs in SQL Server 2022, bump the DTC timeout to 10 minutes or more via registry: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTC\Timeout — set it to 600 (seconds) or higher.
• Use compensating transactions. Instead of wrapping everything in a single distributed transaction, design your system to handle partial failures. For example, use the Saga pattern with saga orchestrators or a database like SQL Server's built-in retry logic.
• Monitor MSDTC logs. Run dxdiag and check the MSDTC log disk usage. If it's near capacity (default max is 4 MB for log files, but can be increased), increase it via registry: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTC\MaxLogSize — set to 65536 for 64 MB.
• Test your exception handling. I always add a finally block that checks if the transaction is still active (via Transaction.Current.TransactionInformation.Status) before doing anything else. Don't assume it's alive.

That should get you past this. Fix the timeout, fix the code, and you won't see 0x8004D083 again. If you do, check the network or the log file — those are the outliers.