locked
CLR Error RRS feed

  • Question

  • I'm doing a batch data transfer from 'server a' to 'server b'. I get the following error. Any idea what this means please?


    The CLR has been unable to transition from COM context
    0x1b1ae8 to COM context 0x1b1c58 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.
    Tuesday, December 13, 2005 8:27 PM

Answers

  • This is an MDA (managed debugger assistant) that is firing because it thinks it has detected a deadlock.

    You can turn off this MDA (Debug --> Exceptions --> Managed Debugging Assistants, and uncheck the ContextSwitchDeadlock feature) but the result of that is that we'll let the deadlock continue without warning you about it.

    How are you doing this data transfer? Could the code there be the culprit for a deadlock?

     

    Wednesday, January 11, 2006 8:01 PM

All replies

  • What kind of data transfer are you attempting?
    Wednesday, December 14, 2005 3:49 PM
  • This is an MDA (managed debugger assistant) that is firing because it thinks it has detected a deadlock.

    You can turn off this MDA (Debug --> Exceptions --> Managed Debugging Assistants, and uncheck the ContextSwitchDeadlock feature) but the result of that is that we'll let the deadlock continue without warning you about it.

    How are you doing this data transfer? Could the code there be the culprit for a deadlock?

     

    Wednesday, January 11, 2006 8:01 PM
  • Ok, if you read through what it's asking you to do, and why it's doing it along with the command it reccomends; you see that basically windows can't talk to your program for x amount of time so it goes all crazy wondering why for the program has forsaken it so.

    Here's the real question, its not, "How do I get this error to stop popping up," I think more realistically its, "Hey Microsoft, what's the equivalant command for CoWaitForMultipleHandles in VB .NET?"

    With this question answered we can get rid of the problem not the symptom, by allowing windows to continue communicating with the UI while the program is undergoing its heavy processing.

    Also, why do programs like this that are running in some sort of loop take up so little processor useage? My network is barley getting any traffic, and my computer is only using 12-20% of the processor, even less useage on the server side. Thats a side question tho, I'm most interested in the topic at hand.

    Thanks for the response.

    Monday, June 12, 2006 10:23 PM