Recurring error - The incoming tabular data stream (TDS) protocol stream is incorrect. The MARS TDS header contained errors.

Question

Not sure if this is the right forum for this question, but my closest searches (thought disappointing) have suggested it is probably a SQL-related issue.

We're getting this error once every other week or so on an ASP.NET application built on .NET Framework 3.5 running against SQL Server 2005.  I can't find much info on this error, but we are up to date on our SQL Server service packs.  When we get this error no one is able to make a connection and we end up having to reboot the server.

Has anyone experienced this error and found a solution for it? 

Answer 1

I've never experienced the error, but it's definitely a SQL Server error message (message_id 4011), complaining that the command given by the client is wrong somehow.

You mention that no-one is able to connect - does this mean using the application, or will Management Studio also not work?

Does your application require MARS (Multiple Active Record Sets)?  If not, you can disable MARS by editing your connection string to include MultipleActiveResultSets=False.

See these two pages: 

http://msdn.microsoft.com/en-us/library/h32h3abf.aspx

http://msdn.microsoft.com/en-us/library/ms345109(SQL.90).aspx

It's worth noting that the first indicates that MARS is disabled by default, but the second states:

 

MARS-enabled client drivers are the following:

• The SQLODBC driver included in the SQL Native Client.
• The SQLOLEDB driver included in the SQL Native Client.
• The SqlClient .NET Data Provider included in the Microsoft .NET Framework, Version 2.0.

By default, these drivers will establish MARS-enabled connections. If for some reason it is desired to establish connections that expose behavior of down-level drivers, each API provides an option to request non-MARS connections

 

The first article is much more recent, however.  Anyway, if you know you don't need MARS, I'd consider explicitly disabling it to see if this has any effect.

Answer 2

Thank you very much for your input!  It provided some information I hadn't been able to dig up on my own.  I read both of those articles and they were very helpful.  I'm not aware that we're using MARS explicitly.  One thing that *did* strike a chord when I was reading, though, was running multiple command objects on the same connection.  I can't say for sure that our app does this, but the possibility is certainly there. 

To answer your question, I'm afraid I'm not sure if we're able to connect via SMSS when this happens, but I think we can.  Users of our app are certainly locked out, though. 

Is there any quick and dirty way to check my .NET code and/or SQL stored procedures to see if we're using MARS explicitly or implicitly?  We are definitely using the SqlClient .NET provider extensively. 

I'm glad to hear about the MARS connection string parameter.  If nothing else, maybe I can set that explicitly to false and see if and where the system breaks.

Answer 3

The easiest way to see if you're using MARS is to connect to Management Studio and run the following command:

<br/>SELECT CASE WHEN Parent_Connection_id IS NULL THEN 'Not MARS' ELSE 'MARS' END as IsMARS, * 
FROM sys.dm_exec_connections
ORDER BY 1

This will show you if you are indeed connecting using MARS (and most likely will, given your error message), but won't tell you if you are actually using MARS. As far as I can tell, there's no actual way of determining if you are or not, except for looking at your code and determining if you interleave your SQLCommand objects.  For example:

Open ConnectionA

Create a SQLCommand (Cmd1) from ConnectionA

Pull some rows from Cmd1

Create a SQLCommand (Cmd2) from ConnectionA

Pull some rows from Cmd2

Pull some rows from Cmd1

Close ConnectionA

If you are using MARS, you can either try changing the code to remove the MARS ability (create a new connection), or analyse your code to figure out why this is happening.  It could be an obscure bug in the .NET libraries or the SQL Native Client.

To confirm that the problem is at the client, I suggest you restart the website in IIS (or restart IIS completely) and not SQL Server next time.  It doesn't sound as if SQL Server would go "bad" for all MARS-enabled connections, so the fault must lie on the ASP.NET application end.

Answer 4

Wow, I REALLY appreciate all your information and help, it has been invaluable.  The query you sent so far has yielded no MARS connections, so we're going to try adding the disable parameter to our connection strings and see what happens.  If we start getting errors at least I'll have a better handle on where to look for possible MARS activity.

Thanks again!

Mike