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

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

I got this problem while working with a large database and it made the UI freeze for a long period. So I put the codes in a BackgroundWorker and now the problem is gone. thanks to @i_am_jorf

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.

private void btnConvert_Click(object sender, EventArgs e)
{
  Cursor = Cursors.WaitCursor;
  bgwConvert.RunWorkerAsync();
}

private void bgwConvert_DoWork(object sender, DoWorkEventArgs e)
{
  //My taking-lots-of-time codes
}

private void bgwConvert_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e)
{
  Cursor = Cursors.Default;
  MessageBox.Show("Done");
}

Answer 3

I just had the same problems moments ago, the solution in my case was simple: Clean the solution and rebuild it!

I am using Visual Studio 2015.

Hope this one helps.

Answer 4

I also had this problem, and I solved it by changing my .Net framework to the latest one (.Net framework 4.5 in my case; from project properties Window-> Debug-> .Net Framework), and changing the CPU type from x86 to Any CPU (in project properties Window-> Build-> Platform Target).

Answer 5

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.

Answer 6

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;