Forum Discussion
Registry setting to exclude specific processes from UI Automation
Hi everyone,
I'm dealing with a system-wide UIA blocking issue caused by one problematic application that interferes with my other applications that rely on UI Automation functionality.
One application in my system hangs and frequently blocks UIA, which prevents my other automation tools from working properly. I need a way to exclude this specific process from UIA while keeping UIA enabled for everything else.
What I'm Looking For:
A registry setting to disable UIA for specific processes, similar to how Image File Execution Options works. Something like:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\ProblematicApp.exe
"DisableUIAutomation"=dword:00000001
Does such a feature already exist that I might have missed in the documentation?
Are there any alternative approaches to prevent specific processes from participating in UIA?
Would this be something Microsoft might consider implementing?
This would solve the issue by allowing me to continue using UIA for legitimate automation while preventing one bad actor from blocking the entire system.
Any insights or workarounds would be greatly appreciated!
4 Replies
- wasifali758595Brass Contributor
Currently, Windows does not provide a registry setting to disable UI Automation (UIA) for specific processes, since UIA is a system-wide accessibility framework and one misbehaving app can unfortunately interfere with others. While there isn’t a “DisableUIAutomation” flag like Image File Execution Options, possible workarounds include using the Application Compatibility Toolkit to apply shims, isolating the problematic app in a VM or sandbox, or filtering it out in your own automation logic to avoid hangs. More advanced methods to suspend UIA providers within a target app exist but are unsupported and fragile. If this issue is critical, the best path is to raise it with Microsoft via Developer Support or the Feedback Hub so it can be considered for future implementation.
hi claudiu At present there isn’t a supported registry setting to disable UI Automation (UIA) for a specific process. Windows doesn’t provide a per-process exclusion mechanism similar to Image File Execution Options for UIA — the framework is enabled or disabled system-wide.
A few alternatives you might consider:
Whitelist your automation scope: Limit UIA queries in your own tools to specific processes/windows instead of enumerating everything.
Process isolation: Run the problematic app in a restricted environment (low integrity or AppContainer) to reduce its ability to interfere with system-wide UIA.
Provider-level blocking: If the application uses custom UIA providers, you may be able to block or control their DLL load with AppLocker or WDAC.
Unfortunately, there’s no built-in registry “DisableUIAutomation” flag today. If this is a blocker, I’d strongly recommend submitting feedback via Feedback Hub (Win+F) or the Developer Community so the engineering team can consider adding per-process exclusion in the future.
- claudiuCopper Contributor
Thanks for the suggestions! However, the filtering itself is being blocked by an applicaiton that is in hang state, so we don't have any solution of now. You basically cannot filter and exclude certain UIA elements using process id for example since the UIA query itself communicates with a provider.
I tested the PropertyCondition filtering approach and confirmed that it still hangs when problematic providers are present.
A potential solution could mean that UIA filtering by ProcessId/ProcessName bypasses provider interaction entirely, since any potential communication with a laggy provider implementation can cause system-wide hangs.
This could potentially work at the low level where UIA injects providers into applications, preventing problematic providers from being loaded entirely. This would help screen readers, test frameworks, and enterprise automation tools avoid system-wide blocking from single bad providers.
For example, I have a blocking app that freezes the main UI thread for 15 seconds to simulate a problematic app.
While this app is in hang, you cannot for example query or work with other elements despite filtering.HashSet<string> excludedProcessNames = new HashSet<string>(); excludedProcessNames.Add("BlockingApp"); var excludedPids = Process.GetProcesses() .Where(p => excludedProcessNames.Contains(p.ProcessName, StringComparer.OrdinalIgnoreCase)) .Select(p => p.Id) .ToArray(); Condition[] conditions = excludedPids.Select(pid => new NotCondition(new PropertyCondition(AutomationElement.ProcessIdProperty, pid)) ).ToArray(); var combinedCondition = new AndCondition(conditions); var elements = AutomationElement.RootElement.FindAll(TreeScope.Children, combinedCondition); foreach (AutomationElement element in elements) { Console.WriteLine(element.Current.ProcessId); } Console.ReadKey();You can try below, if doesn’t work, pl raise it in feedback hub
Use Raw Tree Walking (no provider calls)
- TreeWalker.RawViewWalker sometimes lets you bypass full provider interaction.
- It won’t filter by PID natively, but you might reduce hangs since it doesn’t pull all patterns/properties.
Parallel / Timed Queries
- Run your FindAll in a separate thread or process with a timeout.
- If a provider blocks, you can kill/abandon that call and still make progress elsewhere.
- Example: spawn one process per top-level window, skip the ones that hang.
Win32 API instead of UIA for high-level filtering
- Use EnumWindows (user32.dll) to get top-level HWNDs and their owning process IDs.
- Exclude bad processes at that stage.
- Then, selectively attach UIA only to the remaining windows.
- This avoids even touching problematic processes.
Feature request angle
- What you describe (a process exclusion list at provider attach time) is something that could realistically be proposed to Microsoft. It would help not just automation developers but also screen readers and accessibility tools that need resiliency.
- You can raise this via the Windows Accessibility Feedback Hub or the Windows SDK GitHub issues.