2

I have a rather long-running process in a Windows Service that periodically throws a "ContextSwitchDeadlock" exception:

enter image description here

I have also rigged my service to send myself emails with details about encountered exceptions. I get:

Date: 05/25/2016 09:16:32:
Exception message: Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is not responding.
Exception Source: .Net SqlClient Data Provider

...and then three seconds later this:

Date: 05/25/2016 09:16:35: 
Exception message: Cannot find table 0.
Exception Source: System.Data

BTW: At least it's consistent: I have had three pairs of those exceptions, and each time the second one is datetimed exactly three seconds after the first.

I have had prior experience with jimmying the SQLCommand's CommandTimeout value (currently set at 360) this way or that, and it seems sort of like throwing darts blindfolded or even black magic. Is there a better way to prevent such deadlocks?

I have other very similar methods that don't cause this problem; those take less time. The duration of the method (specifically, the length of time it takes the query to run) seems to be "the rub." I can't change that - "it is what it is" - so what else can I do?

UPDATE

Naturally, the recalcitrant process "made a liar out of me" right after posting the above, as I got two more pairs of the exceptions, this time with the second err msg of the pair occurring one second after the first instead of three. If I wait long enough, maybe the second exception will occur before the first one.

B. Clay Shannon
  • 1,055
  • 124
  • 399
  • 759
  • 1
    Just to confirm, you only get that ContextSwitchDeadlock thingy when you're debugging? – Lasse V. Karlsen May 25 '16 at 16:35
  • Yes, but that's all I've done so far. I haven't installed the service, so it has only run in debug mode (running it from Visual Studio). – B. Clay Shannon May 25 '16 at 16:37
  • 1
    The other two exceptions, the timeout and the one about the unknown table, are likely *real* problems with your code but I would suggest you post these in a different question, along with the code that triggers them. For the context switch deadlock notice, however, see my answer for what it means and how to get rid of it. – Lasse V. Karlsen May 25 '16 at 16:44

1 Answers1

3

The ContextSwitchDeadlock is a "Managed debugging assistant" in Visual Studio and is one of many tools that the Visual Studio debugger gives you additional aid when debugging an application.

I am not 100% positive what kind of heuristics it uses to figure out when to trigger but I know some, and this is also described in the tool window itself:

The current thread is not currently running code or the call stack could not be obtained.

This last part is what usually trips up Visual Studio and this is usually something that happens when a managed (.NET) program calls into COM or P/Invoke. When this is done, Visual Studio is no longer able to look at the program and figure out what it is doing, and when this happens to take more than 60 seconds, it figures something has gone awry.

If your program is doing the above, calling into COM, or using P/Invoke, or something involving an external non-managed (.NET) code, and this external code takes more than 60 seconds to execute, then the dialog is basically a false positive. If you know that this is benign, as in, "yes, it calls external code, and yes, this may sometimes take more than 60 seconds" then you can remove the check lower in that image:

[ ] Break when this exception type is thrown

Note that it is not necessarily an exception though, this is more Visual Studio just raising a red flag on suspicious (to it) behavior. If you know this is OK, just tell it to stop raising that flag.

Note that this has nothing to do with the other real exceptions you mention in the question, only the big ContextSwitchDeadlock dialog.

Lasse V. Karlsen
  • 350,178
  • 94
  • 582
  • 779
  • Okay, thanks; yes, it also does quite a bit of lengthy Excel Interop stuff, so that is probably the issue. I get the exceptions from time to time, but they don't seem to really cause a problem (I don't know why - based on the verbiage, they seem pretty problematic to me). – B. Clay Shannon May 25 '16 at 16:44
  • 1
    As I said in a comment to your question, my answer only details the context switch deadlock, and since you say you have Excel interop I am almost 100% certain this is the cause for that, however, you can just ask Visual Studio to stop warning you about it, assuming you don't think it is taking too long for no good reason. However, you should post the other exceptions and **the code that triggers them** in a separate question so that they can be looked at in more detail. – Lasse V. Karlsen May 25 '16 at 16:47
  • As you wish: http://stackoverflow.com/questions/37444026/why-am-i-getting-timeout-and-cannot-find-table-0-and-what-preventive-measure – B. Clay Shannon May 25 '16 at 17:32