VPF::безответный 60 секундный лимит в COM

archeg

Дата 15.11.2007, 18:43 (ссылка)

(нет голосов)

Загрузка ...

Опытный

Профиль
Группа: Участник
Сообщений: 612
Регистрация: 6.1.2007
Где: Киев

Репутация: 11
Всего: 27

Работаю с Excel через COM. При остановке на брекпойнте студия (ну или винда - черт его знает), дает приложению 60 секунд. Понятно что приложение не отвечает и через 60 секунд она пробует убить COM. Это порядком уже надоело, довольно усложняет дебаг. Может кто знает как такую фигню убить? )

Вот ексепшин что вылетает:

Код


ContextSwitchDeadLock was detected:

The CLR has been unable to transition from COM context 0x159928 to COM context 0x1597b8 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.

Это сообщение отредактировал(а) archeg - 15.11.2007, 18:44

--------------------

ИМХО задница есть универсальный интерфейс. Ибо через задницу можно сделать абсолютно ВСЕ (bash.org.ru)

Дядька всегда можно спросить в аське, если не задалбывать - не откажет smile

И вообще, на самом деле я студент, и ненавижу обращение на "Вы") Тут все свои ;)

tol05

Дата 15.11.2007, 19:24 (ссылка)

(нет голосов)

Загрузка ...

Эксперт

Профиль
Группа: Участник Клуба
Сообщений: 1632
Регистрация: 21.12.2006
Где: Харьков

Репутация: 63
Всего: 170

отсюда

Цитата

When you are in debug mode, the CLR has some managed debug assistants (MDA's) that run around looking for bugs (or potential bugs in your code).  The ContextSwitchDeadlock MDA behaves like this: a background thread runs that will (every 60 seconds) attempt to enter the STA that your code is running in.  The way STA works is that a message based protocol is used to marshal calls.  So in order for the MDA to enter, the marshalling message must get processed--which requires that a GetMessage or PeekMessage call be executed on the STA thread in that timeframe.

What this MDA message means then, is that your code has either explicitly or implicitly entered a codepath that is preventing control to flow back to Excel's main message loop.  This could be caused by an infinite loop, or just a long operation.  For example, you can trigger this MDA if you try to synchronously communicate with a database & end up blocking while you wait for a long query to complete.

In your case, since the CPU utilization is at 100% it sounds like you've gotten yourself into an infinite loop.  My guess is that you aren't handling your Range.FindNext call correctly to terminate your loop.  Here's what Help says about that method in remarks:

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

When the search reaches the end of the specified search range, it wraps around to the beginning of the range. To stop a search when this wraparound occurs, save the address of the first found cell, and then test each successive found-cell address against this saved address.

>>>>>>>>>>>>>>>>>>>>>>>>>>

Could it be that you aren't doing this and therefore that your loop termination condition is always false?

Hope that helps.  If you still can't figure this out, feel free to post code as Martin suggested.

--------------------

На хорошей работе и сны хорошие снятся.

0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей)
0 Пользователей:
« Предыдущая тема \| Общие вопросы по .NET и C# \| Следующая тема »