CloudXR6 Windows Server bug

Gaming and Visualization Technologies XR – VR/AR/MR CloudXR (VR and AR Streaming)
1

When setting up a CloudXR 6 Windows Server, when i try to set the device profile to auto-webrtc the server will not start. I believe the option is not recognized. Any help to get a patched version that supports webrtc on Windows would be greatly appreciated.

2

Which version of CloudXR Runtime version is used? Feel free to share the CloudXR Runtime log under the %TEMP% folder in windows for us to investigate.

3

I have tried all the runtime versions available and get the same result. I see that no matter what configuration parameter I try for device it either errors out of just runs auto_native.

4

It is likely the configuration parameter not properly constructed or passed into the library. The exact error code may help you narrow down to some more specific reason in: Runtime Management API Reference — NVIDIA CloudXR SDK

Here is a minimum python sample script to start the runtime in Linux with auto-webrtc.

import ctypes
import signal
from ctypes import c_char_p, c_size_t, c_void_p, c_int

lib = ctypes.CDLL("libcloudxr.so")
svc = ctypes.c_void_p()

def stop(sig, frame):
    lib.nv_cxr_service_stop(svc)

lib.nv_cxr_service_create(ctypes.byref(svc))
signal.signal(signal.SIGINT, stop)
signal.signal(signal.SIGTERM, stop)

prop = b"device-profile"
val  = b"auto-webrtc"
result = lib.nv_cxr_service_set_string_property(svc, prop, len(prop), val, len(val))
print(result)

lib.nv_cxr_service_start(svc)
lib.nv_cxr_service_join(svc)
lib.nv_cxr_service_destroy(svc)
5

I am trying to run a Windows server and the Windows runtime has the issue. Her eis the error I see and i will also attach the contents of my yaml file: [2026-06-02 17:40:47.010] [INFO] CloudXR API Version: 1.0.7
[2026-06-02 17:40:47.010] [INFO] CloudXR Runtime Version: 6.2.0
[2026-06-02 17:40:47.010] [ERROR] Error: SetStringProperty failed with status 4294967292
[2026-06-02 17:40:47.011] [INFO] Applying configuration from: cloudxr-runtime.yaml
[2026-06-02 17:41:07.535] [ERROR] Error: StartService failed with status 4294967294
[2026-06-02 17:41:07.536] [ERROR] Failed to start CloudXR service - start() returned error code: -2
[2026-06-02 17:41:07.536] [INFO] Stopping subprocess: 83804
[2026-06-02 17:41:11.538] [INFO] Force terminating subprocess PID: 83804
[2026-06-02 17:41:11.585] [INFO] Disconnecting named pipe client: cloudxr-service-ipc-44068-1058166610693
[2026-06-02 17:41:11.585] [INFO] Named pipe client disconnected
[2026-06-02 17:41:11.585] [INFO] Disconnecting named pipe client: cloudxr-service-ipc-44068-1058166610693
[2026-06-02 17:41:11.585] [INFO] Disconnecting named pipe client: cloudxr-service-ipc-44068-1058166610693

Yaml File:

apiVersion: cloudxr.nvidia.com/v1beta1

kind: OpenXRRuntimeConfiguration

# Feature flags control various runtime features

featureFlags:

deviceProfile: auto-webrtc # See: CloudXR Runtime Management API — NVIDIA CloudXR SDK

runtimeFoveation: true # Enable foveated streaming.

runtimeFoveationUnwarpedWidth: 3800 # Unwarped render width for foveation

disableAlpha: true # Disable alpha channel encoding in the video stream. For applications that don’t use transparency, disabling alpha can save encoding time and bandwidth.

audioStreaming: true # Enable audio streaming from the server to the client.

micStreaming: true # Enable microphone streaming from the client to the serve

6

Thanks. This issue is similar to Windows Server yaml configuration · Issue #17 · NVIDIA/cloudxr-js-samples · GitHub. Secure signaling for WebRTC mode in the CloudXR Runtime, which is enabled through Stream Manager, will be supported in the next release.

