How to troubleshoot "client driver has sent multiple requests while the session is in single-user mode" I'm working with a developer who is struggling to stop the following error:


  The server will drop the connection, because the client driver has sent multiple requests while the session is in single-user mode. This error occurs when a client sends a request to reset the connection while there are batches still running in the session, or when the client sends a request while the session is resetting a connection. Please contact the client driver vendor.


When this error occurs, a typical outcome is a session that is holding locks, but has no SQL running (no row in sys.dm_exec_requests for the session_id), and causes blocking until it is killed. The cause of the blocking is straightforward, but how to stop the error from occurring is not.

Some facts about the problem:


The client is using Entity Framework (yes, I know...), with MARS enabled (yes, I know...)
SQL Server version is 10.00.5844 (SQL Server 2008 SP3 CU12). They probably won't upgrade major versions without extensive testing, but applying a newer CU is viable.
The client program shows up in sys.dm_exec_connections as .Net SqlClient Data Provider
The open connection appears to definitely have MARS enabled, as net_transport in sys.dm_exec_connections shows Session.
I'm told the application's connection string has asynchronous processing enabled, per Matt Neerincx's comment in this thread (I don't have access to the application servers to confirm this myself):



  If you set Async=true on the connection string it should prevent this problem.   If you are using MARS and using the same connection on multiple concurrent threads what can happen is the call to reset the connection can get slightly delayed and trigger this error.  If you set Async=true we perform additional locking in the client driver to prevent this from happening.


Further information about this error is scarce. It appears to suggest that the client's program is calling sp_reset_connection while a batch is still running. I could set up a trace to confirm this, but I'd have to record quite a lot of unrelated activity, and the problem is only happening once every few days. Further, I'm not sure that the developer would be able to take advantage of this evidence in order to solve the problem.

Is there any other technique I can use as a DBA or sysadmin to troubleshoot this further, or anything I can suggest to the developer that might provide him with useful information or make the problem less likely to happen?
I don't see it stated anywhere as to what version of the .NET Framework is being used, but given that this question was asked in May of 2014, and .NET Framework version 4.5 came out on 2012-08-15, the following note on SqlConnection.ConnectionString for the Asynchronous Processing / Async keyword seems relevant:


  This property is ignored beginning in .NET Framework 4.5. 


So, it might help to find out the exact version of Entity Framework being used, and the target version of the .NET Framework.

However, it kinda sounds like this issue might be a result of connection pooling. I suspect connection pooling because after the error message about the connection being closed, the session was still around.

The first thing to try is to simply disable connection pooling by adding the following to the connection string:

Pooling=false;


If the problem never comes back, then this was most likely the issue. I hesitate to say that this was the issue since it isn't exactly proof. It could have merely reduced the frequency from "once every few days" to once every few weeks or even months. But, if this does improve things, yet the app hits the server frequently and you would prefer to use connection pooling if at all possible, then you can try to reintroduce connection pooling, but in limited sense: you can set a low value for the Connection Lifetime keyword:

Connection Lifetime=2;


This will have connections close upon returning to the connection pool, if they are over 2 seconds old. This allows for a series of quick query executions to go through without each of them spending time establishing the connection, while at the same time not allowing the connection to linger out there, possibly holding locks, etc.

Even if the error still occurs, by not having connection pooling keeping the session and connection alive, that should allow for proper cleanup, releasing of locks, etc.



Just to have this stated since it was questioned in comments on the question: Multiple Active Result Sets (MARS) is used by Entity Framework to do Lazy Loading. So if the app has been developed to use Lazy Loading, then turning off MARS is not an option.