Bypassing UI Virtualization: Cross-Platform Windows 11 Automation

Automating legacy Win32 applications is generally straightforward: the elements exist in a static hierarchy and respond reliably to simulated mouse clicks. However, modern Windows 11 applications (built on UWP or WinUI 3) utilize aggressive UI Virtualization.

In virtualized applications, UI elements that are collapsed or off-screen are physically removed from the DOM/Memory tree. To reliably automate workstation provisioning—specifically hardening Windows privacy and telemetry settings—I needed a robust way to interact with the OS without relying on fragile, coordinate-based macros.

I built the engine in both Python (Pywinauto) and C# (FlaUI) to evaluate the ecosystem tooling around Microsoft's UIAutomation (UIA) API.

Overcoming Virtualization Race Conditions

When instructing an automation script to toggle a privacy setting hidden inside a collapsed accordion, naive implementations will crash with an ElementNotFoundException. Because Microsoft aggressively unloads collapsed child elements from memory to preserve resources, the element physically does not exist until the dropdown animation completes.

To solve this, I implemented an architectural pattern utilizing Anchor Elements and Smart Retries.

Rather than relying on brittle Thread.Sleep() statements, the engine actively polls the UIA tree. It evaluates the boolean state of the target's visibility in a tight loop, allowing the execution to proceed the exact millisecond the layout engine finalizes the render.

Programmatic Control vs Simulated Clicks

A common failure point in GUI automation is relying on geometric coordinates or simulated hardware clicks (WM_LBUTTONDOWN). If the screen scales, or a tooltip overlaps the button, the click is swallowed.

To guarantee idempotency—ensuring we only turn privacy telemetry off, never accidentally turning it back on—I bypassed simulated clicks entirely in favor of Microsoft's native Toggle Pattern API.

// C# Implementation using FlaUI
protected void SetToggleState(AutomationElement parent, string autoId, bool newState)
{
    // 1. Locate via AutomationID (ignores localization/translation changes)
    var toggle = parent.FindFirstDescendant(cf => cf.ByAutomationId(autoId)).AsToggleButton();

    // 2. Read the internal OS state
    var currentState = toggle.Patterns.Toggle.Pattern.ToggleState.Value == ToggleState.On;

    // 3. Idempotent action via the programmatic UIA Pattern
    if (currentState != newState)
    {
        toggle.Patterns.Toggle.Pattern.Toggle();
    }
}

Conclusion

Regardless of the language chosen, enterprise-grade test automation requires understanding the underlying mechanics of the target system. By writing the engine to communicate directly with the Windows UIAutomation COM interfaces, the resulting scripts are independent of screen resolution, DPI scaling, and physical cursor location.