Problema de foco de roubo

Question

há um tempo atrás algo estranho começou a acontecer, quando pressionar Ctrl ou Alt Gr o foco foi alterado. Eu encontrei vários recursos que não abordam como encontrar o processo real, mas sim como impedir que os aplicativos façam isso, o que não parece ser uma boa solução.

Mais uma vez, pesquisei e não encontrei nada além de hacks para o problema real, isso é não duplicado.

Eu preparei um pequeno aplicativo que detecta quando o foco muda. Tanto quanto eu posso dizer, isso acontece em todos os aplicativos que eu instalei. Abaixo está uma cópia da janela de saída do Visual Studio (com o aplicativo que eu configurei em execução):

Como reproduzi o problema:

• Focalizou manualmente a janela do Bloco de Notas (o log # 1 apareceu).
• Pressionado ctrl, o log relacionado ao segmento e o log # 2 foram exibidos.

Conteúdo da janela de saída:

1 - Window Handle: 723652 | Process: notepad | Window: Untitled - Notepad | Exe file: C:\Windows\system32\notepad.exe The thread 0xafc has exited with code 259 (0x103). 2 - Window Handle: 526994 | Process: notepad | Window: Untitled - Notepad | Exe file: C:\Windows\system32\notepad.exe

O que eu tentei:

• Após o foco ser perdido pressionando ALT + F4 , tentando fechar o processo. [antes de chegar com o aplicativo].
• Usou o Process Explorer para tentar identificar o processo (mas, como não consigo fechá-lo, não há ajuda)

O que acho que está acontecendo:

• Desde quando o problema ocorre, nenhum outro processo está recebendo o foco, ele deve estar atribuindo a ele um valor nulo e sendo reatribuído à janela antiga, mesmo que ele não recupere o foco, mas de acordo com o aplicativo que ele faz ; Ou seja: a borda está em cinza e não consigo interagir com a janela, a menos que eu a clique novamente, embora ela deva ser focalizada novamente.

O que posso fazer para identificar o processo e não apenas impedir que os aplicativos mudem o foco?

    

Answer 1

Eu sei que esta é uma pergunta antiga e você pode não estar mais para reproduzir o comportamento mencionado, mas ainda tentarei responder, pois pode ser útil para alguém com comportamento semelhante.

Verifique se há causas mais comuns

Primeiro, tentei identificar se tenho algum aplicativo óbvio em execução no meu computador que possa estar causando isso. Tais aplicativos seriam:

• Provedores de atalhos do Curstom
• Drivers de teclado ou mouse que podem, no caso, ter teclado ou mouse com botões adicionais. O motivo disso é que muitos deles simulam o uso de determinadas teclas pressionadas quando você clica ou pressiona esses botões adicionais.
• Algum outro software que possa ser usado para simular a entrada do usuário

Agora, se isso não revelar quaisquer causas mais óbvias, eu continuaria com abordagens mais avançadas.

Possível injeção de código

A primeira coisa que gostaria de fazer é verificar se algum código adicional pode ter sido injetado em um aplicativo específico (Notepad.exe no seu caso) verificando quais identificadores DLL estão abertos e comparando-os com a lista DLL que você pode obter da maioria scanners de dependência.

Qualquer identificador de DLL aberto para um arquivo DLL que não é relatado pelo scanner de dependência pode ser a DLL injetada em seu processo.

Então, no caso de encontrar um, eu tentaria descobrir a qual aplicativo ele pertence e, em seguida, com base no que essa aplicação pretende fazer, decida se essa DLL deveria ter sido injetada em meu aplicativo, em primeiro lugar ou não. / p>

No caso, se eu descobrisse que nenhuma DLL deveria ter sido injetada em meu aplicativo desse aplicativo ou se não consegui descobrir a qual aplicativo essa DLL específica pertence, eu a renomeia e, em seguida, reinicia o sistema operacional. se eu não fosse ser capaz de renomeá-lo de dentro do sistema operacional, pois ele seria bloqueado. Eu usaria o CD botable e, em seguida, renomeie esse arquivo.

Após a reinicialização, eu primeiro verificaria se o comportamento ainda é presistente e depois também verificaria todos os aplicativos que possam estar usando essa DLL por conta própria para ver se eles ainda estão funcionando.

Injetar meu próprio código / gancho

Se a primeira abordagem não retornasse nenhum resultado, eu iria injetar meu próprio código no aplicativo afetado para registrar mensagens específicas do Windows que são enviadas ou geradas por esse aplicativo específico.

Essa abordagem exige um bom conhecimento de programação, já que você precisa criar seu próprio programa para isso.
Também é bom que você tenha conhecimento básico avançado das partes internas do aplicativo afetado, para que você saiba quais mensagens precisa ouvir.

Crie um aplicativo de trapping

Eu também tentaria criar meu próprio aplicativo que poderia ser afetado por esse comportamento e, em seguida, tentar rastreá-lo a partir dele. Para fazer isso, eu precisaria ter conhecimentos básicos dos aplicativos internos afetados, a fim de reproduzir com êxito o cenário.

Quando estou pensando nisso, provavelmente faria isso antes de tentar o Code injection approach

Por enquanto, estas são as etapas que vêm à mente. Mas eu posso chegar a algumas ideias adicionais durante o processo também.