| Previous | Next |
| RTC_E_DUPLICATE_WATCHER | RTC_E_ROAMING_OPERATION_INTERRUPTED |
RTC_E_MALFORMED_XML
What the RTC value marks: RTC_E_MALFORMED_XML
The operational meaning of this result is tied to synchronizing profile, buddy, watcher, group, or ACL data with the server while preserving update ordering: RTC received or generated XML that cannot be parsed for the roaming or presence operation.
The machine-readable identity of this result is 0x80EE004C in the RTC interface facility 0xEE; the result identity matters because RTC uses separate facilities for API conditions, SIP final responses, and PINT service statuses.
The first useful check is to preserve document type, encoding, parse position, namespace declarations, and a redacted fixture. The result must be separated from nearby conditions because well-formedness failure occurs before list or ACL semantic validation.
Protocol and object boundary
| RTC area | RTC roaming synchronization boundary |
|---|---|
| Objects to correlate | roaming event, server version, local cache, operation generation, list document and completion state |
| Condition to prove | RTC received or generated XML that cannot be parsed for the roaming or presence operation |
| Safe corrective direction | fix XML generation/transport and retry only after fetching authoritative version state |
At the boundary, An interrupted roaming operation has an uncertain outcome: the server may have committed data even when the client did not receive completion; separately, this result must be read with the rule that A failed synchronization must be reconciled with fresh server state before replaying list mutations.
Evidence that separates the cause
Do not wait for a generic failure notification to log this result; preserve the API call or event producing it together with the RTC object and transaction state visible at that moment.
- Code-specific proof: preserve document type, encoding, parse position, namespace declarations, and a redacted fixture.
- Identity and target: local/server version marker.
- State at production: last acknowledged mutation.
- Timing and ordering: fresh enumeration after failure.
When recording it, redact credentials, full telephone numbers, private contact lists, and message bodies; retain permitted URI domains, header names, byte counts, hashes, transaction identifiers, timestamps, and state transitions.
Related RTC results
It is tied to the condition “RTC received or generated XML that cannot be parsed for the roaming or presence operation”; preserve that producing boundary before choosing recovery; the neighboring results below require different control-flow decisions.
RTC_E_ROAMING_ENABLED | roaming is already enabled for the selected profile or data type |
|---|---|
RTC_E_ROAMING_FAILED | the server-side roaming transaction completed as a failure |
RTC_E_ROAMING_OPERATION_INTERRUPTED | a roaming operation ended without a trustworthy commit outcome |
Facility equality is not semantic equality; route each contrasted value through its own recovery branch.
A safe diagnostic sequence
- Start from
0x80EE004Cand it, then find the method/event pair that first exposed it. - Check whether the failure was local before transmission, produced during RTC state validation, or mapped from a remote response.
- the proof step is to preserve document type, encoding, parse position, namespace declarations, and a redacted fixture.
- Keep the analysis at the right boundary: well-formedness failure occurs before list or ACL semantic validation.
- After you fix
XMLgeneration/transport and retry only after fetching authoritative version state, repeat the smallest reproducer rather than restarting the entire application environment.
A SIP capture without RTC callback state cannot show which local object accepted or rejected the transition; an HRESULT-only log has the opposite weakness: it cannot show whether the result was generated before transmission or mapped from the peer.
How to handle the result
The appropriate response to it is not a blanket reconnect. Instead, fix XML generation/transport and retry only after fetching authoritative version state, while preserving ownership of cleanup and any bounded retry.
Distinguish local rejection from an operation that may already have reached the server; use transaction identifiers and final events before replaying any non-idempotent action.
Example: A truncated roaming document ends inside a buddy element.
Actions that do not address this condition
- Do not blindly replay non-idempotent list changes after a disconnect.
- Do not delete the local cache before preserving versions and pending operations.
- A wrapper handling it should retain the original HRESULT instead of replacing it with an undifferentiated call failure.
Verification after a fix
Keep two tests: one that intentionally produces “RTC received or generated XML that cannot be parsed for the roaming or presence operation”, and one that applies the narrow correction; check the callback sequence, 0x80EE004C, final session/profile state, and absence of leaked listeners, dialogs, streams, or registrations.
Technical references
- Client Presence Roaming — authoritative context for the boundary.
- Microsoft RTC return constants — definitions relevant when reproducing it.
- SIP presence event package — API or protocol rules used to interpret it.
Looking for a different code? Search another status or error code.