Приложение C # продолжает зависать на удаленном

Question

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

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

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

ОБНОВЛЕНИЕ:

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

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

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

Answer 1

AFAIK, разницы нет. Кроме того, я никогда не сталкивался с такой проблемой. Предлагаю попробовать следующее:

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

Если замораживание продлено на длительное время, попробуйте сделать следующее:

• Воспроизведение стоп-кадра через удаленный рабочий стол.
• Перейдите на компьютер, на котором вы только что воспроизвели стоп-кадр, и войдите непосредственно в систему и посмотрите, по-прежнему ли заблокировано приложение

Answer 2

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

Самое простое предложение, которое у меня есть, - это проверить использование памяти и использование процессора в диспетчере задач, когда происходит зависание.

Если добавить подробное ведение журнала невозможно, добавьте только достаточное количество записей, чтобы знать, КОГДА приложение зависает.Это может быть просто поток в приложении, который раз в минуту записывает метку времени в файл.Затем вы можете увидеть, есть ли какой-либо шаблон, когда он зависает, например, после того, как пользователь вышел из системы, или когда некоторые из данных, которые вы отслеживаете, изменяются, или в определенное время каждый день, или после того, как он был в сети для определенногоколичество времени.

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

Answer 3

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