Voler le problème principal

il y a quelque temps quelque chose de bizarre a commencé à se produire, lorsque vous appuyez sur Ctrl ou Alt Gr la mise au point est modifiée. J'ai trouvé plusieurs ressources qui n'indiquent pas comment trouver le processus réel mais plutôt comment empêcher les applications de le faire, ce qui ne semble pas être une bonne solution.

Encore une fois, j'ai effectivement recherché et trouvé rien d'autre que des hacks au problème actuel, c'est ne pas un doublon.

J'ai préparé une petite application qui détecte les changements de focus. Autant que je sache, cela se produit dans toutes les applications que j'ai installées. Vous trouverez ci-dessous une copie de la fenêtre de sortie de Visual Studio (avec l'application exécutée que j'ai configurée):

Comment j'ai reproduit le problème:

• Concentrez manuellement la fenêtre du bloc-notes (le journal n ° 1 est apparu).
• Appuyez sur ctrl, le journal relatif au thread et le journal n ° 2 sont apparus.

Contenu de la fenêtre de sortie:

1 - Poignée de fenêtre: 723652 | Processus: bloc-notes | Fenêtre: Sans titre - Bloc-notes | Fichier exe: c: \ windows \ system32 \ notepad.exe   Le thread 0xafc s'est terminé avec le code 259 (0x103).   2 - Poignée de fenêtre: 526994 | Processus: bloc-notes | Fenêtre: Sans titre - Bloc-notes | Fichier exe: c: \ windows \ system32 \ notepad.exe

Ce que j'ai essayé

• Après avoir perdu la mise au point, appuyez sur ALT + F4 , essayant de fermer le processus. [avant de venir avec l'application].
• Utilisé Process Explorer pour essayer d'identifier le processus (mais comme je ne peux pas le fermer, aucune aide du tout)

Ce que je pense que ça se passe:

• Étant donné que lorsque le problème se produit, aucun autre processus ne reçoit le focus, il doit lui attribuer une valeur nulle et le réaffecter à l'ancienne fenêtre, même s'il ne reprend pas le focus, mais en fonction de l'application, il le fait; c'est-à-dire que la bordure est grisée et que je ne peux pas interagir avec la fenêtre à moins de cliquer à nouveau dessus, même si elle doit être à nouveau focalisée.

Que puis-je faire pour identifier le processus et ne pas simplement empêcher les applications de changer de focus?

Je sais que c’est une vieille question et que vous ne pourrez peut-être plus reproduire le comportement mentionné, mais je tenterai quand même de répondre car cela pourrait être utile pour une autre personne ayant un comportement similaire.

Vérifier les causes les plus courantes

J'essayais tout d'abord de déterminer si une application évidente s'exécutant sur mon ordinateur pourrait en être la cause. Ces applications seraient:

• Fournisseurs de raccourcis personnalisés
• Pilotes de clavier ou de souris pouvant éventuellement être utilisés avec des boutons supplémentaires. La raison en est que beaucoup d'entre eux simulent l'utilisation de certaines touches lorsque vous cliquez ou appuyez sur ces boutons supplémentaires.
• Certains autres logiciels pouvant être utilisés pour simuler une saisie utilisateur

Maintenant, si cela ne révélait aucune cause plus évidente, je continuerais avec des approches plus avancées.

Injection de code possible

La première chose à faire est de vérifier si du code supplémentaire a peut-être été injecté dans une application spécifique (Notepad.exe dans votre cas) en vérifiant les descripteurs de DLL ouverts et en les comparant à une liste de DLL pouvant être obtenue de la plupart des analyseurs de dépendances.

Tout DLL ouvert dans un fichier DLL qui n'est pas signalé par l'analyseur de dépendance peut être la DLL injectée dans votre processus.

Donc, au cas où j'en trouverais un, j'essaierais de déterminer à quelle application il appartient et ensuite, en fonction de ce que cette application est censée faire, décide si cette DLL aurait dû être injectée dans mon application ou non.

Dans le cas où j'aurais découvert qu'aucune DLL n'aurait dû être injectée dans mon application à partir de cette application ou si je ne pouvais pas savoir à quelle application appartient cette DLL spécifique, je l'aurais renommé puis redémarré le système d'exploitation. si je ne pouvais pas le renommer depuis le système d'exploitation en raison de son verrouillage, j'utiliserais un CD botable, puis renommerais ce fichier à partir de là.

Après le redémarrage, je voudrais d’abord vérifier si le comportement est toujours persistant et, plus tard, vérifier également toutes les applications pouvant utiliser cette DLL par elles-mêmes pour voir si elles fonctionnent toujours.

Injecter mon propre code / hook

Si la première approche ne donnait aucun résultat, j'injecterais mon propre code dans l'application concernée afin de consigner les messages Windows spécifiques envoyés ou générés par cette application spécifique.

Cette approche nécessite de citer de bonnes connaissances en programmation, car vous devez écrire votre propre programme à cet effet.
En outre, il est bon que vous possédiez une connaissance de base des ressources internes de l’application touchée afin que vous sachiez quels messages vous devez écouter.

Créer une application de piège

J'essayerais également de créer ma propre application qui pourrait être affectée par ce comportement, puis d'essayer de la suivre. Pour ce faire, je devrais connaître les bases internes des applications concernées afin de reproduire le scénario avec succès.

Quand j'y pense, je le ferais probablement avant d'essayer le Code injection approach

Pour l'instant, ce sont les étapes qui me viennent à l'esprit. Mais je pourrais aussi venir à quelques ajouts idées au cours du processus.