Обнаружение заторможенного потока пользовательского интерфейса

Question

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

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

Таким образом, в подготовке к этому, несколько вопросов:

1. уже существует что-то вроде этого? Это кажется довольно распространенной проблемой, поэтому, если существуют существующие инструменты для диагностики этого, возможно, стоит использовать их, а не сворачивать собственное решение.

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

Answer 1

уже существует что-то вроде этого?

Да. Крайне важно сделать это за пределами процесса, так как тупик делает очень вероятным, что диагностический код тоже зашел в тупик. DebugDiag utility имеет явную поддержку для замеченных приложений.

Я до сих пор обсуждаю, что информация, которую я должен попытаться собрать

минидампы вы получите из DebugDiag должна быть достаточно, чтобы дать вам выстрел диагностирования причины. Примерный отладочный сеанс, который демонстрирует решение тупика, - shown here.

И, конечно, хороший жесткий взгляд на ваш код никогда не болит. Тупики в области пользовательского интерфейса часто вызваны:

• Отображение окна на рабочем потоке. Класс SystemEvents является очень серьезным нарушителем спокойствия, когда вы это делаете. Он должен запускать свои события в потоке пользовательского интерфейса, но это требует, чтобы он угадал, какой конкретный поток в вашей программе является фактически потоком пользовательского интерфейса. Как только он догадывается, вы настроены на спонтанный тупик любой раз позже. Обратите внимание, что это не требует использования класса SystemEvents в вашем собственном коде, многие элементы управления подписывают событие ThemeChanged, чтобы перерисовать себя. Fwiw, эта сессия отладки, с которой я связан, демонстрирует такой тупик. Остерегайтесь экранов всплесков на дому, окон «прогресса», которые создаются на рабочем потоке вместо потока пользовательского интерфейса и, конечно же, на любом рабочем потоке, который отображает пользовательский интерфейс.

• Элементы управления данными, чей основной источник привязки обновляется в рабочем потоке. Очень часто, поскольку запросы dbase имеют тенденцию быть медленными. Такие элементы управления должны сначала быть несвязаны явно.