| Previous | Next |
| RTC_E_ROAMING_FAILED | RTC_E_INVALID_ACL_LIST |
RTC_E_INVALID_BUDDY_LIST
What RTC_E_INVALID_BUDDY_LIST means in RTC
The operational meaning of this result is tied to enabling presence, maintaining buddies/watchers/groups, and processing server-roamed presence state: the buddy-list data violates RTC list structure or identity rules.
Log this result as 0x80EE004F in the RTC interface facility 0xEE, not only as a signed decimal; the facility distinguishes local RTC validation from a response status mapped by the stack.
Before changing configuration, validate buddy IDs/URIs, group references, duplicates, XML shape, and server version; the RTC codes surrounding this result are not equivalent because the document can be well-formed XML yet semantically invalid as a buddy list.
Minimum incident record
- Code-specific proof: validate buddy IDs/URIs, group references, duplicates,
XMLshape, and server version. - Owning object: subscription dialog and expiration.
- Wire evidence: ACL decision and
NOTIFYversion. - Lifecycle state: presence profile and account.
Protocol and object state
| RTC area | presence subscription and contact-list |
|---|---|
| Objects to correlate | presence profile, buddy, watcher, group, ACL, SUBSCRIBE/NOTIFY state, presence document |
| Condition to prove | the buddy-list data violates RTC list structure or identity rules |
| Safe corrective direction | repair only the invalid entries and preserve authoritative identifiers |
Presence data is subscription state rather than call state; buddy existence, watcher authorization, and current availability are separate concepts. When presence roaming is enabled, the server can act as the presence agent and becomes authoritative for list and subscription updates.
Correct application response
Resolve it at its producing layer: repair only the invalid entries and preserve authoritative identifiers; after it, a separate UI or watchdog retry must wait until that layer reports a final state.
A retry is safe only after the prior transaction’s outcome is reconciled; reissuing state-changing requests while the peer result is unknown can create contradictory RTC state.
Example: A roaming list contains two records with one server ID and a group reference to a deleted group.
How to prove the condition
- Start from
0x80EE004F, then find the method/event pair that first exposed it. - the proof step is to validate buddy IDs/URIs, group references, duplicates,
XMLshape, and server version. - Check whether the failure was local before transmission, produced during RTC state validation, or mapped from a remote response.
- Keep the analysis at the right boundary: the document can be well-formed
XMLyet semantically invalid as a buddy list. - After you repair only the invalid entries and preserve authoritative identifiers, repeat the smallest reproducer rather than restarting the entire application environment.
Diagnosis is strongest when object state and protocol trace share timestamps and transaction identifiers; avoid treating packet capture and HRESULT logging as substitutes for one another.
Nearby failure modes
Use “the buddy-list data violates RTC list structure or identity rules” as the discriminator when comparing the related RTC results below.
RTC_E_NO_GROUP | the requested presence group identifier does not exist in current authoritative state |
|---|---|
RTC_E_NOT_EXIST | the specific RTC object requested by the operation no longer exists |
RTC_E_DUPLICATE_WATCHER | the watcher is already present in the watcher/authorization collection |
Actions that do not address this condition
- With it, do not overwrite the server list with a stale local snapshot after an uncertain roaming result.
- Also do not expose a private buddy list or watcher identity in general logs.
Verification after a fix
Keep two tests: one that intentionally produces “the buddy-list data violates RTC list structure or identity rules”, and one that applies the targeted fix; check the callback sequence, 0x80EE004F, final session/profile state, and absence of leaked listeners, dialogs, streams, or registrations.
Technical references
- Client Presence Roaming — API or protocol rules used to interpret it.
- Microsoft RTC return constants — authoritative context for this result.
- SIP presence event package — definitions relevant when reproducing it.
- Watcher information — API or protocol rules used to interpret it.
Looking for a different code? Search another status or error code.