Windows 11 UI Automation: Reliable way to locate and highlight the Start button from a WinUI 3 app?

Question

Windows 11 UI Automation: Reliable way to locate and highlight the Start button from a WinUI 3 app?

Perry Jones 45

I have a WinUI 3 desktop app that provides guidance-only assistance. The app highlights external Windows controls with a transparent click-through overlay, speaks the instruction, waits for the user to act, then verifies the resulting UI state before advancing.

We recently changed the guidance engine to use UI Automation events as triggers, with post-condition validation and bounded polling as fallback.

The app now builds and launches successfully on a real Windows 11 self-hosted runner. The first real behavior test reaches the printer-guidance flow, but fails at the first step:

Start-button highlight was not observed.

The current Start-button selector is roughly:

The resolver enumerates UIA top-level windows, finds the taskbar window, then searches descendants for the Start control and uses its bounding rectangle for the highlight overlay.

The problem is that on the actual Windows 11 desktop this selector is apparently not resolving the Start button reliably enough for the highlight step to succeed.

What is the most reliable way to locate the Windows 11 Start button through UI Automation from another desktop process?

In particular:

Is Shell_TrayWnd + explorer.exe still the correct UIA root for the Start button on current Windows 11?
Is AutomationId = StartButton reliable across Windows 11 builds?
Should the Start button be located from the desktop root instead of through Shell_TrayWnd?
Are there cases where the Start button appears under a different UIA subtree, process, control type, or view?
Is Raw View preferable to Control View for this control?
Is there a recommended fallback strategy if the automation ID or taskbar hierarchy changes?

The app is guidance-only and does not programmatically click the Start button in production. It only needs to locate the control, obtain its bounding rectangle, highlight it, observe the user action, and then verify that the Start menu opened.

Any guidance on the most stable Windows 11 UIA pattern for resolving the Start button would be appreciated.

0 comments

Answer accepted by question author

Taki Ly (WICLOUD CORPORATION) 4,440 Microsoft External Staff Moderator

Hello @Perry Jones ,

Thanks for the clear write-up. I reproduced this on a Windows 11 desktop (build 26200) and enumerated the taskbar via UI Automation. A few points that may help:

1. It's still under Shell_TrayWnd (explorer.exe), but it is not a direct child. It sits two levels deep: Shell_TrayWnd > Windows.UI.Input.InputSite.WindowClass >Taskbar.TaskbarFrameAutomationPeer > the Start element (AutomationId="StartButton", Name="Start", ControlType.Button, ClassName="ToggleButton"). So, a TreeScope.Children or shallow search will miss it, you likely need TreeScope.Descendants.

2. On a multi-monitor setup I saw two matches for AutomationId="StartButton" , one under Shell_TrayWnd (primary) and one under Shell_SecondaryTrayWnd (secondary). If you search from the desktop root with FindFirst, you may get the button on the wrong monitor, so the overlay ends up off the observed screen. Anchoring to a specific taskbar window instead of the root should avoid this.

Answers to your specific questions

Shell_TrayWnd + explorer.exe: still the correct anchor on current builds.
AutomationId="StartButton": reliable on this build, but nested inside the XAML island, so search descendants.
Search from root: not recommended with multiple monitors (duplicate matches) — anchor to the tray window.
Raw vs Control View: Control View was sufficient here.
Fallback: if the AutomationId changes, Name="Start" + ControlType.Button within Taskbar.TaskbarFrameAutomationPeer works as a secondary match.

Minimal resolver

static AutomationElement ResolveStartButton()
{
    var tray = AutomationElement.RootElement.FindFirst(
        TreeScope.Children,
        new PropertyCondition(AutomationElement.ClassNameProperty, "Shell_TrayWnd"));
    if (tray is null) return null;

    var start = tray.FindFirst(TreeScope.Descendants,
        new PropertyCondition(AutomationElement.AutomationIdProperty, "StartButton"))
        ?? tray.FindFirst(TreeScope.Descendants, new AndCondition(
            new PropertyCondition(AutomationElement.NameProperty, "Start"),
            new PropertyCondition(AutomationElement.ControlTypeProperty, ControlType.Button)));

    if (start is null || start.Current.IsOffscreen) return null;
    var r = start.Current.BoundingRectangle;
    if (r.IsEmpty || r.Width <= 0 || r.Height <= 0) return null;
    return start;
}

