имаюсь разработкой приложения на C # (.Net 3.5, Win Forms), которое запускается на сервере и доступно пользователям с помощью удаленного рабочего стола. Приложение продолжает зависать на случайных на удаленной машине случайных случаях (то есть все компоненты графического интерфейса становятся белыми, диспетчер задач сообщает, что приложение не отвечает), но не при локальном запуске (я неполностью уверен в этом, но не смог воспроизвести стоп-кадр на моей машине).

Кто-нибудь сталкивался с таким поведением в своих приложениях, к которым осуществляется удаленный доступ? Какую стратегию отладки вы бы предложили? Нужно ли учитывать что-то особенное при разработке приложений Win Forms, к которым обращается удаленный рабочий стол?

РЕДАКТИРОВАТЬ: некоторые заметки о приложении и заморозке: приложение не восстанавливается после заморозки. Кроме того, замораживание не происходит (или еще не произошло) во время взаимодействия с пользователем, но между входами в систему на удаленной машине. Приложение следит за решателем CFD, поэтому оно работает, даже когда его никто не использует.

ОБНОВИТЬ:

Мы действительно внедрили подробное ведение журнала, записывая каждый вызов функции в файл с отметкой времени. К сожалению, результаты были не очень убедительными. То есть последний зарегистрированный вызов функции всегда возвращается правильно. Кроме того, некоторые фоновые таймеры все еще работали, хотя приложение выглядело замороженным (графический интерфейс пользователя полностью белый и т. Д.). Посленекоторые проблемы нам удалось взглянуть на сбой в WinDBG. В системном потоке мы нашли вызов OnUserPreferenceChanged () и далее до Invoke.WaitOne (). Мы пока не можем сказать наверняка, но, похоже, это проблема,эти статьи, В качестве быстрого исправления я установил фиктивный обработчик для упомянутого события. Я сообщу, как это работает.

ОБНОВЛЕНИЕ 2:

Оказывается, при входе в систему на удаленном компьютере запускается несколько событий OnUserPreferenceChanged (). Так что это действительно была подозреваемая проблема. Исправление оказалось не таким простым, хотя. Я ожидал бы, что IllegalCrossReferenceException выбрасывается каждый раз, когда фоновый поток пытается изменить элемент управления, созданный в системном потоке. Это не похоже на случай. Я назвал свой системный поток, и перед каждым доступом к элементу управления я утверждал, что текущим именем потока является имя системного потока. В разных местах это утверждение не удалось (например, при обратном вызове из таймера), но не было выдано исключение. После использования надлежащего делегирования в этих местах, заморозки прекратились. Приложение работает без остановки уже несколько недель, и мои пользователи снова счастливы;)