Hi,
I have a routine which transfers data from an excel worksheet to a data table, then I iterate through the datatable to update records in an Sql database. Works fine up to a point, however half way through the process, I get the following error message.
"No symbols are loaded for any call stack frame. The source code cannot be displayed"
Whe I click OK on this messagebox, the following error information is shown.
ContextSwitchDeadlock was detected
Message: The CLR has been unable to transition from COM context 0x1a1de0 to COM context 0x1a1f50 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.
The "long running operation" consist of updating 2 columns of a table containing 8 columns, with 98 records, however, the stop occurs after 51 records have beend updated, and the application does become non responsive.
I'd really appreciate a simple explanation of the above messages. And some code in VB to use the recommended CoWaitForMultipleHandles, or whatever else will overcome my problem.
I've searched the MSDN site, but cannot come up with answers that I understand.
Cheers
Tailor
Call Stack Frame
JEP8979
Hi Lifeng Lu,
Thank you for your reply, and I believe you are correct about the reasons for the problem. I will bear in mind your advice about running code in a background nonSTA thread, if I strike the problem again.
In the meantime because of the small number of records involved, (usually less than 350) I have reworked the code to renew my Command Object inside the For loop, instead of using the same one multiple times. This has seemed to eliminate the problem, and in fact, there seems to have been a beneficial effect on the processing speed.
Your interest and advice is much appreciated.
John
DavidFG
I think the routine is running in the main thread of your application. The ContextSwitchDeadlock is often reported, when your routine in your main UI thread takes longer than 60 seconds, and doesn't pump messages. When it doesn't pump messages, if another thread happens to call (COM call) into the main thread, it couldn't go through. It is actually hard to know whether someone will call you when you are in a long process. Actually, in the managed world, that call is caused by GC, which could run at anytime, and when managed COM wrapper is cleaned up, it tries to call into the main thread to release the COM object.
Unless you manage all COM reference by yourself, which is almost impossible to do. It is better to move all long processes into a background thread. In your case, try to run that piece of code in a background non STA thread. Of course, it could take some time to do.
On that other hand, some of those issues may be ignored. You can turn off the related option in the Debug/Exceptions.../Managed Debugging Assistants".
Thanks