7

Is there a timeline when the next release will occur?

8

Thanks for your patience. The CloudXR Runtime 6.2.1 has been released and is now available for download from NGC.

The existing Stream Manager can now start the new runtime in WebRTC mode with secure signaling.

Here are a few important points to note:

  • Since the runtime is in secure signaling mode, the CloudXR.js needs to run in HTTPS mode to connect to it.

  • The current version of CloudXR.js does not support specifying a client token. This feature will be added in the next release of CloudXR.js. For now, please skip setting the clientID in Stream Manager for the JavaScript client.

9

Hi,

Follow-up on the auto-webrtc issue on Windows. The fix announced in 6.2.1 does not resolve it on my setup, and I can now confirm the same failure on 6.0.5, so this does not appear to be specific to one patch release.

Environment

  • Windows 10 (build 17763)
  • Quadro RTX 6000 (Turing) - not on the supported list, but the runtime initializes Vulkan, creates a CUDA context and completes compositor setup without errors
  • CloudXR Runtime 6.2.1 and 6.0.5 (clean rebuild for each)
  • Stream Manager 6.1.0
  • CloudXR.js 6.2.0
  • Clients: Meta Quest 3 (current Horizon OS) and the IWER emulator in Chrome

What works

Runtime starts correctly in auto-webrtc mode. Log confirms deviceProfile: auto-webrtc and backendMode: nvst-webrtc. It listens on 0.0.0.0:48322, single process (verified via netstat + tasklist, no duplicate service instances).

The CloudXR.js client connects successfully. From the emulator on localhost it reaches “Connected to Server” / “WAITING FOR STREAMING”. From real Quest 3 headsets over the network, netstat shows established connections:

157.253.192.225:48322  157.253.113.184:34584  CLOSE_WAIT
157.253.192.225:48322  157.253.113.184:48912  CLOSE_WAIT
157.253.192.225:48322  157.253.113.184:57648  CLOSE_WAIT

So signaling, TLS and firewall are all fine.

What fails

No OpenXR application ever registers with the service in auto-webrtc mode:

OpenXR Error: xrGetSystem returned XR_ERROR_FORM_FACTOR_UNAVAILABLE

GetCxrServiceStatus never changes:

OpenXR Runtime: Running
OpenXR App: Disconnected      <- never changes
CloudXR Client: Connected

UDP 47998 never opens, which is consistent with the media pipeline never being reached.

Tested with:

  1. The official LOVR sample, launched with --use_system_runtime after the client was connected and waiting (per the documented auto-webrtc behaviour where xrGetSystem returns FORM_FACTOR_UNAVAILABLE until a client connects)
  2. A Unity 2022.3 project (VR Template, OpenXR only, Oculus provider disabled, XR settings regenerated from scratch)

Same result in both, and on both runtime versions.

Ruled out

  • Wrong active runtime: HKLM\SOFTWARE\Khronos\OpenXR\1\ActiveRuntime points to the Stream Manager’s JSON (verified via GetCxrServiceJsonPath). Also tested via XR_RUNTIME_JSON.
  • Interface binding: listening on 0.0.0.0, and both localhost and LAN clients reach it.
  • Duplicate service instances: single PID owns the port.
  • Firewall / network: real headsets connect from another host.
  • Headset OS version: Quest 3 on current Horizon OS.
  • Client/runtime version mismatch: CloudXR.js 6.2.0 is documented as compatible with Runtime 6.x.
  • Application-side config: the official NVIDIA sample fails identically to the custom Unity app.

For reference, --device-profile=apple-vision-pro works end to end on this exact machine: service starts, LOVR connects, application initializes successfully. Only auto-webrtc fails to accept an OpenXR application.

Question

When the runtime runs in auto-webrtc mode, is there an additional step required for an OpenXR application to attach to the service? The Unreal integration guide mentions reinitializing the OpenXR HMD after nv_cxr_service_start succeeds - is there an equivalent requirement for applications that use the system runtime rather than embedding the C API?

Happy to provide full runtime logs. Thanks.