What does HRESULT 0x80EE002D (RTC_E_NO_DEVICE) mean?

Status / error code:		Category:

Constant name:
Source:	Operating System:
Description: No preferred device

Previous	Next
RTC_E_LOCAL_PHONE_NEEDED	RTC_E_INVALID_PROFILE

RTC_E_NO_DEVICE

Operational meaning: `RTC_E_NO_DEVICE`

This result belongs to the RTC media controller and terminal boundary area of RTC and identifies no preferred or compatible media device is available for the requested RTC media type.

This result carries 0x80EE002D in the RTC interface facility 0xEE; store the result value at the first RTC callback or method boundary, before retry logic replaces it with a broader timeout or connection message.

Start the result investigation by having the trace enumerate terminals and preferred-device settings for capture and render; for this HRESULT, do not skip the distinction that this is selection/capability absence, while MEDIA_*_DEVICE_NOT_AVAILABLE can describe a chosen device that became unavailable.

Signals worth preserving

Capture the first result before retry, reconnect, profile re-enable, or teardown changes the evidence; associate this result with one RTC object generation and one transaction or media transition.

Code-specific proof for this HRESULT: enumerate terminals and preferred-device settings for capture and render.
Correlation key for this HRESULT: stream direction and negotiated codec.
Protocol or object snapshot for this HRESULT: device removal or format-change event.
Last completed transition for this HRESULT: session and media type.
Expected output for this HRESULT: terminal/device identifier.

A useful this result trace does not require communication content or secrets; in the result record, keep structural metadata and correlation identifiers while removing passwords, authorization material, complete numbers, and private presence data.

Protocol and object boundary

RTC area	RTC media controller and terminal boundary
Condition to prove	no preferred or compatible media device is available for the requested RTC media type
Objects to correlate	RTC session, media type, terminal/device, stream direction, controller state, acoustic echo cancellation
Safe corrective direction	select a valid terminal or disable that media type for the session

At the boundary, Signaling success does not guarantee that a capture or render device exists or that a media stream can start; separately, it must be read with the rule that AddStream, RemoveStream, hold, and terminal selection change the media state machine and can race with callbacks from the previous operation.

Verification workflow

Start from 0x80EE002D and 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 enumerate terminals and preferred-device settings for capture and render.
keep the analysis at the right boundary: this is selection/capability absence, while MEDIA_*_DEVICE_NOT_AVAILABLE can describe a chosen device that became unavailable.
after you select a valid terminal or disable that media type for the session, repeat the smallest reproducer rather than restarting the entire application environment.

Use RTC event state to interpret the protocol trace for this HRESULT, and use the trace to verify what left or reached the host; for this HRESULT, this two-sided correlation identifies the producing layer.

Do not confuse it with

It is tied to the condition “no preferred or compatible media device is available for the requested RTC media type”; preserve that producing boundary before choosing recovery; for this HRESULT, the neighboring results below require different control-flow decisions.

`RTC_E_MEDIA_AEC`	RTC failed to enable acoustic echo cancellation for the audio path
`RTC_E_MEDIA_ENABLED`	code attempted an enable transition for media that is already enabled
`RTC_E_MEDIA_SESSION_NOT_EXIST`	the requested media-session object no longer exists for the RTC signaling session

Keeping it separate from these neighbors improves both user messaging and automated retry policy.

Recovery and control flow

Recovery from it should be narrow: select a valid terminal or disable that media type for the session; while handling it, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.

Before retrying it, classify the previous operation as definitely failed, definitely completed, or remotely uncertain; for this HRESULT, that distinction prevents duplicate dialogs, bindings, transfers, or roaming mutations.

Example for this HRESULT: A headless machine starts an audio session with no configured audio terminal.

Actions that do not address this condition

An investigation should not do not recreate the entire SIP session before determining whether only a local terminal failed.
also do not assume the default Windows device is the terminal selected by the RTC object.
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 “no preferred or compatible media device is available for the requested RTC media type”, and one that applies the narrow correction; for this HRESULT, check the callback sequence, 0x80EE002D, final session/profile state, and absence of leaked listeners, dialogs, streams, or registrations.

Technical references

About the RTC Client API — authoritative context for the boundary.
Creating an RTC session — definitions relevant when reproducing it.
Microsoft RTC return constants — API or protocol rules used to interpret it.
SDP offer/answer — authoritative context for the boundary.

Looking for a different code? Search another status or error code.