How to fix Error 3910 on Windows Server 2025 / Windows 11

Troubleshooting Guide: SQL Server Error 3910 — “Transaction Context In Use By Another Session”

Why This Error Happens

This error occurs when multiple sessions or connections attempt to use the same transaction context simultaneously, typically caused by improper connection pooling, multi-threaded applications sharing a single SqlConnection object, or distributed transactions that weren’t properly committed or rolled back before a new operation began. It can also surface when linked server queries or MARS (Multiple Active Result Sets) configurations are mismanaged, leaving an orphaned transaction attached to a session that another process then tries to access. Essentially, SQL Server 2025 detects that a transaction is “owned” by a session different from the one currently issuing commands against it.

Step-by-Step Resolution Guide

Step 1: Identify the Conflicting Session

  • Run DBCC OPENTRAN in SQL Server Management Studio (SSMS) to identify the oldest active transaction and its associated Session ID (SPID).
  • Cross-reference with sys.dm_tran_active_transactions and sys.dm_tran_session_transactions to pinpoint which session owns the stuck transaction.
  • Check application logs around the same timestamp to correlate the error with a specific connection or thread.

Step 2: Review Application Connection Handling

  • Inspect the application code (especially .NET apps using SqlConnection/SqlTransaction) to ensure each thread uses its own connection and transaction object rather than sharing a single instance.
  • Verify that Enlist=false or proper TransactionScope boundaries are set if using distributed transactions, located typically in the connection string configuration file (e.g., web.config or appsettings.json).
  • Confirm MARS is explicitly enabled only where necessary by checking for MultipleActiveResultSets=True in the connection string, as improper MARS use is a common trigger.

Step 3: Terminate the Orphaned Session

  • If a stuck session is confirmed via Step 1, run KILL <SPID> in SSMS to forcibly terminate the orphaned transaction (replace <SPID> with the actual session ID).
  • On Windows Server 2025, open SQL Server Configuration Manager and restart the SQL Server (MSSQLSERVER) service if multiple sessions remain locked system-wide.
  • Clear any hung connections in the application’s connection pool by restarting the application pool via IIS Manager (for web apps) or recycling the service in Services.msc.

Step 4: Patch and Update SQL Server

  • Navigate to Microsoft Update Catalog or use SQL Server Setup to confirm you are running the latest Cumulative Update (CU) for SQL Server 2025, as transaction-context bugs are frequently addressed in CUs.
  • Check installed version via SELECT @@VERSION; and compare against the latest build listed on the official SQL Server release notes page.

Alternative or Verification Steps

  • To verify the fix, re-run the failing application workflow while monitoring DBCC OPENTRAN and sys.dm_exec_requests to confirm no transaction remains orphaned across sessions.
  • If the error persists, consider isolating the problematic stored procedure or application module and wrapping all transaction logic in explicit BEGIN TRAN/COMMIT/ROLLBACK blocks with proper TRY...CATCH error handling to eliminate ambiguous transaction ownership.