Contextswitchdeadlock

Question

While debugging my program in VS 2008, I encountered the following error:

The CLR could not move from the COM context 0x34fc1a0 to the COM context 0x34fc258 for 60 seconds. A thread that owns the target context / apartment most likely either performs a non-download or processes a very long operation without pumping Windows messages. This situation, as a rule, has a negative impact on performance and may even lead to the application becoming inactive or memory automatically accumulating over time. To avoid this

It seems to be inhibited, although the code only contains a simple C # timer: see snippet below:

private void RequestWork() { // The timer will be re-intialised if there are still no wating jobs in the database StopTimer(); // assign all the threads some work InitialiseTimer(); } /// <summary> /// Initialise a timer with a timer interval configured from app.config. Enable the timer and /// register an appropriate event handler /// </summary> private void InitialiseTimer() { if (m_Timer == null) { // look up the default backoff time from the config string backOffInt = ConfigurationSettings.AppSettings["BackOffInterval"]; int backoffInterval = 1000; m_Timer = new System.Timers.Timer(); // set the timer interval to 5 seconds m_Timer.Interval = backoffInterval; m_Timer.Elapsed += new ElapsedEventHandler(m_Timer_Elapsed); } m_Timer.Enabled = true; } private void StopTimer() { if (m_Timer != null) { m_Timer.Enabled = false; } } void m_Timer_Elapsed(object p_Sender, ElapsedEventArgs p_E) { RequestWork(); } 

As far as I know, the timer should work, pass, and then initialize again, I see no local reason for the deadlock.

I know how to disable this error, but I feel that this is not a solution, instead it masks the problem.

Answer 1

You can disable this if you think you definitely do not have a deadlock situation:

Debug-> Exceptions-> Managed Debug Assistants in Visual Studio and uncheck ContextSwitchDeadlock

Answer 2

This is an endless cycle. You must allow your application to send messages at least once every 60 seconds to eliminate this exception. Try calling System.Threading.Thread.CurrentThread.Join (10) once in a while. There are other challenges you can make to get messages displayed.

Answer 3

It seems that you add a new event handler every time you call InitialiseTimer. Thus, m_Timer_Elapsed will be called as many times as it was added. You must add an event handler only once.

Answer 4

If your application freezes or does not respond even after unchecking the context switch. Place the following line before calling the method or for the loop.

In c #

 System.Windows.Forms.Application.DoEvents(); 

and VB.NET/VB/ASP.NET

 DoEvents() 

Answer 5

A couple of questions / questions:

1) The code snippet looks like your interval is 1 second (not 5, as indicated in the comments). 2) The big question is: what does RequestWork() do?

Not knowing what RequestWork() does, we cannot comment on why you see ContextSwitchDeadlock.

Something to think about this method a) how long will it take? b) is it access to GUI elements?

Some MSDN comments about the past:

If you use a timer with a user interface element, such as a form or control, assign a form or control that contains a timer to the SynchronizingObject property, so that the event is marshaled to the user interface stream.

-and-

The expired event is raised by ThreadPool thread. If processing an Expired Event lasts longer than the Interval, the event can be raised again to another ThreadPool thread. Therefore, the event handler must be returnable.

I think, since you have a 1 second timer, you can see what happens in RequestWork and see how long it will take.