Window/UI Automation tools return empty results on Windows ARM64 (x86-emulated Python)

[mlindgren]

Summary

This issue description was created with the assistance of Claude. Diagnostic info and hypothesis were collected/created by Claude.

On a Windows ARM64 device, the Snapshot, App (switch mode), and related UI Automation tools all return empty results — no windows enumerated, no active window found, App switch returns "Application not found" — even when multiple applications are visibly running. Screenshot capture and shell-based tools (PowerShell, Process, FileSystem) work correctly.

Environment

windows-mcp version	0.4.0
Claude Desktop version	MSIX-packaged build (log path: AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\)
Host OS	Windows 11, ARM64 (aarch64) device
Python (MCP server)	CPython 3.13.14 x86_64 (emulated via uv managed install: AppData\Roaming\uv\python\cpython-3.13.14-windows-x86_64-none)
Python (system)	CPython 3.14.0 ARM64 native (AppData\Local\Programs\Python\Python314-arm64)
uv version	WinGet install (astral-sh.uv_Microsoft.Winget.Source_8wekyb3d8bbwe)

Note: uv defaults to x86_64 Python on Windows ARM64 for wheel-compatibility reasons. No native windows-aarch64 managed Python is available from uv at this time.

Steps to Reproduce

1. Install windows-mcp on a Windows ARM64 device via Claude Desktop extensions.
2. Install CPython 3.13.x x86_64 via uv. I had to do this manually. No native ARM64 managed Python is available.
3. Confirm the server starts and connects successfully (MCP handshake completes, tools/list succeeds).
4. Call any window-enumeration tool: Snapshot, App (switch mode), etc.

Observed Behavior

• Snapshot returns: Opened Windows: No windows found / Focused Window: No active window found / List of Interactive Elements: No interactive elements
• App with mode=switch returns: Application <name> not found.
• The cache log spams: Retrieved 0 cached children (newly built) for every enumeration attempt
• Desktop State capture takes ~6.6 seconds (significant stall) before returning empty
• Repeated COM errors in the watchdog: Focus callback COM error: (-2147220991, 'An event was unable to invoke any of the subscribers', (None, None, None, 0, None))

Expected Behavior

Window enumeration tools should return the list of open top-level windows and support switching focus to them by name.

Confirmed Working

• Screenshot — returns a correct desktop capture (pillow/DXGI path, not UIA)
• PowerShell — full shell access works
• Process (list/kill) — works correctly
• Snapshot screenshot component — image captures correctly; only the UI tree/window enumeration is broken

Diagnostic: UIA Works from Same Process via .NET

To rule out sandbox isolation and process integrity as causes, the following was run via the PowerShell tool (same MCP server process, same x86-emulated context):

[System.Runtime.InteropServices.RuntimeInformation]::ProcessArchitecture
# Output: X64

Add-Type -AssemblyName UIAutomationClient
$root = [System.Windows.Automation.AutomationElement]::RootElement
$w = $root.FindAll(
    [System.Windows.Automation.TreeScope]::Children,
    [System.Windows.Automation.Condition]::TrueCondition
)
$w.Count  # Output: 16
$w | ForEach-Object { $_.Current.Name }
# Output: Shell Handwriting Canvas | Claude | Issues · CursorTouch/Windows-MCP ... - Work - Microsoft Edge | ... - Personal - Microsoft Edge | Signal | ...

The .NET UIA client enumerates all 16 top-level windows correctly from the same emulated x86 process. This rules out:

• Process sandbox / AppContainer isolation (token is Medium Mandatory Level, no AppContainer SID)
• UIPI blocking
• x86-on-ARM64 emulation as a blanket cause (since .NET UIA works fine emulated)

The issue is therefore specific to how windows-mcp's own UIA/comtypes layer walks the window tree — the comtypes/uiautomation path returns nothing where System.Windows.Automation succeeds.

Hypothesis

The cache_utils log (Retrieved 0 cached children (newly built)) suggests the tree walker is successfully initiating enumeration but getting no children back from whatever UIA call it makes at the root level. The COM subscriber error (-2147220991) on the watchdog's focus event hook may be related — if the event registration is failing, it could affect tree state or initialization in a way that causes enumeration to return empty.

Possible specific causes:

• The uiautomation or comtypes UIA tree-walk call used by windows-mcp may be using a different UIA scope, condition, or root element than AutomationElement.RootElement.FindAll(Children, True), causing it to miss top-level windows.
• The COM CoInitialize apartment model (CoInitializeEx(None, 2) = MTA, seen in logs) may conflict with how the UIA event hooks are registered, leading to the subscriber errors and potentially affecting enumeration.

Workaround

None currently. The PowerShell tool can be used as a fallback to drive .NET UIA directly, but this requires writing inline PowerShell for every UI operation and defeats the purpose of the dedicated tools.

[Jeomon]

Thanks for raising this problem, I will look into it.
Mean while can you please try out the latest version of windows-mcp