The CLR has been unable to transition from COM context [...] for 60 seconds

Question

I am getting this error on code that used to work. I have not changed the code.

Here is the full error:

The CLR has been unable to transition from COM context 0x3322d98 to COM context 0x3322f08 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.

And here is the code that caused it:

var openFileDialog1 = new System.Windows.Forms.OpenFileDialog();
openFileDialog1.DefaultExt = "mdb";
openFileDialog1.Filter = "Management Database (manage.mdb)|manage.mdb";

//Stalls indefinitely on the following line, then gives the CLR error
//one minute later.  The dialog never opens.
if(openFileDialog1.ShowDialog() == DialogResult.OK)
{
    ....
}

Yes, I am sure the dialog is not open in the background, and no, I don't have any explicit COM code or unmanaged marshalling or multithreading.

I have no idea why the OpenFileDialog won't open - any ideas?

Answer 1

One fix for the problem is to go to the Debug -> Exceptions -> Managed Debug Assistants menu in Visual Studio and uncheck the ContextSwitchDeadlock

From http://blog.wpfwonderland.com/2007/08/16/clr-has-been-unable-to-transition-from-com-context-for-60-seconds/

Update: Please, don't downvote, if you fairly think, that workaround is awful idea. A number of people tried a number of solutions listed as answers here, but my workaround was the only thing helped them. That's why the answer still has the positive score.

Answer 2

Figured it out - it automatically brings you to the last location you looked in every time the dialog opens. If that location is a network location that no longer exists (ex. the other computer is off), it will just hang forever.

My workaround looks like this:

string initialDirectory = ...; //Figure out an initial directory from somewhere
openFileDialog1.InitialDirectory = !Directory.Exists(initialDirectory)
                                       ? Path.GetPathRoot(Environment.SystemDirectory)
                                       : initialDirectory;

Answer 3

So, it's complaining about a COM context even though you're not explicitly using COM because opening a native shell dialog underneath all that lovely c# code, and the shell does use COM.

What this message is telling you is that whatever it's trying to do, it's doing it on the UI thread and not in a nice way, and that seems to be taking a long time. Obviously whatever is wrong isn't your fault per-se, so you can ignore most of the advice it's giving you.

Things to try:

1. First I would try, as AaronLS suggest, simplifying your openFileDialog as much as possible. Try not setting anything; just create a new guy and call ShowDialog(). If that solves the problem, then you've just given it malformed parameters, and we can go talk about the implications of that. However if it does not work, that means that something is going wrong in shell land.

2. One possible reason this might happen is because you have a shell extension installed that is doing something bad. The best thing for you to do is break-in (ctrl+break in Visual Studio I think, or debug->break all on the menu bar) and get the complete stack for us. We should be able to identify the culprit by seeing who is on the stack when the dialog appears.