Visual Studio: ContextSwitchDeadlock

C#Sql ServerVisual Studio

C# Problem Overview


I have been getting an error message that I can't resolve. It originates from Visual Studio or the debugger. I'm not sure whether the ultimate error condition is in VS, the debugger, my program, or the database.

This is a Windows app. Not a web app.

First message from VS is a popup box saying: "No symbols are loaded for any call stack frame. The source code can not be displayed." When that is clicked away, I get: "ContextSwitchDeadlock was detected", along with a long message reproduced below.

The error arises in a loop that scans down a DataTable. For each line, it uses a key (HIC #) value from the table as a parameter for a SqlCommand. The command is used to create a SqlDataReader which returns one line. Data are compared. If an error is detected a row is added to a second DataTable.

The error seems to be related to how long the procedure takes to run (i.e. after 60 sec), not how many errors are found. I don't think it's a memory issue. No variables are declared within the loop. The only objects that are created are the SqlDataReaders, and they are in Using structures. Add System.GC.Collect() had no effect.

The db is a SqlServer site on the same laptop.

There are no fancy gizmos or gadgets on the Form.

I am not aware of anything in this proc which is greatly different from what I've done dozens of times before. I have seen the error before, but never on a consistent basis.

Any ideas, anyone?

Full error Text: The CLR has been unable to transition from COM context 0x1a0b88 to COM context 0x1a0cf8 for 60 seconds. The thread that owns the destination context/apartment is most likely either doing a non pumping wait or processing a very long running operation without pumping Windows messages. This situation generally has a negative performance impact and may even lead to the application becoming non responsive or memory usage accumulating continually over time. To avoid this problem, all single threaded apartment (STA) threads should use pumping wait primitives (such as CoWaitForMultipleHandles) and routinely pump messages during long running operations.

C# Solutions


Solution 1 - C#

The ContextSwitchDeadlock doesn't necessarily mean your code has an issue, just that there is a potential. If you go to Debug > Exceptions in the menu and expand the Managed Debugging Assistants, you will find ContextSwitchDeadlock is enabled.

If you disable this, VS will no longer warn you when items are taking a long time to process. In some cases you may validly have a long-running operation. It's also helpful if you are debugging and have stopped on a line while this is processing - you don't want it to complain before you've had a chance to dig into an issue.

Solution 2 - C#

In Visual Studio 2017, unchecked the ContextSwitchDeadlock option by:

Debug > Windows > Exception Settings

enter image description here

In Exception Setting Windows: Uncheck the ContextSwitchDeadlock option

enter image description here

Solution 3 - C#

As Pedro said, you have an issue with the debugger preventing the message pump if you are stepping through code.

But if you are performing a long running operation on the UI thread, then call Application.DoEvents() which explicitly pumps the message queue and then returns control to your current method.

However if you are doing this I would recommend at looking at your design so that you can perform processing off the UI thread so that your UI remains nice and snappy.

Solution 4 - C#

It sounds like you are doing this on the main UI thread in the app. The UI thread is responsible for pumping windows messages as the arrive, and yet because yours is blocked in database calls it is unable to do so. This can cause problems with system wide messages.

You should look at spawning a background thread for the long running operation and putting up some kind of "I'm busy" dialog for the user while it happens.

Solution 5 - C#

If you don't want to disable this exception, all you need to do is to let your application pump some messages at least once every 60 seconds. It will prevent this exception to happen. Try calling System.Threading.Thread.CurrentThread.Join(10) once in a while. There are other calls you can do that let the messages pump.

Solution 6 - C#

The above solution is good in some scenarios but there is another scenario where this happens when you are unit testing and you try to "Debug Selected Tests" from the Test Explorer when you solution is not set to Debug.

In this case you need to change your solution from Release or whatever it is set to to Debug in this case. If this is the problem then changing "ContextSwitchDeadlock" won't really help you.

I missed this myself because the error message was so nasty I didn't check the obvious thing which was the Debug setting!

Solution 7 - C#

In Visual Studio 2017 Spanish version.

> "Depurar" -> "Ventanas" -> "ConfiguraciĆ³n de Excepciones"

and search "ContextSwitchDeadlock". Then, uncheck it. Or shortcut

> Ctrl+D,E

Best.

Solution 8 - C#

You can solve this by unchecking contextswitchdeadlock from

Debug->Exceptions ... -> Expand MDA node -> uncheck -> contextswitchdeadlock

Solution 9 - C#

Had this issue as well and my fix was to add "await" to my threads:

Await Task.WhenAll(taskList.ToArray())
Await Task.Run(myAction)

Solution 10 - C#

I was getting this error and switched the queries to async (await (...).ToListAsync()). All good now.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionSeaDriveView Question on Stackoverflow
Solution 1 - C#PedroView Answer on Stackoverflow
Solution 2 - C#Hassan RahmanView Answer on Stackoverflow
Solution 3 - C#SpenceView Answer on Stackoverflow
Solution 4 - C#Rob WalkerView Answer on Stackoverflow
Solution 5 - C#rold2007View Answer on Stackoverflow
Solution 6 - C#EwanView Answer on Stackoverflow
Solution 7 - C#kahonmlgView Answer on Stackoverflow
Solution 8 - C#KR AkhilView Answer on Stackoverflow
Solution 9 - C#Andrew GaleView Answer on Stackoverflow
Solution 10 - C#dunwanView Answer on Stackoverflow