O Windows Vista e o novo implemento verificam a a capacidade de resposta dos aplicativos baseados na interface do usuário por padrão .
Isso pode levar um aplicativo a ser rotulado como "Não está respondendo" enquanto estiver em primeiro plano (barra de tarefas) ou quando sua janela receber o foco (diálogo).
Quando o aplicativo não está respondendo e o SO pode inferir que a falha está relacionada a uma exceção em um módulo filho, do qual o próprio aplicativo não sabe, o Windows sabe que o aplicativo não pode exibir sua própria mensagem de erro, gravar no eventlog do sistema e criar um relatório de falha, o Windows exibe uma caixa de diálogo indicando que o processo "Parou de funcionar". Isso é um pouco diferente de uma falha de aplicativo, porque a pilha do executável principal não caiu sozinha; no entanto, geralmente está aguardando uma resposta do módulo filho que nunca virá. O log de eventos geralmente contém informações sobre a exceção da criança.
Um aplicativo é considerado não responsivo quando a API do Windows não consegue detectar que a janela da interface do usuário entrou em um local onde o usuário pode manipulá-lo em algum momento. Em C #, você pode consultar o status do Windows para verificar sua capacidade de resposta com a chamada Process.Responding()
. Este método retorna false, (ou gerar uma exceção se o MainWindowHandle não existe) ou verdadeiro se a janela estiver em status Ocioso e estiver aguardando entrada.
Existem casos em que um programa não-responsivo está realmente fazendo muito trabalho, exatamente como deveria, então uma mensagem que não responde nem sempre é indicativa de falha (apenas um código ruim) ). A janela da área de trabalho pode eventualmente se tornar responsiva. Um diálogo "Stopped Working" , no entanto, geralmente indica uma falha permanente, e o aplicativo precisará ser abortado. Isso não é 100% verdadeiro o tempo todo, mas na maioria das vezes, é o caso.
A natureza dessas mensagens e seus problemas associados são inseparáveis das técnicas de programação usadas na execução de trabalhos e da integração com componentes e serviços externos, como APIs externas. A Microsoft lançou algumas boas informações sobre o que fazer e não fazer, para desenvolver um design de interface do usuário responsivo . Estratégias de encadeamentos ruins, acesso síncrono e assíncrono a componentes externos e contenção de recursos (bloqueios / bloqueios) são as causas mais comuns.
Para usuários finais que sofrem de problemas com aplicativos que "Pararam de funcionar", a Microsoft recomenda um caminho de solução de problemas abrangente, encontrado aqui: link O driver da placa de vídeo é geralmente responsável por problemas com o loop Draw () e pode, portanto, causar falta de resposta, assim como as APIs do sistema. verificar a instalação do driver e que o próprio SO é integral (com SFC.exe) são etapas que valem a pena determinar se o aplicativo se integra ao sistema com firmeza, como esperado. Hardware como a Placa de Vídeo e a RAM também devem estar funcionando corretamente.
Espero que isso ajude