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

C# Problem Overview

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?

C# Solutions

Solution 1 - C#

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.

Solution 2 - C#

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;

Solution 3 - C#

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:

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.
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.

Solution 4 - C#

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");
}

Solution 5 - C#

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).

Solution 6 - C#

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.

Content Type	Original Author	Original Content on Stackoverflow
Question	BlueRaja - Danny Pflughoeft	View Question on Stackoverflow
Solution 1 - C#	Roman O	View Answer on Stackoverflow
Solution 2 - C#	BlueRaja - Danny Pflughoeft	View Answer on Stackoverflow
Solution 3 - C#	i_am_jorf	View Answer on Stackoverflow
Solution 4 - C#	Alex Jolig	View Answer on Stackoverflow
Solution 5 - C#	Ali Rasouli	View Answer on Stackoverflow
Solution 6 - C#	Mohamed Nagieb	View Answer on Stackoverflow