Visual Studio: ContextSwitchDeadlock

Question

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.

score 361 · Accepted Answer · edited Sep 30 '21 at 09:46

361

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.

edited Sep 30 '21 at 09:46

Andreas

5,393
9
44
53

answered Feb 23 '09 at 17:07

Pedro

12,032
4
32
45

4

Right on! Thanks. I did have to go to Customize and add Exceptions to the Debug menu. Not the most intuitive aspect of the UI. Tools\Customize, then Rearrange Commands (button), then Select Debug from drop-down at upper right, then Add (button). Whew! – SeaDrive Feb 23 '09 at 17:56
Yeah, it seems some installs have that on the menu and some do not. I've seen that with other useful menu items as well, and I've yet to figure out what turns them on or off by default. – Pedro Feb 23 '09 at 19:15
107

`ctrl-alt-e` brings the exception dialog. – Florian Doyon Feb 17 '12 at 11:32
1

Many of the more recent versions of Visual Studio (2012, 2010, 2008) and possibly some earlier ones, allow one to choose the primary use of Visual Studio when it is first run after installation. That choice determines the default layout of toolbars, including which controls are visible or hidden, and even which keystrokes correspond to which commands. In VS 2010, the Import and Export Settings Wizard allows you to reset to one of the available defaults. – Zarepheth Dec 10 '13 at 16:00
Yes, and this is a pita! – Johan Boulé Oct 28 '15 at 16:51
Thanks for that; since it is a "debugging" thing, does that mean that a user (running the release version of the .exe) would never see it anyway? – B. Clay Shannon-B. Crow Raven Nov 24 '15 at 17:59
4

@B.ClayShannon - ContextSwitchDeadlock is specific to the debugger. A release version of the exe won't display this message. – Pedro Dec 03 '15 at 18:36
This solution resolver the problema for Relese mode too ? – Pedro Franco Apr 29 '16 at 19:46
10

In VS 2013 Navigate with `Debug -> Windows -> Exceptions Settings`. Then use search – Markus Weber Jun 28 '16 at 15:47
1

@MarkusWeber same with 2015 – Noah Cristino Jul 09 '17 at 21:04
@MarkusWeber same with 2017. Debug -> Windows is where it's at. – Dan Nov 29 '17 at 17:53
To clarify re finding Exceptions Settings under Debug > Windows: FIRST, open a solution - the menu item won't be there if you don't have any solution open. – ToolmakerSteve Jul 02 '19 at 20:38

score 58 · Answer 2 · answered Mar 07 '19 at 16:43

58

In Visual Studio 2017, unchecked the ContextSwitchDeadlock option by:

Debug > Windows > Exception Settings

In Exception Setting Windows: Uncheck the ContextSwitchDeadlock option

answered Mar 07 '19 at 16:43

Hassan Rahman

4,953
1
34
32

still works in VS 2019 Pro – Tom McDonald Sep 20 '21 at 00:32

score 22 · Answer 3 · answered Mar 04 '09 at 22:41

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.

score 17 · Answer 4 · answered Feb 23 '09 at 17:02

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.

score 10 · Answer 5 · answered Mar 04 '09 at 22:38

10

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.

answered Mar 04 '09 at 22:38

Could you explain why this helps? – rollsch Oct 16 '17 at 22:23
This will not work, I have a loop updating UI and still get the error message. – htm11h Jan 09 '18 at 21:22
1

There is no need to use a value of 10 milliseconds, in fact if you intend to call it repeteadly in a long-running operation, that will decrease the overall performance (total time execution) a lot. Just pass zero to it. – ElektroStudios Dec 03 '18 at 14:00
I had similar problem. Found your solution to be working. Thanks! – Sk Shahnawaz-ul Haque Apr 22 '20 at 12:55

score 3 · Answer 6 · answered Jul 21 '16 at 09:12

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!

score 3 · Answer 7 · answered Jul 07 '17 at 09:34

3

In Visual Studio 2017 Spanish version.

"Depurar" -> "Ventanas" -> "Configuración de Excepciones"

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

Ctrl+D,E

Best.

answered Jul 07 '17 at 09:34

kahonmlg

3,839
3
17
21

score 2 · Answer 8 · answered Nov 06 '17 at 07:14

2

You can solve this by unchecking contextswitchdeadlock from

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

answered Nov 06 '17 at 07:14

KR Akhil

877
3
15
32

score 2 · Answer 9 · answered Apr 01 '21 at 22:02

2

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

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

answered Apr 01 '21 at 22:02

Andrew Gale

61
3

score 1 · Answer 10 · answered Dec 10 '19 at 20:22

1

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

answered Dec 10 '19 at 20:22

dunwan

1,577
2
16
14

score 0 · Answer 11 · answered Jun 26 '23 at 10:19

0

For everyone using SQLite on your project, don't forget to write database changes. If database is open in SQLite Browser, it causes deadlock.

answered Jun 26 '23 at 10:19

Daumantas Drukteinis

45
5

score 0 · Answer 12 · answered Jul 10 '23 at 16:50

What worked for me was to put the code that's taking a while and assigned it to background worker process.

// Attaching a long running task to a new thread and wait for process to finish.
System.Threading.Tasks.Task.Run(() => 
     {
        // Do Long running code here
     }).Wait();

This will run the code on a new thread and the main thread will wait for this task to complete

Visual Studio: ContextSwitchDeadlock

12 Answers12

Linked