Forum Discussion
Registry setting to exclude specific processes from UI Automation
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.