Estoy desarrollando una aplicación C # (.Net 3.5, Win Forms) que se ejecuta en un servidor y a la que acceden los usuarios que utilizan el escritorio remoto. La aplicación se congela en ocasiones aparentemente aleatorias en la máquina remota (es decir, todos los componentes de la GUI se vuelven blancos, el administrador de tareas informa que la aplicación no responde), pero no cuando se ejecuta localmente (no soyenterament estoy seguro de eso, pero no pude reproducir el congelamiento en mi máquina).

¿Alguien ha experimentado ese comportamiento en sus aplicaciones a las que se accede de forma remota? ¿Qué estrategia de depuración sugeriría? ¿Debo considerar algo especial al desarrollar aplicaciones Win Forms a las que se accede desde un escritorio remoto?

EDIT: algunas notas sobre la aplicación y la congelación: la aplicación no se recupera de la congelación. Además, la congelación no ocurre (o no sucedió todavía) durante la interacción del usuario, sino entre los inicios de sesión en la máquina remota. La aplicación monitorea un solucionador de CFD, por lo que está haciendo cosas incluso cuando nadie lo está usando.

ACTUALIZAR

e hecho, implementamos un registro detallado, escribiendo cada llamada de función a un archivo con una marca de tiempo. Lamentablemente, los resultados no fueron muy concluyentes. Es decir. la última llamada a la función registrada siempre se devuelve correctamente. Además, todavía se estaban ejecutando algunos temporizadores de fondo, a pesar de que la aplicación parecía congelada (GUI completamente blanca, etc.). Despuésalgunos problema logramos echar un vistazo a un crashdump en WinDBG. En el hilo del sistema encontramos una llamada a OnUserPreferenceChanged () y más arriba a Invoke.WaitOne (). No podemos decir con certeza todavía, pero parece ser el problema descrito enesta artículo. Como solución rápida, instalé un controlador ficticio para el evento mencionado. Informaré cómo funciona esto.

UPDATE 2:

Como resultado, un inicio de sesión en una máquina remota dispara varios eventos OnUserPreferenceChanged (). Entonces, de hecho, era el problema sospechoso. Sin embargo, la solución resultó no ser tan fácil. Hubiera esperado que se lanzara una IllegalCrossReferenceException cada vez que un subproceso en segundo plano intenta modificar un control que se creó en el subproceso del sistema. Este no parece ser el caso. Llamé a mi hilo del sistema y antes de cada acceso a un control, afirmé que el nombre del hilo actual es el nombre del hilo del sistema. En varios lugares esta afirmación falló (por ejemplo, en una devolución de llamada desde un temporizador), pero no se produjo ninguna excepción. Después de usar la delegación adecuada en estos lugares, las heladas se detuvieron. La aplicación se ejecuta sin parar durante algunas semanas y mis usuarios están contentos nuevamente;)