Fix XACT_E_REPLAYREQUEST (0X8004D085) COM+ CRM Error

I know how annoying this one is. Your COM+ app just sits there, logs filling up with XACT_E_REPLAYREQUEST, and the event viewer won't shut up about it. The good news? The fix is straightforward — no deep surgery needed.

Immediate Fix: Clear the CRM Logs

The culprit here is almost always leftover CRM log files from a crashed or improperly shut down transaction. The CRM (Compensating Resource Manager) holds onto these records until they're replayed, but sometimes they get stuck in a loop.

Here's what you do:

1. Open Component Services. Run dcomcnfg from the Run dialog or Command Prompt.
2. Expand Component Services > Computers > My Computer > COM+ Applications.
3. Find the application that's throwing the error. If you're not sure which one, look at the Event Viewer logs under Applications and Services Logs > Microsoft > Windows > COM+. The error should name the app.
4. Right-click the application and select Shut Down. This stops it cleanly.
5. Now navigate to C:\Windows\Registration\. Look for files with a .crmlog or .crmsql extension — they're usually named like CRM_<GUID>.log. Delete those files. Yes, delete them. The CRM will recreate them when needed.
6. Restart the COM+ System Application service. Open services.msc, find it, right-click and Restart. Wait 10 seconds.
7. Restart your COM+ application from Component Services (right-click > Start).

That's it. 90% of the time this clears the replay request. The CRM now has a clean slate and won't try to replay old, dead transactions.

Why This Works

COM+ CRM uses those log files as a checkpoint. When a transaction starts, the CRM writes a record to disk. If the system crashes mid-transaction, the CRM picks up those records on restart and replays them to finish or roll back. But if the records are corrupt or the transaction is orphaned (no parent process to complete it), the CRM keeps retrying forever. Deleting the files tells the CRM to forget about those transactions. Yes, you lose the ability to complete them, but if they've been stuck for hours, they're never going to finish anyway. The CRM just needs a clean log directory to work properly.

Less Common Variations

Error Persists After Deleting Logs

If the error comes back right away, you might have a corrupt COM+ catalog. Run this command as Administrator:

regsvr32 /u comsvcs.dll
regsvr32 comsvcs.dll
net stop COMSysApp
net start COMSysApp

This re-registers the COM+ core DLL. Wait 15 seconds between each command. If you still get errors, move to the next fix.

Multiple COM+ Applications Affected

Sometimes the CRM service itself is hosed. In that case, reset the entire COM+ catalog:

1. Open Component Services.
2. Right-click My Computer and select Properties.
3. Go to the Options tab and click Reset Defaults. This wipes all custom COM+ application settings, so back them up first (export each app to a .msi file).
4. Confirm the prompt and restart the computer.

Third-Party CRM Components

Some apps (like older versions of Microsoft SQL Server's COM+ integration or IBM MQ Series) install their own CRM workers. If the log files don't show up in C:\Windows\Registration, check the app's own directory. For SQL Server, look in C:\Program Files\Microsoft SQL Server\MSSQLXX.MSSQLSERVER\COM\. Delete any *.crm files there after shutting down the app.

Prevention

This error almost always happens because a COM+ app crashed mid-transaction or because the server was hard-rebooted. To prevent it:

• Always shut down COM+ apps gracefully before a server reboot. Use the Component Services GUI or net stop on the service hosting the app.
• Don't use hard reset buttons. I know it's tempting when a server hangs, but COM+ CRM doesn't handle dirty shutdowns well. If you can, use a graceful OS shutdown.
• If your app uses custom CRM workers, make sure they implement the ICrmLogControl interface correctly. Misbehaving CRM workers that don't properly complete or forget transactions are a common cause.
• Monitor the COM+ event logs for warnings about lingering CRM records. A scheduled task that runs weekly, checks for .crmlog files older than 7 days, and deletes them can save you from this exact headache. Just make sure the app isn't using them first.

One last thing: if you're on a cluster (Windows Server Failover Cluster), don't delete those log files on a passive node. The CRM state is shared across nodes. Only fix the active node, then fail over gracefully. I've seen admins make that mistake and lose transaction history on a live cluster. Don't be that guy.