Hi,
We have scheduler with resources. When try to set scheduler DataSource property, VS shows the message that ContextSwitchDeadlock was detected. DataSource contains 1 resource with more than 200 appointments. I guess the problem is in a large number of appointments we try to show. Is there any limits regard this. This is a complete text of a message:
ContextSwitchDeadlock was detected
Message: The CLR has been unable to transition from COM context 0x20cae8 to COM context 0x20cc58 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.
Thanks.
We have scheduler with resources. When try to set scheduler DataSource property, VS shows the message that ContextSwitchDeadlock was detected. DataSource contains 1 resource with more than 200 appointments. I guess the problem is in a large number of appointments we try to show. Is there any limits regard this. This is a complete text of a message:
ContextSwitchDeadlock was detected
Message: The CLR has been unable to transition from COM context 0x20cae8 to COM context 0x20cc58 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.
Thanks.