automation.VARIANT._set_value assumes c_char.value has length 1

[douglasnovy]

Environment data

• OS: Windows Server 2022 / Windows 10
• Python version: 3.13.12
• comtypes version: 1.4.16
• COM type libraries involved in the real-world trigger: UI Automation (IUIAutomation)

Code snippet

This synthetic reproducer exercises the exact failing branch in comtypes/automation.py:

from ctypes import c_char
from comtypes.automation import VARIANT


class WeirdChar(c_char):
    @property
    def value(self):
        return b"hello"


VARIANT(WeirdChar(b"h"))

Traceback on comtypes 1.4.16:

Traceback (most recent call last):
  File "<stdin>", line 10, in <module>
  File "...\site-packages\comtypes\automation.py", line 199, in __init__
    self.value = args[0]
  File "...\site-packages\comtypes\automation.py", line 347, in _set_value
    self._.VT_UI1 = ord(value.value)
TypeError: ord() expected a character, but string of length 5 found

The current branch is:

elif isinstance(value, c_char):
    self._.VT_UI1 = ord(value.value)
    self.vt = VT_UI1

Situation reproducing steps

1. Import VARIANT from comtypes.automation
2. Pass a c_char instance whose .value is longer than one byte to VARIANT(...)
3. automation.py calls ord(value.value)
4. ord() raises TypeError because the input length is greater than 1

In a real application, I hit this through COM/UI Automation property marshaling. During tree traversal, a COM property eventually reached VARIANT._set_value as a c_char whose .value was unexpectedly multi-byte, which caused the same traceback above.

Expected behavior

comtypes should not assume that c_char.value is always length 1 before calling ord().

At minimum, this branch should validate the length explicitly and raise a more direct error with context. If treating the underlying data as a byte is the intended behavior, raw[0] after validation would also avoid the current ord() failure path.

Actual behavior

comtypes raises a generic TypeError from ord():

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

When this happens in COM-driven code, the error bubbles out of a deep marshaling path and is difficult for downstream callers to diagnose or handle precisely.

Additional context

I do not yet have a minimal pure-COM reproducer outside the larger application, so the code snippet above is synthetic. I am filing this because it demonstrates the exact failing branch and matches the traceback seen in the real COM/UI Automation scenario.

[moi15moi]

@junkmd Please confirm what I say, but I believe it's normal. You should use c_char_p for a string. c_char is just for one character.

[junkmd]

@douglasnovy

Thank you for your report.

I am very interested in understanding how this issue occurs in a real-world scenario.

As @moi15moi mentioned, c_char is designed to hold just one character.
I initially suspected that c_char.value might be reading from a memory address up to a null terminator(similar to c_char_p), but my tests show that it consistently returns only the first character, regardless of the subsequent memory content:

