Перекачка сообщений Windows во время длительной эксплуатации?

Question

Я получаю следующее сообщение на большой операции, я бегу:

Среда CLR не смог перейти из COM контекста 0x1fe458 к COM контекста 0x1fe5c8 в течение 60 секунд. Поток , которому принадлежит место назначения Контекст/квартира, скорее всего, либо без ожидания откачки, либо обработка очень долго работает операция без перекачки Windows сообщений. Эта ситуация обычно имеет отрицательное воздействие на производительность и может даже привести к тому, что приложение становится невосприимчивым или используемым в памяти , постоянно накапливающимся с течением времени. Чтобы избежать этой проблемы, вся одиночные резьбовой квартиры (STA) нити должны использовать насосную ожидания примитивы (например, CoWaitForMultipleHandles) и обычно накачать сообщения во время длительных запущенных операций.

Как отправить сообщения Windows, чтобы эта ошибка больше не возникала при длительных операциях?

Answer 1

Непонятно, в чем заключается контекст: выполняете ли вы какую-то долговременную задачу в потоке пользовательского интерфейса приложения WinForms или WPF? Если это так, не делайте этого - используйте BackgroundWorker или запустите задачу в пуле потоков или в новом потоке напрямую (возможно, используя Control.Invoke/BeginInvoke или Dispatcher, если вам нужно обновить интерфейс). Если большая операция использует СОМ компонент, который жаловался, что это будет сложнее ...

Answer 2

Вы должны обработать свою длинную операцию в отдельном потоке, чтобы избежать зависания пользовательского интерфейса. Это также решит проблему выше

Answer 3

Традиционный метод win32 является:

void PumpMessages() 
{ 
    MSG msg; 
    for(;;) { 
     if(!PeekMessage(&msg, 0, 0, 0, PM_REMOVE)) { 
      return; 
     } 
     if(msg.message == WM_QUIT) { 
      s_stopped = true; 
      return; 
     } 
     TranslateMessage(&msg); 
     DispatchMessage(&msg); 
    } 
} 

Но я понимаю, что вы используете .NET.

Answer 4

В этих сценариях я использую Application.DoEvents. Я не знаю, будет ли это работать в вашей ситуации. Он требует ссылки на System.Windows.Forms, но также будет работать в консольных приложениях.

В качестве альтернативы вы можете попробовать многопоточность своих приложений.

Answer 5

Если это происходит внутри отладчика, это может быть связано с ContextSwitchDeadlock MDA, которое вы можете отключить (используйте окно «Исключения» в Visual Studio). Однако это указывает на большую проблему - вам не следует выполнять длительные операции в потоке пользовательского интерфейса.

Answer 6

Как я знаю, эта вещь происходит только с прикрепленным отладчиком. Вы никогда не получите это исключение в производстве.

Answer 7

Я знаю, что это задавали много лет назад, но надеемся, что это поможет другим в будущем. Если вы не хотите беспокоиться о том, чтобы делать фонового работника или перекачивать сообщения, простое обходное решение просто обновляет что-то в пользовательском интерфейсе. Например, у меня есть инструмент, который только я использую, поэтому мне все равно, использует ли он поток пользовательского интерфейса. Поэтому я просто обновляю textbox.text в пользовательском интерфейсе, над чем я работаю. здесь приведен фрагмент кода. Это очень хакерский и, вероятно, неправильный способ сделать это профессионально, но он работает.

for (int i = 0; i < txtbxURL.LineCount; i++) 
{ 
    mytest.NavigateTo(mytest.strURL); 
    mytest.SetupWebDoc(mytest.strURL); 
    strOutput = mytest.PullOutPutText(mytest.strURL); 
    strOutput = mytest.Tests(strOutput); 
    mytest.CheckAlt(mytest.strURL); 
    mytest.WriteError(txtbxWriteFile.Text); 
    txtblCurrentURL.Text = mytest.strURL; 
    //This ^^^ is what is being updated, which keeps the thread from throwing the exception noted above. 
}