Two things that would help me confirm: is the failing runner using more than one display (or a virtual/headless one)? And what exact build is it on (winver)? The taskbar tree has shifted across 22H2/23H2/24H2, so the build matters.

If you found my response helpful or informative, I would greatly appreciate it if you could follow this guide for your confirmation.

Thank you.

Perry Jones 45 Reputation points

2026-08-13T05:54:58.7633333+00:00

Thank you. I ran the requested diagnostics on the same self-hosted interactive runner.

Windows version: Microsoft Windows 11 Home 10.0.26200 Build: 26200

Display configuration: ScreenCount=1 DISPLAY1, Primary=True No Shell_SecondaryTrayWnd was present.

UIA found exactly one primary taskbar and one Start button:

Shell_TrayWnd ControlType.Pane IsOffscreen=False UIA rectangle: [0,1528,2560,72]

Start: Name=Start AutomationId=StartButton ClassName=ToggleButton ControlType.Button IsOffscreen=False UIA rectangle: [782,1528,67,72]

The Start target passed our rectangle/safety validation: RESOLVER_REJECTION=none ValidTargetCount=1

So this does not appear to be a multi-monitor or duplicate-Start issue.

One thing I noticed that may be relevant to your DPI point: System.Windows.Forms.Screen reports the display bounds as [0,0,1707,1067], while UIA is returning taskbar coordinates in a 2560 x 1600 physical-pixel space. That appears to be a 150% scaling difference.

During the actual NMK guidance run, however, the production activeExternalTarget.Locate() still returns null even though this direct UIA diagnostic resolves the Start button successfully.

Given that discrepancy, would you recommend checking the process DPI-awareness context next, or is there another difference between the direct UIA query and an in-process WinUI 3 UIA client that you would investigate first?
Taki Ly (WICLOUD CORPORATION) 4,440 Reputation points Microsoft External Staff Moderator

2026-08-13T07:54:00.1266667+00:00

Hi @Perry Jones ,

I'd separate the two symptoms.

On the null from Locate(), which is the real blocker, DPI is very likely not the cause. I re-ran the same query in a Per-Monitor-V2 process on both STA and MTA threads, and the Start button resolved every time, with the rectangle staying in physical pixels. DPI-awareness changed neither whether FindFirst succeeds nor its coordinate space, so it wouldn't produce a null.

Since your diagnostic resolves it but the in-process path doesn't, I'd look at the code-path differences first. One possibility is a stale or cached tree: if Locate() reuses a RootElement captured at startup or a CacheRequest, note that the taskbar is a XAML island explorer can tear down and recreate, so resolving from a fresh RootElement on each attempt may help. Another is a narrower condition or scope: if it uses TreeScope.Children, a different starting element, or extra predicates, it can miss what the diagnostic finds with Descendants plus AutomationId, so logging the exact condition, scope, and starting element and comparing them would surface this quickly. A third is timing: if it runs off a UIA event before explorer's tree is realized, a single FindFirst can return null, and bounded retry usually covers that.

On the DPI observation, that's a real but separate issue. UIA reports physical pixels while your PMv2 overlay positions in DIPs, which is the 2560×1600 versus 1707×1067 (150%) gap you saw. Even after Locate() succeeds, the highlight will land in the wrong place unless you convert the rectangle to DIPs (divide by the overlay monitor's scale factor, or use GetDpiForWindow). I'd treat this as the next fix rather than the cause of the null.

So, to answer your question directly, I'd investigate the in-process code path (cached root, condition or scope, timing) before the DPI-awareness context. If you can share the exact condition, scope, and starting element that Locate() uses, I'll compare it against the working diagnostic.
Perry Jones 45 Reputation points

2026-08-13T15:24:01.6566667+00:00

thank you
Perry Jones 45 Reputation points

2026-08-13T16:07:53.91+00:00

Thank you. We ran the exact production NMK resolver outside the WinUI shell on the same Windows 11 build 26200 runner, under both STA and MTA.

This narrowed the failure considerably.

The production resolver successfully finds Shell_TrayWnd, enumerates its descendants, and finds the actual Start element:

Name='Start' AutomationId='StartButton' Class='ToggleButton' ControlType=50000 Offscreen=False Usable=True ControlSelectorMatch=True

