| Previous | Next |
| RTC_E_NO_TRANSPORT | RTC_E_INVALID_PREFERENCE_LIST |
RTC_E_NOT_EXIST
Operational meaning: RTC_E_NOT_EXIST
This code belongs to enabling presence, maintaining buddies/watchers/groups, and processing server-roamed presence state: the specific RTC object requested by the operation no longer exists. Treating it as a generic RTC failure loses the state needed to choose a safe next action.
For correlation, retain 0x80EE0058 in the RTC interface facility 0xEE together with this result; generic HRESULT text can otherwise hide the protocol family and the exact RTC branch.
Evidence should show that you record object kind, authoritative ID, owner collection, generation, and last removal event; the diagnostic distinction is that this generic absence must be narrowed to the API object; it should not be converted to a network-not-found diagnosis.
Signals worth preserving
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: record object kind, authoritative ID, owner collection, generation, and last removal event.
- Correlation key: subscription dialog and expiration.
- Protocol or object snapshot: ACL decision and
NOTIFYversion. - Last completed transition: presence profile and account.
- Expected output: buddy/watcher URI.
Protocol and object state
| RTC area | presence subscription and contact-list |
|---|---|
| Condition to prove | the specific RTC object requested by the operation no longer exists |
| Objects to correlate | presence profile, buddy, watcher, group, ACL, SUBSCRIBE/NOTIFY state, presence document |
| Safe corrective direction | refresh the owning collection and discard stale references |
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.
Verification workflow
- Start from
0x80EE0058, then find the method/event pair that first exposed it. - To verify this, record object kind, authoritative ID, owner collection, generation, and last removal event.
- Keep the analysis at the right boundary: this generic absence must be narrowed to the API object; it should not be converted to a network-not-found diagnosis.
- After you refresh the owning collection and discard stale references, repeat the smallest reproducer rather than restarting the entire application environment.
Do not confuse it with
RTC_E_NOT_PRESENCE_PROFILE | the selected profile is not provisioned for the presence operation |
|---|---|
RTC_E_INVALID_BUDDY_LIST | the buddy-list data violates RTC list structure or identity rules |
RTC_E_PRESENCE_NOT_ENABLED | a presence operation was requested before presence was enabled for an appropriate profile |
Recovery and control flow
The appropriate response to it is not a blanket reconnect. Instead, refresh the owning collection and discard stale references, while preserving ownership of cleanup and any bounded retry.
Example: A delayed command targets a presence object removed during roaming synchronization.
Actions that do not address this condition
- Do not expose a private buddy list or watcher identity in general logs.
- Do not overwrite the server list with a stale local snapshot after an uncertain roaming result.
Technical references
- Client Presence Roaming.
- Microsoft RTC return constants.
- SIP presence event package.
- Watcher information.
Looking for a different code? Search another status or error code.