Stealing focus issue

Question

a while ago something weird started happening, when pressing Ctrl or Alt Gr focus is changed. I've found several resources which don't address how to find the actual process but rather how to block applications from doing so, which doesn't seem like a good solution.

Again, I've actually researched and found nothing but hacks to the actual problem, this is not a duplicate.

I've prepared a small app which detects when focus changes. As far as I can tell, it happens on all applications I have installed. Below is a copy of Visual Studio's output window (with the app I've setup running):

How I reproduced the issue:

• Manually focused the Notepad Window (log #1 showed up).
• Pressed ctrl, both the thread related log and log #2 showed up.

Output Window content:

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

What I've tried:

• After focus being lost pressing ALT + F4, trying to close the process. [before coming up with the app].
• Used Process Explorer to try to identify the process (but since I can't close it, no help at all)

What I think it's happening:

• Since when the issue occurs no other process is receiving the focus, it must be assigning it a null value and re-assigning to the old window, even though it doesn't actually regains focus, but according to the app it does; i.e: the border is greyed out and I can't interact with the window unless I click it again even though it should be focused again.

What can I do in order to identify the process and not just prevent applications from changing focus?

Answer 1

I know this is an old question and you might no longer be albe to reproduce the mentioned behavior but I Will still try to answer as it might come in handy for someone else with similar behavior.

Check for more common causes

First I would try to identify if I have any obvious application running on my computer that might be causing this. Such applications would be:

• Curstom shortcuts providers
• Keyboard or mouse drivers which might in case if having keyboard or mouse with additional buttons. Reason for this is that many of them simulate using of certain key presses when you click or press those additional buttons.
• Some other software which might be used for simulating user input

Now if that would not reveal any more obvious causes i would go and continue with more advanced approaches.

Possible code injection

First thing I would do is try to check if some aditional code might have been injected into specific application (Notepad.exe in your case) by checking which DLL handles are open and comparing them with DLL list that you could get from most dependancy scanners.

Any open DLL handle to a DLL file that is not reported by dependancy scanner might be the injected DLL into your process.

So in case of finding one I would try to figure out to which application it belongs and then based of what that aplication is intended to do decide if that DLL should have been injected into my application in the first place or not.

In case if I would have found out that no DLL should have been injected into my application from that application or if I could not figure out to which application that specific DLL belongs I would go and rename it and then restarting the OS. if I would not be albe to rename it from within the working OS due to it being locked I would use botable CD and then rename that file from there.

After restart I would first check if the behavior is still presistant and later also check all aplications that might be using that DLL on their own to see if they are still working.

Inject my own code / hook

If the first approach would not return any results I would go and inject my own code into affected application in order to log speicifc Windows messages that are sent or generated by that specific application.

This approach requires quote good programming knowlege since you need to wrtie your own program for this.
Also it is good if you have athleast basic knowledge of the affected application internals so that you know which messages you need to listen to.

Create a trap application

I would also try to create my own application which could be affected by this behavior and then try to trace it from it. In order to do this I would need to have basic knoledge of the affected application internals in order to sucsessfully reproduce the scenario.

When I'm thinking about it I would probably do this before trying the Code injection approach

For now theese are the steps that come to mind. But I might come to some additionals ideas during the process aswell.