However, when this production COM UIA path reads the Start element's bounding rectangle, it receives values approximately:

Rect=[2.16E-311, 2.26E-311, 0, 0]

The zero width/height causes our safety conversion to reject the element, so Locate() returns NULL. Repeated attempts produce the same result on both STA and MTA.

This is particularly interesting because our earlier diagnostic using the managed UI Automation API resolves the same Start element with a valid physical-pixel rectangle of approximately 67 x 72.

So the selector, TreeScope.Descendants, taskbar anchor, offscreen check, timing/retry, and STA/MTA distinction no longer appear to be the cause. The difference now appears to be how our production COM UIA interop is marshaling/reading CurrentBoundingRectangle.

Does this look like an incorrect COM interop declaration or marshaling issue for the UIA bounding rectangle? If so, what is the recommended C# interop signature/type for reading IUIAutomationElement.CurrentBoundingRectangle reliably?

That's what I'd send. We have finally reduced this from “Start button highlight doesn't work” to a very specific technical question Microsoft can answer.
Perry Jones 45 Reputation points

2026-08-13T20:28:30.21+00:00

you still with me? we have pressed forward with and made some progress, if we get stuck again, would like to know if we can vcome back here?
Taki Ly (WICLOUD CORPORATION) 4,440 Reputation points Microsoft External Staff Moderator

2026-08-14T02:26:04.47+00:00

Hi @Perry Jones ,

Yes, I'm still with you, and I'm glad to hear you've made real progress.

I think it's worth noting that your original question here, how to reliably locate the Start button through UI Automation, now appears resolved. Your trace confirms the resolver anchors to Shell_TrayWnd, enumerates descendants, and matches the actual Start element (ControlSelectorMatch=True, Offscreen=False, Usable=True). So, the locate/selector problem that started this thread looks answered.

What you've uncovered since then is a different kind of issue. The garbage rectangle values [2.16E-311, …, 0, 0] point to a COM interop marshaling problem in how IUIAutomationElement::CurrentBoundingRectangle is declared and read, and the physical-pixel to DIP scaling is a separate overlay-placement topic. Both are distinct from the original UIA locate question.

Since these are new and quite specific technical questions, it might be cleaner to open a fresh thread for the COM interop and marshaling issue, ideally tagged for Windows API / C++ or .NET interop so the right specialists can pick it up. A focused thread also tends to get a faster and more precise answer, and it keeps the history for each problem clear.

Thank you again for the very thorough diagnostics throughout this one.
Perry Jones 45 Reputation points

2026-08-14T02:29:51.4766667+00:00

yes sir, thank you so much for you devotion and great fixes, we are Testing it now on a clean windows machine.
Taki Ly (WICLOUD CORPORATION) 4,440 Reputation points Microsoft External Staff Moderator

2026-08-14T02:36:15.6333333+00:00

Hi @Perry Jones ,

You’re very welcome.

Please continue testing on the clean Windows machine. If you encounter any further issues related to the COM interop or bounding rectangle handling, please open a new thread with the test results so that specific issue can be reviewed separately.

1 additional answer

Your answer

Perry Jones 45 Reputation points

2026-08-13T05:54:58.7633333+00:00

Thank you. I ran the requested diagnostics on the same self-hosted interactive runner.

Windows version: Microsoft Windows 11 Home 10.0.26200 Build: 26200

Display configuration: ScreenCount=1 DISPLAY1, Primary=True No Shell_SecondaryTrayWnd was present.

UIA found exactly one primary taskbar and one Start button:

Shell_TrayWnd ControlType.Pane IsOffscreen=False UIA rectangle: [0,1528,2560,72]

Start: Name=Start AutomationId=StartButton ClassName=ToggleButton ControlType.Button IsOffscreen=False UIA rectangle: [782,1528,67,72]

The Start target passed our rectangle/safety validation: RESOLVER_REJECTION=none ValidTargetCount=1

So this does not appear to be a multi-monitor or duplicate-Start issue.

One thing I noticed that may be relevant to your DPI point: System.Windows.Forms.Screen reports the display bounds as [0,0,1707,1067], while UIA is returning taskbar coordinates in a 2560 x 1600 physical-pixel space. That appears to be a 150% scaling difference.