Python 3.13.9 (main, Oct 14 2025, 21:22:32) [MSC v.1944 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
Ctrl click to launch VS Code Native REPL
>>> from ctypes import c_char, POINTER, cast, create_string_buffer, addressof
>>> c_char(b"a")
c_char(b'a')
>>> c_char(b"ng")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
    c_char(b"ng")
    ~~~~~~^^^^^^^
TypeError: one character bytes, bytearray or integer expected
>>> raw_null_terminated = b"hello\0"
>>> buffer = create_string_buffer(raw_null_terminated)
>>> addr = addressof(buffer)       
>>> weird = c_char.from_address(addr)
>>> weird.value
b'h'

Could you provide more details? Specifically:

1. Is a subclass of c_char (like the WeirdChar in your snippet) actually being passed to the VARIANT constructor or its .value property?
2. Or is there a specific condition where a standard c_char instance truly returns a multi-byte string from its .value property?
3. Could you share the full traceback or the specific COM property/method in UI Automation that triggered this?

If we can identify whether this is caused by a custom subclass or a specific behavior of ctypes in a certain marshaling context, it will help us decide if we should implement a more robust length check or change how we access the underlying byte.

[douglasnovy]

Thanks, this is very helpful, and I agree with the pushback on my synthetic example.

The WeirdChar snippet was only meant to hit the exact failing branch in automation.py; it does not prove that a normal ctypes.c_char instance can return a multi-byte .value in ordinary use. That part is on me, and I want to clarify the real-world context more carefully.

Real downstream scenario

The real failure was observed while using UI Automation from a downstream project, Windows-MCP, during desktop tree traversal / snapshot capture.

Relevant downstream mitigation PR:

• CursorTouch/Windows-MCP#148

The downstream stack is roughly:

Snapshot
-> desktop state capture
-> UI tree traversal
-> IUIAutomationElement.BuildUpdatedCache(...)
-> cached/current property access
-> comtypes marshaling
-> automation.VARIANT._set_value
-> ord(value.value) failure

The runtime error seen from downstream was:

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

What I have ruled out so far

At least from inspecting the downstream code path, I do not currently see evidence that the downstream project:

• manually constructs a c_char,
• manually constructs a subclass of c_char,
• or directly calls VARIANT(...) with one of those objects.

The relevant wrappers are mostly thin pass-through calls around COM/UIA APIs, e.g.:

• self.Element.GetCachedPropertyValue(propertyId)
• self.Element.GetCurrentPropertyValue(propertyId)
• self.Element.BuildUpdatedCache(cacheRequest)

So I do not currently have evidence of explicit user-code misuse like:

• "we built a weird c_char subclass and passed it into VARIANT ourselves."

What the downstream code does do

It requests a fairly broad cache of UIA properties/patterns while traversing a live desktop tree. That property set includes several legacy accessibility properties, notably:

• LegacyIAccessibleRoleProperty
• LegacyIAccessibleValueProperty
• LegacyIAccessibleDefaultActionProperty
• LegacyIAccessibleStateProperty

So the downstream project is definitely exercising some messier corners of UI Automation / MSAA interop.

My current best guess is:

1. some UI Automation / MSAA provider returns an unexpected value shape,
2. that value reaches comtypes during marshaling,
3. and the c_char branch in automation.VARIANT._set_value is where it finally detonates.

Answers to your questions

1. Is a c_char subclass actually being passed in the real scenario?

Not that I know of.

The subclass in the issue body was synthetic only. I have not found downstream code explicitly constructing or passing a c_char subclass.

2. Do I have evidence that a normal c_char instance can return multi-byte .value?

No, not yet.

At this point I agree that I have not demonstrated that. The issue is really about a real-world traceback reaching this branch, not yet about a proven minimal ctypes.c_char behavior change.

3. Do I know the exact UI Automation property / method that triggered it?

Not precisely yet.

What I know:

• it happened during UI Automation tree traversal on Windows,
• the downstream project was using BuildUpdatedCache(...) and cached property access,
• the likely suspects are among the legacy accessibility properties listed above,
• but I have not yet isolated the exact property id or provider.

Why I still thought the comtypes branch was worth reporting

Even if the upstream cause turns out to be a buggy UIA/MSAA provider or a downstream traversal choice, this branch in automation.py still seems fairly brittle:

elif isinstance(value, c_char):
    self._.VT_UI1 = ord(value.value)
    self.vt = VT_UI1

If value.value is not length 1 for any reason, the resulting TypeError is pretty opaque once it bubbles out of a deep COM path.

So even if the final conclusion is "not a comtypes bug," it still felt worth asking whether:

• a length check,
• a more explicit error,
• or a different byte extraction path

would make this failure mode easier to diagnose.

What I can do next

The most useful next step on my side is probably one of:

1. isolate a smaller repro using raw IUIAutomation + comtypes, without the downstream project, or
2. instrument the downstream traversal to identify the exact property / provider that triggers the failure.

Right now I have:

• a real downstream failure,
• a confirmed landing point in this branch,
• but not yet the exact COM property/provider smoking gun.

So at the moment I'd describe this as:

• confirmed real-world failure path
• unconfirmed root-cause ownership

I'm happy to follow up with more evidence once I isolate the property/provider. Right now I have the smoke, the alarm, and a desktop accessibility stack that appears to have swallowed a small bag of gremlins.

[junkmd]

@douglasnovy

Thank you for your response.

• isolate a smaller repro using raw IUIAutomation + comtypes, without the downstream project

• instrument the downstream traversal to identify the exact property / provider that triggers the failure

These details will be very useful.
Please proceed with the next steps.

[junkmd]

I can provide the exact consumer stress harness and JSON run artifact as an attachment in a follow-up comment.

Please do so.

[douglasnovy]

Here's where we landed after a fairly thorough investigation. Apologies for the earlier noise — wanted to make sure this follow-up actually earns its keep.

What we built and ran

We wrote several probes at different layers of the stack. All results below are on comtypes 1.4.16, windows-mcp 0.7.0, Python 3.14.3, Windows 10.

1. Raw IUIAutomation + comtypes (no downstream project)

We used comtypes.client.GetModule("UIAutomationCore.dll") directly to walk the live desktop tree with RawViewWalker, reading 33 UIA properties per node (the same set windows-mcp requests, including all four LegacyIAccessible* properties). We monkey-patched VARIANT.value's setter to intercept every c_char instance and log anomalies.

Results across multiple runs:

Run	Nodes visited	Properties read	c_char calls intercepted	ord() TypeError
Desktop only	2,500	~82,500	0	No
Desktop + Notepad	2,500	~82,500	0	No
Desktop + Notepad + Unicode-titled window	1,500	~49,500	0	No

The c_char branch in _set_value was never reached during any of these traversals. Zero calls, not "called but didn't fail" — genuinely zero.

2. windows-mcp Desktop.get_state() loop

We also ran windows-mcp's actual Desktop.get_state() (the real consumer path) in a loop with the same VARIANT.value instrumentation:

Version	Rounds	Completed	c_char calls	Failure
windows-mcp 0.7.0 (pre-fix)	25	24	0	1 non-ord() failure
windows-mcp from GitHub main (post-fix)	25	25	0	None
windows-mcp 0.7.0 (10-round rerun)	10	10	0	None

Again: c_char_calls was always 0.

3. UIA property stability matrix

We profiled 3,500 nodes × 10 properties = 35,000 individual GetCurrentPropertyValue calls. The only failures observed were COMError on stale/detached nodes at depth 20 — never TypeError, never involving c_char.

What this tells us

The c_char branch in VARIANT._set_value is not being exercised during normal UIA property access on our test machines. Whatever triggered the original ord() crash in production involved desktop state, an accessibility provider, or a marshaling path we haven't been able to recreate on demand.

The deterministic repro in the issue body (the WeirdChar subclass) remains solid — it proves the branch is fragile. But we can't currently demonstrate a standard c_char instance arriving with multi-byte .value during real UIA traversal.

What we think happened

Our best hypothesis is that a specific MSAA/UIA provider (possibly a third-party accessibility tool, a browser extension, or a particular app's custom automation peer) returned a value that reached the c_char branch with unexpected content. The failure was observed during windows-mcp Snapshot on a machine with a richer desktop state than our current test environment.

Scripts (all available on request)

• comtypes_root_cause_hunt.py — Raw IUIAutomation + comtypes tree walker with VARIANT.value setter instrumentation + optional windows-mcp snapshot rounds + delta-debugging property minimizer
• uia_property_stability_matrix.py — BFS property profiler: failure counts by property, exception type, and provider
• windows_mcp_consumer_repro.py — windows-mcp Desktop.get_state() stress loop with per-round subprocess isolation and timeout

Happy to share any of these or their JSON artifacts if useful. Will also follow up if we catch the failure in the wild again — the instrumentation is in place to capture the exact property ID and provider when it surfaces.

[junkmd]

In my experience, I know that this kind of reproduction is difficult.

Setting aside the effort to make it an automated or environment-independent test for a moment — unless you were actually using tkinter — could you provide a minimal repro using the actual application (or your "machine with a richer desktop state") where you encountered the error?

While we might need formal testing later, We first want to confirm the real-world situation where this occurred.

[douglasnovy]

Final best-effort summary from my side.

I am done chasing the live repro, so I want to leave behind everything I was able to establish that seems relevant to this issue.

What I know happened in the real world

• I saw this twice on March 25, 2026 on a Windows Server CI VM.
• The application was a real notepad.exe window opened on a real text file.
• The automation backend was windows-mcp, which uses comtypes underneath for Windows UI Automation.
• The failing action was a normal "activate/focus/maximize the Notepad window and verify it is ready for text entry" step.
• The surfaced error both times was:

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

• The exception came back through the real UI automation path, not through a fabricated unit test:

... -> windows_mcp_backend.py -> _rpc
WindowsMCPBackendError: ord() expected a character, but string of length 5 found
...
AIModelStepRunFailure: ord() expected a character, but string of length 5 found
...
AIUIExecutionError: ord() expected a character, but string of length 5 found

So, even though I cannot hand over a stable live app repro, this absolutely did happen while automating a real desktop app.

What I think this means

The likely path is:

1. windows-mcp asks Windows UI Automation for state while traversing/inspecting the desktop tree.
2. Some UIA provider/property comes back in a shape that eventually reaches the comtypes VARIANT._set_value c_char branch.
3. That branch does:

self._.VT_UI1 = ord(value.value)

4. value.value is not length 1, so ord() raises:

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

I could not recover the exact UIA property name or provider from the historical logs. The logs preserved the high-level exception, but not the low-level property/provider payload.

What I could reproduce deterministically

I was able to build a deterministic synthetic repro for the broken comtypes code path itself. The point of this repro is not to claim that a normal ctypes.c_char should behave this way on its own; it is to show that the comtypes branch is not robust against a c_char value object whose .value is not a single character.

Minimal synthetic repro:

import ctypes
from comtypes.automation import VARIANT


class WeirdChar(ctypes.c_char):
    @property
    def value(self):
        return "hello"


VARIANT(WeirdChar(b"x"))

This deterministically fails with:

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

That is enough to show that this branch is brittle:

self._.VT_UI1 = ord(value.value)

What I tried to recover the live repro

After finding the historical real-world failures, I spent time trying to recreate them as closely as possible:

• same general Windows CI machine class
• same real Notepad scenario
• historical code revisions from the period where I originally saw the bug
• forced windows-mcp==0.7.0
• multiple historical reruns
• one dense rerun that executed the same Notepad case 20 times in a row

Result:

• I could not make the ord() failure happen again.
• In the dense rerun, the Notepad readiness step succeeded 20/20.
• Across the historical reruns, I ended up with 24 old-stack Notepad attempts on the same machine class without reproducing the ord() path again.
• The only failures I still saw were later save-interaction failures, not this ord() failure.

What I conclude from that

• The original failure was real.
• The comtypes VARIANT._set_value c_char path is genuinely vulnerable to this shape of value.
• The original March 25, 2026 live failure most likely depended on transient desktop/UIA provider state on that CI machine that no longer exists now.

So the most honest final status I can leave is:

• I have real-world evidence that this occurred in actual desktop automation.
• I have a deterministic synthetic repro for the broken comtypes branch.
• I do not have a stable modern step-by-step real-app repro that reliably recreates the same UIA/provider state.

[junkmd]

... -> windows_mcp_backend.py -> _rpc
WindowsMCPBackendError: ord() expected a character, but string of length 5 found
...
AIModelStepRunFailure: ord() expected a character, but string of length 5 found
...
AIUIExecutionError: ord() expected a character, but string of length 5 found

I am very interested in the content of the omitted traceback.
Is this occurring with the properties you previously mentioned?

• LegacyIAccessibleRoleProperty
• LegacyIAccessibleValueProperty
• LegacyIAccessibleDefaultActionProperty
• LegacyIAccessibleStateProperty

Regardless of the instability or environment-dependent nature of the issue, could you please share the full, non-omitted traceback (especially the part leading up to the ord error during UI Automation operations) and the script you used for your investigation?

It would be extremely helpful if you could provide even a single example of which method in which UI Automation interface is likely to trigger this.
If capturing the error is difficult, perhaps you could try temporarily inserting a logger directly into the comtypes source within your virtual environment to see what happens.