A single background process — PAD.BridgeToUIAutomation2.exe from Microsoft Power Automate Desktop — was causing system-wide input freezes, mouse stuttering, keyboard input loss, and audio dropouts on a high-end workstation (i9-14900K, RTX 4090, 96 GB RAM, 4K 120Hz). The root cause: Power Automate's UI Automation bridge subscribes to global accessibility events, which forces every windowed application to generate cross-process callbacks on every repaint. This created a cascading DWM composition stall that affected the entire system. Disabling Power Automate from startup instantly resolved all symptoms.
- CPU: Intel Core i9-14900K (32 logical processors)
- GPU: NVIDIA GeForce RTX 4090 24 GB
- RAM: 96 GB DDR5-6600
- Display: 4K (3840×2160) @ 120 Hz
- OS: Windows 11 Pro 24H2 (Build 26100.7171)
- NVIDIA Driver: 576.88
The symptoms had been present for roughly a year, gradually worsening as the system accumulated more applications:
- Mouse cursor stuttering and jerking — not just within the offending app, but system-wide, including over the desktop and other windows.
- Keyboard input loss — keystrokes during freezes were dropped entirely, not queued.
- Audio dropouts — music would cut out during freezes.
- System beeping — the classic Windows "input buffer overflow" beep (short sine wave bursts) when clicking during a freeze.
- Taskbar clock freezing — while USB-connected devices like Stream Deck continued updating normally.
- Opening long/complex web pages in Chrome or Edge (e.g., a single-page Docsify manual with tens of thousands of DOM nodes).
- Editing or previewing Markdown in JetBrains CLion/IntelliJ.
- Any interaction with Bambu Suite (laser/CNC software) — switching tabs, moving the window, clicking anything.
- Long Claude.ai conversations with streaming responses.
- Firefox was completely unaffected (it doesn't use standard Win32 accessibility APIs the same way Chromium does).
Hover effects within Bambu Suite were instant — the app's message loop was running fine. But any action that triggered a repaint (tab switch, window move, content update) caused a multi-second freeze. This pointed directly at the DWM composition pipeline, not the application itself.
The following were all investigated and ruled out:
| Hypothesis | Test | Result |
|---|---|---|
| GPU driver DPC latency | LatencyMon during freeze | Highest DPC 1.63 ms — within normal range |
| Memory pressure / page faults | Resource Monitor during freeze | 28 GB free, zero hard faults |
| CPU saturation | Task Manager during freeze | Low utilization across all cores |
| Chrome GPU compositor | --disable-gpu-compositing |
Still froze |
| Chrome hardware acceleration | Disabled HA in settings | Still froze (and CPU didn't spike) |
| NVIDIA driver GPU preemption | LatencyMon DPC/ISR analysis | All DPC times under 2 ms even during freeze |
| Display refresh rate | Dropped from 120 Hz to 60 Hz | No change |
| MPO (Multiplane Overlay) | OverlayMinFPS=0 registry key |
No change |
| MPO disabled entirely | OverlayTestMode=5 + reboot |
No change |
| Hardware-accelerated GPU scheduling | Disabled HAGS | No change |
| Chrome ANGLE backend | Tried D3D9, D3D11 WARP | No change |
| Various Chrome flags | --disable-gpu, rasterization flags |
No change |
Note: After resolving the PA issue, a secondary Chromium-specific problem remained — mouse stuttering on heavy pages in Chrome/Edge while other apps (including Bambu Suite) worked fine. This turned out to be the known Windows 11 24H2 DWM/MPO flipping issue, resolved by setting OverlayMinFPS=0:
reg add "HKLM\SOFTWARE\Microsoft\Windows\Dwm" /v OverlayMinFPS /t REG_DWORD /d 0 /f
Restart DWM or reboot to apply. This fix alone did NOT help while PA was running — PA's UIAutomation overhead was the dominant problem masking everything else.
A WPR trace (wpr -start GeneralProfile) captured during a freeze revealed the critical clue in WPA:
dwm.exeaccumulated 52.9 seconds of wait time during the trace.- The Readying Process for DWM was
chrome.exe— meaning DWM was blocked waiting on Chrome's compositor to release a shared resource. - The UI Delays panel showed multiple processes with
MsgCheck Delayin the tens of seconds.
This confirmed: DWM composition was stalling, and every application's repaint was blocked by something in the rendering pipeline.
Bambu Suite (built on wxWidgets + OpenGL, fully synchronous UI thread rendering) turned out to be the perfect diagnostic tool. Unlike Chrome, which partially masks latency through its multi-threaded compositor, Bambu Suite froze immediately and reproducibly on any UI interaction. This made bisecting the cause vastly easier.
After a reboot with a stripped-down startup:
- Bambu Suite launched immediately after boot — worked perfectly.
- Waited for autostart applications to load — started lagging.
- Captured a process snapshot at the moment lag appeared.
- Systematically killed process groups, testing Bambu Suite after each.
The following were cleared as not causing the issue: NZXT CAM, Stream Deck (+ 30 plugins), GPU Tweak III, MSI Afterburner, HWiNFO64, Process Lasso, Start11, NVIDIA Overlay, Snagit, Epic Games Launcher, Discord, Elgato Audio, f.lux, OneDrive, SSHFS-Win Manager, AutoDarkMode, JetBrains Toolbox, Intel Graphics Command Center, and more.
Power Automate Desktop. Specifically, PAD.BridgeToUIAutomation2.exe.
Killing PA's three processes instantly restored Bambu Suite to full responsiveness:
taskkill /f /im "PAD.Console.Host.exe"
taskkill /f /im "PAD.AutomationServer.exe"
taskkill /f /im "PAD.BridgeToUIAutomation2.exe"Windows UI Automation is an accessibility framework. Applications expose their UI elements as "providers," and assistive tools connect as "clients" to listen for changes.
The critical architectural detail: the overhead is on the provider side, not the client side. When any client subscribes to global UI Automation events:
- Every application with a visible window becomes a provider.
- On every repaint, each provider must check if the accessibility tree changed, build event notifications, and send them via cross-process COM calls.
- This happens synchronously on the UI thread of each application.
- The client (PAD) may filter most events, but the provider has already done the work.
PAD.BridgeToUIAutomation2 subscribes to global events across the entire desktop subtree. This means every windowed application in the system — Chrome, CLion, Bambu Suite, explorer, even the clock in the taskbar — pays the cost on every single frame.
DWM (Desktop Window Manager) composites all visible windows. When it needs to composite a frame, it must acquire each window's shared surface. If an application's UI thread is blocked in a UI Automation callback, it holds onto its surface longer, and DWM must wait. At 4K resolution with dozens of windowed applications, these delays cascade into multi-second system-wide freezes.
Running Microsoft's AccEvent tool (from Windows SDK) confirmed the mechanism. Even with minimal events visible in AccEvent's window, Bambu Suite immediately started lagging — because AccEvent itself is a global UI Automation listener, and the mere act of subscribing triggers the same provider-side overhead.
An ETW trace using the Microsoft-Windows-UIAutomationCore provider captured 199,023 events in 34 seconds (~5,850 events/sec). The top event was ID 517 (provider interface calls like IRawElementProviderSimple::get_ProviderOptions, GetPropertyValue, Navigate) with 76,909 occurrences — confirming massive provider-side polling.
Extracting unique PIDs from the trace and resolving them revealed four PA processes among the callers:
14860 = PAD.AutomationServer
49120 = PAD.Designer
50344 = PAD.Console.Host
50584 = PAD.AutomationServer (second instance)
Further testing revealed that Power Automate's impact persists even after killing all PA processes. Applications that were running while PA was active continue to experience lag after PA is terminated.
| Step | Bambu Suite | Chrome (pinokio.co/docs) |
|---|---|---|
| Clean boot, no PA | ✅ Normal | ✅ Normal |
| Launch PA | ❌ Laggy | ❌ Laggy |
| Kill all PA processes | ❌ Still laggy for a while | ❌ Still laggy |
| Restart affected app after PA kill | ✅ Normal | ✅ Normal |
When PA starts, PAD.BridgeToUIAutomation2 registers as a global UI Automation listener. This causes every running application to activate its UIA provider infrastructure — building accessibility trees, registering for change notifications, and setting up cross-process COM channels.
When PA is killed, the global listener is removed, but applications that already activated their provider-side UIA infrastructure don't fully deactivate it. The overhead persists until the application is restarted.
If you accidentally launch PA, killing it is not enough — you need to restart any application that was running while PA was active to fully eliminate the lag. Alternatively, just restart PA-affected apps one by one (or sign out and back in).
This also explains why some users report that "signing out and back in" fixes their lag — it restarts all applications, clearing the poisoned UIA state.
Disable Power Automate Desktop from startup.
Task Manager → Startup → Power Automate Desktop → Disable.
That's it. One toggle. After a year of system-wide stuttering, input loss, audio dropouts, and nearly reinstalling Windows.
Get-Process | ForEach-Object {
try {
if ($_.Modules.ModuleName -contains "UIAutomationCore.dll") {
[PSCustomObject]@{Name=$_.ProcessName; PID=$_.Id; Path=$_.Path}
}
} catch {}
} | Format-Table -AutoSizeNote: most results will be passive providers (normal). Look for processes with "Bridge", "Automation", "Accessibility", or "UIА" in the name — those are likely active clients (listeners).
# Start trace
logman start uia -p "{820A42D8-38C4-465D-B64E-D7D56EA1D612}" 0xFFFFFFFF 0x5 -o C:\uia.etl -ets
# Reproduce the lag, then stop
logman stop uia -ets
# Parse and find top talkers
tracerpt C:\uia.etl -o C:\uia.csv -of CSV
Get-Content C:\uia.csv | ForEach-Object {
($_ -split ",")[9]
} | Sort-Object | Group-Object | Sort-Object Count -Descending | Select-Object Count, Name -First 10Resolve the top hex PIDs:
Get-Process -Id 0x1234 | Select-Object Name, Id, PathAccEvent from Windows SDK (C:\Program Files (x86)\Windows Kits\10\bin\<version>\x64\accevent.exe) shows real-time UI Automation events. Useful for seeing the flood, but be aware it is itself a global listener and will cause the same performance degradation while running.
-
Power Automate Desktop is pre-installed on Windows 11 and enabled in autostart once launched at least once. If you're not actively using it for desktop automation, disable it.
-
UI Automation global listeners are toxic to system responsiveness. The overhead is architectural — it's on every provider (every windowed application), not just the listener. There is no workaround short of removing the listener.
-
Firefox is immune. It doesn't participate in Win32 UI Automation the same way Chromium-based apps do. If you notice that Firefox is fine but Chrome/Edge/Electron apps stutter — suspect a global UIA listener.
-
LatencyMon won't catch this. The stalls happen in regular thread context (kernel mutexes, cross-process COM calls), not in DPC/ISR. LatencyMon only monitors DPC/ISR latency.
-
The symptoms mimic GPU driver issues. Mouse stuttering + DWM stalls naturally leads to investigating NVIDIA drivers, display settings, and GPU scheduling. The actual cause is in a completely different subsystem.
-
Find the dumbest, most sensitive application you have and use it as a canary. Bambu Suite with its synchronous wxWidgets UI was invaluable — it reacted instantly to the problem, unlike Chrome which partially masked it through async compositing.