During the actual NMK guidance run, however, the production activeExternalTarget.Locate() still returns null even though this direct UIA diagnostic resolves the Start button successfully.

Given that discrepancy, would you recommend checking the process DPI-awareness context next, or is there another difference between the direct UIA query and an in-process WinUI 3 UIA client that you would investigate first?
Perry Jones 45 Reputation points

2026-08-13T15:24:01.6566667+00:00

thank you
Perry Jones 45 Reputation points

2026-08-13T16:07:53.91+00:00

Thank you. We ran the exact production NMK resolver outside the WinUI shell on the same Windows 11 build 26200 runner, under both STA and MTA.

This narrowed the failure considerably.

The production resolver successfully finds Shell_TrayWnd, enumerates its descendants, and finds the actual Start element:

Name='Start' AutomationId='StartButton' Class='ToggleButton' ControlType=50000 Offscreen=False Usable=True ControlSelectorMatch=True

However, when this production COM UIA path reads the Start element's bounding rectangle, it receives values approximately:

Rect=[2.16E-311, 2.26E-311, 0, 0]

The zero width/height causes our safety conversion to reject the element, so Locate() returns NULL. Repeated attempts produce the same result on both STA and MTA.

This is particularly interesting because our earlier diagnostic using the managed UI Automation API resolves the same Start element with a valid physical-pixel rectangle of approximately 67 x 72.

So the selector, TreeScope.Descendants, taskbar anchor, offscreen check, timing/retry, and STA/MTA distinction no longer appear to be the cause. The difference now appears to be how our production COM UIA interop is marshaling/reading CurrentBoundingRectangle.

Does this look like an incorrect COM interop declaration or marshaling issue for the UIA bounding rectangle? If so, what is the recommended C# interop signature/type for reading IUIAutomationElement.CurrentBoundingRectangle reliably?

That's what I'd send. We have finally reduced this from “Start button highlight doesn't work” to a very specific technical question Microsoft can answer.
Perry Jones 45 Reputation points

2026-08-13T20:28:30.21+00:00

you still with me? we have pressed forward with and made some progress, if we get stuck again, would like to know if we can vcome back here?
Taki Ly (WICLOUD CORPORATION) 4,440 Reputation points Microsoft External Staff Moderator

2026-08-14T02:26:04.47+00:00

Hi @Perry Jones ,

Yes, I'm still with you, and I'm glad to hear you've made real progress.

I think it's worth noting that your original question here, how to reliably locate the Start button through UI Automation, now appears resolved. Your trace confirms the resolver anchors to Shell_TrayWnd, enumerates descendants, and matches the actual Start element (ControlSelectorMatch=True, Offscreen=False, Usable=True). So, the locate/selector problem that started this thread looks answered.

What you've uncovered since then is a different kind of issue. The garbage rectangle values [2.16E-311, …, 0, 0] point to a COM interop marshaling problem in how IUIAutomationElement::CurrentBoundingRectangle is declared and read, and the physical-pixel to DIP scaling is a separate overlay-placement topic. Both are distinct from the original UIA locate question.

Since these are new and quite specific technical questions, it might be cleaner to open a fresh thread for the COM interop and marshaling issue, ideally tagged for Windows API / C++ or .NET interop so the right specialists can pick it up. A focused thread also tends to get a faster and more precise answer, and it keeps the history for each problem clear.

Thank you again for the very thorough diagnostics throughout this one.
Perry Jones 45 Reputation points

2026-08-14T02:29:51.4766667+00:00

yes sir, thank you so much for you devotion and great fixes, we are Testing it now on a clean windows machine.
Taki Ly (WICLOUD CORPORATION) 4,440 Reputation points Microsoft External Staff Moderator

2026-08-14T02:36:15.6333333+00:00

Hi @Perry Jones ,

You’re very welcome.

Please continue testing on the clean Windows machine. If you encounter any further issues related to the COM interop or bounding rectangle handling, please open a new thread with the test results so that specific issue can be reviewed separately.

Answer 1

Taki Ly (WICLOUD CORPORATION) 4,440 Microsoft External Staff Moderator

Hi @Perry Jones ,

I'm working on this issue and will try to get back to you soon.

Thank you for your patience.

Perry Jones 45 Reputation points

2026-08-13T03:38:30.84+00:00

I think we got it, If not I'll be back. lol