Description

The Snapshot tool intermittently fails during UI Automation tree traversal with:

TypeError: ord() expected a character, but string of length 5 found

The failure appears to originate in comtypes/automation.py while a UIA COM property is being marshaled into a VARIANT. When that exception escapes tree_traversal, the entire Snapshot call fails instead of skipping the problematic element.

Steps to Reproduce

1. Install windows-mcp via uvx windows-mcp (windows-mcp 0.7.0, comtypes 1.4.16)
2. Run on a Windows machine where the desktop contains UI elements with non-ASCII accessibility properties (for example non-English window titles, emoji in notifications, or certain tray items)
3. Call the Snapshot tool
4. Intermittently, tree traversal hits a UIA property that causes comtypes to raise the ord() TypeError

Note: This depends on the visible desktop state and reproduces consistently on our Windows Server CI VM, but may be harder to reproduce on a clean desktop.

Expected Behavior

Snapshot should complete successfully and return desktop state, even if one UI element has problematic COM data.

Actual Behavior

Snapshot fails for the whole window traversal and propagates an unhandled TypeError with the message above.

Root Cause Analysis

This appears to come from comtypes/automation.py handling of a c_char-backed VARIANT value. In the failing case, the underlying value is longer than a single character, so ord() raises before windows-mcp can finish walking the tree.

This is upstream behavior in comtypes, but it surfaces here because Snapshot reads many UIA properties while traversing the desktop tree.

Environment

• OS: Windows Server 2022 / Windows 10
• Python: 3.12.3
• windows-mcp: 0.7.0 (installed via uvx)
• comtypes: 1.4.16
• MCP Client: Custom (ScriptAutomation framework using windows-mcp as a subprocess bridge)

Suggested Fix

Add a defensive guard in src/windows_mcp/tree/service.py inside tree_traversal so the known comtypes ord() TypeError is logged and skipped at both:

• the current node level
• the per-child iteration level

The guard should be narrow enough that unrelated TypeErrors still raise normally.

Additional Context

• This bug was discovered while running automated AI UI test cases through a release pipeline on a Windows VM agent
• The Snapshot tool works correctly most of the time; the failure only occurs when specific UI elements with non-ASCII COM properties happen to be visible
• The same desktop state that causes the crash in one run may not cause it in the next if the problematic UI element is no longer visible (for example a notification dismissed or a window closed)