Estou desenvolvendo um aplicativo C # (.Net 3.5, Win Forms) que é executado em um servidor e é acessado por usuários usando a área de trabalho remota. O aplicativo fica congelando em ocasiões aparentemente aleatórias na máquina remota (ou seja, todos os componentes da GUI ficam brancos, o gerenciador de tarefas informa que o aplicativo não está respondendo), mas não quando executado localmente (não estouinteiramente tenho certeza disso, mas não consegui reproduzir o congelamento na minha máquina).

Alguém já experimentou esse comportamento em seus aplicativos acessados remotamente? Que estratégia de depuração você sugeriria? Preciso considerar algo especial ao desenvolver aplicativos Win Forms que são acessados pela área de trabalho remota?

EDIT: algumas notas sobre o aplicativo e o congelamento: O aplicativo não se recupera do congelamento. Além disso, o congelamento não ocorre (ou ainda não ocorreu) durante a interação do usuário, mas entre os logins na máquina remota. O aplicativo monitora um solucionador de CFD, por isso está fazendo as coisas mesmo quando ninguém o está usando.

ATUALIZAR:

Nós implementamos o log detalhado, gravando todas as chamadas de função em um arquivo com um carimbo de data / hora. Infelizmente, os resultados não foram muito conclusivos. I.e. a última chamada de função registrada sempre retornava corretamente. Além disso, ainda havia alguns temporizadores de segundo plano em execução, embora o aplicativo parecesse frozne (a GUI completamente branca etc.). Depois dealgum problema conseguimos dar uma olhada em um crashdump no WinDBG. No encadeamento do sistema, encontramos uma chamada para OnUserPreferenceChanged () e depois até Invoke.WaitOne (). Ainda não podemos ter certeza, mas parece ser o problema descrito emestes artigos. Como solução rápida, instalei um manipulador fictício no evento mencionado. Vou relatar como isso funciona.

ATUALIZAÇÃO 2:

Como se vê, um Logon em uma máquina remota dispara vários eventos OnUserPreferenceChanged (). Portanto, era de fato a questão suspeita. A correção acabou não sendo tão fácil. Eu esperava que um IllegalCrossReferenceException fosse lançado toda vez que um thread em segundo plano tentasse modificar um controle criado no thread do sistema. Este não parece ser o caso. Chamei meu segmento de sistema e, antes de cada acesso a um controle, afirmei que o nome atual do segmento é o nome do segmento do sistema. Em vários lugares, essa afirmação falhou (por exemplo, em um retorno de chamada de um timer), mas nenhuma exceção foi lançada. Depois de usar a delegação adequada nesses locais, os congelamentos foram interrompidos. O aplicativo é executado sem parar há algumas semanas e meus usuários estão felizes novamente;)