Develop Reference

CLR has been unable to transition from COM context

This sort of thing is already on Stack Overflow, here. However, it doesn't quite fix the problem.
I'm working on a probability simulator that's multi-threaded. Say, I want to figure out the result of one billion "dice rolls." If this runs for > 1 minute, the following message pops up:
The CLR has been unable to transition from COM context 0x29eac30 to COM context 0x29eab78 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.
My code includes, for the situation:
bool done = false;
while (done)
{
done = false;
foreach (WorkerObject w in workers)
{
done = done && w.done;
}
}
I'm using Task objects for multi-threading, and there is a Task.Wait() method, but this is a thread-blocking operation that does essentially the same thing as this. Using Thread.Sleep(500) in the loop gives the same result.
Now, I've Googled around for how to actually fix this, and, normally, the "fix" is to disable the compiler warning and to just keep going on with it, but how would I actually fix the problem?

CLR has been unable to transition from COM context 0x3b2d70 to COM context

While debugging an application i am getting the following error.
The CLR has been unable to transition from COM context 0x3b2d70 to COM
context 0x3b2ee0 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.
Why system throws this error.

I got the solution
Need to uncheck ContextSwitchDeadlock under Debug->Exceptions->Managed Debugging Assistants.
After unchecking ContextSwitchDeadlock its not throwing the error.

Error on inserting data in SQL Server db from Excel Sheet

I am inserting data from an Excel sheet to SQL Server 2005 db. I am getting this error randomly, sometimes after 20-30 records and sometimes after 1000s. I am unable to find the reason.
I am using Visual Studio 2008.
The CLR has been unable to transition
from COM context 0x21a7b0 to COM
context 0x21a920 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.
Can anybody tell me what this error is and why I am getting this.
Thanks.

edit: This thread seems to directly answer your question and the steps involved to solve it.
If you want to learn more check out this MSDN article.

Are you closing connections when you are done with them? It may be that connections are left open, consuming the maximum number of connections available to your application, and eventually timing out.

Strange Message about threads in C#

I have a program that I run and in the middle I get this message:
Managed Debugging Assistant 'ContextSwitchDeadlock' has detected a problem in 'C:\Documents and Settings\Lena G\My Documents\SchoolStuff\IR Information\Home Work\FianlProject\finalProject\finalProject\bin\Debug\finalProject.vshost.exe'.
Additional Information: The CLR has been unable to transition from COM context 0x3407968 to COM context 0x3407ad8 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.
I understand that it has something to do with the fact that it runs for 60 seconds without stopping or something like that? How is it a problem?
I also put [STAThread] before the main of my program because if I remove it then it shows me this message:
An unhandled exception of type 'System.Threading.ThreadStateException' occurred in System.Windows.Forms.dll
Additional information: Current thread must be set to single thread apartment (STA) mode before OLE calls can be made. Ensure that your Main function has STAThreadAttribute marked on it. This exception is only raised if a debugger is attached to the process.
Anyone know how I can solve this problem?
Thanks in advance,
Lena

You need to make sure that your thread that owns the COM component isn't being "locked up" via processing for >60 seconds.
What's probably happening is that you have a COM object in a form, and you're doing work on the UI thread. If your UI gets blocked by the processing for >60 seconds, the COM component can complain.
Consider using a BackgroundWorker instance to handle your long running process. This would push the work onto a background thread, and allow the COM component to process messages without complaints.

It is a warning that's generated when you make calls on an ActiveX object from a background thread and your main thread is blocked. Perhaps more likely: there was a bug in the retail version of Visual Studio 2005 that tripped this warning for no good reason. It got fixed in Service Pack 1, be sure you have that installed. Yet another workaround is to shut it up. Debug + Exceptions, Managed Debugging Assistants, untick the ContextSwitchDeadlock warning. But use SP1 if you don't have it.

ContextSwitchDeadlock when running unit (integration) tests

We get the following error when running at test:
ContextSwitchDeadlock was detected
Message: The CLR has been unable to transition from COM context 0x344b0c0 to COM
context 0x344b230 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.
The test does a WCF call to a method on the service layer that gets data from the database using Entity Framework. Data is also Cached on the server side using EntLib Caching Application Block.
The test that tests the same code on the server side passes without error.

Found the problem.
We were not closing the WCF proxies correctly. We were using "using" instead of a try catch with close or abort.
Therefore, an error in one test would cause a ContextSwitchDeadlock in a subsequent test that tried to use the same WCF service.