Explorer.exe randomly taking focus - Windows 11

One potential source of Windows 11 File Explorer focus stealing is Bonjour (published by Apple Inc.), which installs a Windows service with the service name and display name "Bonjour Service" that is set to automatically run at device startup. I stopped this service and changed its Startup Type from Automatic to Manual to prevent it from running by default, but it's possible that this effectively prevents it from fulfilling its purpose (which is an acceptable tradeoff for me), and I recognize that this is only reacting to the symptoms and doesn't identify the root cause. I had Bonjour version 3.0.0.10 installed (bundled with FileMaker Pro 16 which is published by FileMaker, Inc.).

I determined this cause in an indirect way without having to install additional software or provision an unbounded amount of logging storage space by following the steps in "Test your Windows app for Windows 10 in S mode" to apply its audit mode policy to the system (thankfully there wasn't an existing SIPolicy.p7b). After restarting the system, I opened Event Viewer to the mentioned "Application and Services Logs\Microsoft\Windows\CodeIntegrity\Operational" log and kept it open while waiting for the focus stealing to happen. Once it triggered, I refreshed the event log to see what uncertified software recently tried to run --- this event log is set to only retain the most recent 1 MB of events (which amounted to about 1,300 events for me), so if you need more time to study the log, be sure to export a copy. (Modern Windows apps that are actually compliant with Microsoft Store policies should not be able to steal focus. Although the certification process is looser than that ideal scenario, S mode is a good starting point towards approaching the stricter Windows Phone and Xbox console computing experiences.)

In my case, Bonjour doesn't seem to be the only source of focus stealing (but I estimate it is responsible for about 90% of them) --- something in my organization's Group Policy refresh also seems to trigger focus stealing. I haven't investigated this area yet, but I determined this by studying recently-run scheduled tasks in the "Application and Services Logs\Microsoft\Windows\TaskScheduler\Operational" log.

To conveniently open Event Viewer to the specified logs in subsequent logon sessions, you can run the following commands (check the opened window afterwards; there seem to be scenarios where the requested log will not actually be opened):

• "mmc.exe" "eventvwr.msc" /c:"Microsoft-Windows-CodeIntegrity/Operational"
• "mmc.exe" "eventvwr.msc" /c:"Microsoft-Windows-TaskScheduler/Operational"

same problem. when playing vlc the window switches to explorer

when playing vlc the window switches to explorer

Without deeper analysis, the only recommendation I have is to make sure you're using VLC UWP, which is the edition that is compliant with Microsoft Store policies (aside from its Windows 8 package, which targets an out-of-support operating system and would not have been accepted for publication today, breaching policy 10.1.4). This will help with accountability in diagnosing application behavior.

Did you miss the 100s of reports of explorer stealing focus from other apps? This is an explorer.exe problem, not a VLC problem... please help to fix the actual problem.

It's easy to blame Windows because the upgrade the most recent perceived change to your system. As users, we need to hold first-party and third-party developers accountable, which is difficult to do when "This program is doing unsupported things, but their customers don't know or care."

The easiest thing we can do is look for applications and installers that adhere to the modern Windows app model (.appx and .msix, not loose .exe or .msi) and don't subvert it with capabilities like runFullTrust, which is disclosed by the phrasing "Uses all system resources" or formerly, "Access all your files, peripheral devices, apps, programs and registry". S mode compatibility is a good start, but not as strong as it ought to be because runFullTrust products are still allowed --- Windows made its success on that legacy app model, so it's difficult to turn it away.

In my case, I used S mode compatibility testing to identify a program (Bonjour) that can do anything it wants (loose .exe is the equivalent of runFullTrust) and was responsible for most of the symptoms. The last known part is in my organization's Group Policy processing, which does things that are not S mode compliant, but the symptoms are now infrequent enough that I'm willing to accept it and move on to more productive endeavors.