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?

  • Why is MARS enabled? Isn't there a way to tell EF to turn that crap off? May 29, 2014 at 20:57
  • Yes, I may just suggest they test turning off MARS. I don't know why they are using it and doubt the developer does either as this is a spaghetti code legacy app handed down through many generations of developers. That said, I'm not sure if that will stop this error or make it occur incessantly. May 29, 2014 at 21:00
  • 2
    Yes, I think Ladislav's answer to that question highlights why the dev probably can't disable MARS easily. The app is probably coded to execute multiple queries on the same connection in parallel, and disabling MARS in the connection string may just make the error happen more often unless the dev rewrites the app. The only answer may be 'debug your app, or rewrite it and turn MARS off.' May 29, 2014 at 21:06
  • 2
    For MARS configuration, there is a requirement on the server side that the client will not send second and subsequent batches until first batch that sends reset completes its round trip. But SQLClient driver does not prohibit the caller from doing this. The workaround to prohibit this on the client side is to set Async=true in the connection string so it will serialize executes. If that doesn't work, disable MARS on the client. Here's an article about connection leaks blogs.msdn.com/b/dataaccesstechnologies/archive/2009/10/13/…
    – stacylaray
    May 30, 2014 at 1:24

1 Answer 1


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:


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.

  • 1
    Thanks, I marked this as the answer as it addresses the general question about how to approach this type of problem as a DBA, and provides some useful information that I hadn't considered. Sep 29, 2015 at 20:24
  • @JamesLupolt Thanks. But you have no way to test the app again to confirm? Would it at least be possible to indicate the exact versions of Entity Framework and target .NET Framework? I will also update my answer to clarify to minor things. Sep 29, 2015 at 20:55
  • At this point the app has been replaced. I don't think I have any way of figuring out what the .NET Framework or EF versions were at the time I asked this over a year ago. Sep 29, 2015 at 21:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.