WPF рендеринг потока зависает - PullRequest
24 голосов
/ 26 мая 2011

У меня возникла проблема в приложении wpf, где поток рендеринга останавливает рендеринг, но поток пользовательского интерфейса и вспомогательные потоки по-прежнему отправляют сообщения.

Похоже, это связано с повреждением шрифта презентации.кэша, однако это кажется маловероятным, так как приложение восстанавливается нормально при перезагрузке.

Поток рендеринга иногда зависает, предотвращая обновление чертежей, но поток пользовательского интерфейса все еще отправляет сообщения.

Мы виделианалогичная проблема (похожая на здесь ), возникшая при применении преобразования масштаба к текстовому блоку, которая была решена путем удаления кэша шрифтов, однако эта конкретная проблема не может быть надежно повторена.

Каков наилучший способ диагностики основной причины этой проблемы?

У меня есть ошибка с Microsoft в connect , но она не будет рассматриваться, если другие не проголосуютдо.

Ответы [ 5 ]

5 голосов
/ 14 июля 2011

Замораживание вызвано размещением видео элемента управления activex.

В способе управления DirectShow возникло состояние гонки, из-за которого DirectX завис.

Мы нашли эту проблему, взяв дамп процесса с помощью procdump , а затем открыв файл дампа в windows отладчик .

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

Это позволило нам создать повторяющиеся зависания, используя код, который запускает и останавливает видео. Мы сняли управление, и зависание прекратилось.

1 голос
/ 06 июня 2011

Единственный способ найти основную причину проблемы - это постоянное ведение журнала из потока, пока вы не найдете причину, по которой он зависает.Я могу предложить много способов сделать это, но это зависит от того, насколько сложен этот код в потоке рендеринга.Без большого количества отладочной информации (такого рода вещи, которые вводят достаточно времени ожидания для временного решения проблемы, не меньше), вы не сможете развернуться до единственного момента, когда это происходит.

Если вы можете повторить это в VS, то вам следует использовать консольное журналирование вокруг ожидаемых проблемных частей, в противном случае вам, вероятно, придется вставить его в текстовый файл или отправить в системный регистратор.

Можете ли вы заставить его повторяться в простом приложении, которое выполняет только рендеринг и связанные части остальной части приложения, или это происходит только (может быть только?) В полной программе?

1 голос
/ 02 июня 2011

Я не знаю, почему это происходит, но я испытал это раньше.Проще наблюдать это в системах, предназначенных для Framework 4.0 и работающих на старых машинах (XP, Vista).

Я решил решить:

  1. Удалить FontCache3.0.0.0.dat
  2. Постоянно отключить службу кэширования шрифтов на компьютере-нарушителе

Решение 1 работало на одном компьютере с XP.Это также работало на компьютере с Vista, но через некоторое время проблема обнаружилась снова.

Чтобы удалить FontCache3.0.0.0.dat, вам нужно остановить службу «Windows Presentation Foundation Font Cache 3.0.0.0».прежде чем вы сможете удалить этот файл.В Vista он находится в каталоге c: \ windows \ serviceprofiles \ localservice \ appdata \ local.В XP он находится в папке c: \ windows \ system32 \ documents and settings \ localservice \ local settings \ application data (возможно, я неправильно ввел какую-то папку)

Я также обнаружил, что отключение системы вообще (решение 2)не влияет на производительность моих приложений .net.

0 голосов
/ 01 июня 2011

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

0 голосов
/ 31 мая 2011

Вы можете использовать сторожевой сервис, который очищает кэш, когда сервис обнаруживает проблему. Служба должна будет периодически опрашивать каждый раз, когда ваше приложение работает.

Я буду первым, кто признает, что это неоптимальное решение, и, если вы не сможете включать и выключать сервис только на небольшие промежутки времени, вы, скорее всего, разряжаете батареи довольно быстро.

...