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.