XR stream freezes and disconnects | Innoactive Resources

A frozen XR image does not identify the cause on its own. The stream may recover automatically, or the session may end and need to be started again. The useful question is what happened on the workstation, headset, and network at the same time?

This guide is for local streaming from a Windows workstation using Innoactive Spatial Runtime and NVIDIA CloudXR. Collect evidence first, then change one thing at a time.

1. Record what happened

For each freeze, note:

Exact date, time, and time zone, ideally to the second. For example: 2026-10-08 14:01:11 CEST (UTC+02:00).
How long the session had been running before the freeze, and roughly how long the frozen image lasted.
Whether the stream recovered by itself, reconnected, or ended and required a manual restart.
Whether the application on the workstation was still responsive. If you cannot check, record that as unknown.
Whether other headsets or network applications were affected at the same time.

If it tends to happen after about ten minutes, record the actual start and freeze times for several attempts. A repeated interval is a useful clue, but does not establish the cause.

2. Save Spatial Runtime and CloudXR logs

On the workstation, open Innoactive Spatial Runtime → Settings → Log Files → Open. Copy the logs covering the affected session into a separate folder before restarting the runtime or workstation, where possible.

Include:

SpatialRuntime-*.log.
CloudXrHost-*.log, if present.
CloudXR\cxr_server.*.log.
CloudXR\cxr_streamsdk.*.log.
OpenXRRuntimeService-*.log, if present.

For repeated freezes, include all files covering the incident period, including sessions before and after any automatic restart. The newest file alone may miss the failure. Preserve the original filenames and timestamps. If you have already restarted, look for the earlier files as well.

See Collect Innoactive Spatial Runtime logs for the folder-opening steps, and Collect debug and crash logs from the Vision Pro app for headset-side evidence.

3. Check the whole connection

The baseline for local streaming is workstation → Ethernet → switch/access point → Wi-Fi → headset. A wired workstation still depends on the headset’s wireless connection. Record any extra hops, including mesh wireless backhaul. See NVIDIA network setup.

If several headsets freeze together, investigate shared components first; if only one is affected, compare that headset and its wireless connection. These observations guide the investigation but do not prove the cause.

Include these details with the logs:

Detail	What to record
Software	Spatial Runtime version, headset client version, headset OS version, and Windows version
Workload	Application and version, scene or project used, and number of connected headsets
Graphics	GPU model and graphics driver version
Active network adapter	Full adapter model, connection name, driver provider, driver version, and driver date
Connection	Workstation Ethernet or Wi-Fi, headset access point, and any VPN, dock, or USB Ethernet adapter in the path
Wi-Fi	Access-point model and firmware, SSID and connected access point/BSSID if available, band, channel, channel width, headset location, and connected-device count
Network changes	Cable, workstation Ethernet port, switch port, or adapter changes and when they happened

Find adapter information under Device Manager → Network adapters → [adapter] → Properties → Driver. On a PC with several Ethernet ports, verify which adapter serves the connected port; do not infer its manufacturer from the socket or PC model. Your IT team can help match the active connection to its adapter.

4. Investigate Wi-Fi

Ask your IT team to inspect the access point or wireless controller around the freeze timestamp. Include its time zone and any clock difference from the workstation. Collect available records of headset disconnections or reassociations, roaming between access points, channel changes, DFS/radar events, and access-point restarts. Record signal strength, retry rates, and channel utilization if the equipment exposes them; mark unavailable data as unknown.

Check for interference, obstacles, or congestion near the headset. Wireless interference can reduce performance; see Apple's interference guidance. A strong signal indicator alone does not show whether packets are delayed or lost.

After collecting the original evidence, try one comparison at a time:

Move closer to the access point with a clear path, keeping the workload unchanged.
Test one headset, then repeat with the usual number of headsets.
Have IT test a less congested, locally permitted channel, recording the original and new settings.
Compare another access point while preserving the workstation, scene, and wired connection where possible.

Ask IT to compare packet loss, latency variation, and throughput on the local streaming path. A test from another wireless device is only a proxy for the headset, and a successful internet speed test does not validate the local workstation-to-headset connection. NVIDIA's CloudXR troubleshooting guide describes comparing wired and wireless performance and testing local throughput.

Use Optimize the network for local streaming for setup guidance. Do not assume a freeze after a particular number of minutes proves interference, roaming, or a DFS event; match the timing to evidence.

5. Investigate Ethernet and adapter resets

Export the Windows System event log

Do this on the streaming workstation, soon after the freeze:

Open the Windows Start menu, search for Event Viewer, and open it.
Expand Windows Logs and select System.
Choose Save All Events As… and save the log as an .evtx file.
Include that file with the runtime logs. If access is restricted, ask your IT administrator to export it.

Keep the original event log; a screenshot alone loses useful details. If your organization requires a smaller export, use Filter Current Log… to include the affected session and several minutes before and after it, then Save Filtered Log File As…. Include informational events as well as warnings and errors so that link restoration is visible.

Look for adapter resets at the freeze time

Inspect events around the recorded timestamp for:

Microsoft-Windows-NDIS / NDIS, Event ID 10400, with a message that the network interface has begun resetting.
Adapter-driver messages reporting hardware not responding, a hardware failure, or a lost network link.
A subsequent event reporting that the link was restored.

Save the General message and Details for relevant events, including the adapter name, timestamp, provider, and event ID. Driver-specific providers and event IDs vary, so do not filter only for 10400.

A reset can interrupt packet delivery: Microsoft's NDIS reset documentation describes how transmit requests may fail or remain queued during a reset. Match the affected adapter to the connection used for streaming. An event from an unused interface may be unrelated.

A driver message saying “hardware failure” does not by itself prove a physically defective adapter. Driver, firmware, and hardware investigation may still be needed. Likewise, no reset event does not rule out a network problem elsewhere.

Compare Ethernet connections

After saving the evidence, coordinate a comparison with your IT team:

Record the original adapter and setup.
If available, use another Ethernet adapter or workstation Ethernet port. Keep the cable, switch port, headset, scene, and other conditions the same where possible.
Verify which adapter is now active and whether the workstation's IP address changed. Reconnect the headset to the workstation if necessary.
Repeat the same workload for longer than the usual time to failure, and repeat the session if practical.
Record the duration, any freezes, and any new Windows reset events. Save the new logs separately.

Changing a switch port tests a different part of the connection from changing the workstation's adapter. Label each trial clearly. A single successful session is encouraging, but does not establish that the problem is fixed.

If resets consistently follow one adapter, give the evidence to your IT team or workstation vendor to review the appropriate driver and firmware. Avoid changing several driver, power-management, and network settings together: that makes it difficult to tell which change helped.

6. Check the application and runtime

If the workstation application also freezes or exits, capture its own logs and any error dialog. Export relevant Windows Logs → Application events using the same Event Viewer procedure. For VRED, see Collect VRED crash logs. Record whether Spatial Runtime or CloudXR stopped or restarted at that time.

If the desktop application remains responsive, continue investigating both the streaming components and the network. Compare the order of events across workstation, headset, and access-point logs. An error logged during session shutdown may be a consequence of the original interruption. No Windows adapter-reset event does not establish that Wi-Fi or the rest of the network was healthy.

For installation or startup-specific issues, see Lessons learnt — common setup issues.

For every comparison, keep a record of the single change, session duration, freeze times, and result. Run beyond the usual time to failure and repeat where practical. Save each trial's logs separately.

What a confirmed adapter-reset pattern looks like

In one investigated incident, nine stream-stall windows coincided with Windows network-adapter resets. The driver reported a failure, Windows began resetting the interface, and the Ethernet link was lost and restored. Eight link interruptions lasted about seven seconds; one lasted about eleven seconds.

Six stalls ended the CloudXR session; three recovered control traffic without immediate session termination. This is why a stream that resumes automatically can still warrant investigation. The measured link interruption is not necessarily the full duration of the visible freeze.

That evidence identified an adapter-reset problem in that incident. It does not establish the same cause for every freeze, or for another system with similar timing. CloudXR errors during shutdown can also be consequences of an earlier interruption; compare the sequence across Windows and runtime logs before assigning a cause.

7. Send a complete support report

Attach the logs through your Innoactive support ticket, following your organization's rules for sharing diagnostic data. Use this template:

Session start (date, time, time zone):
Freeze time(s) (date, time, time zone):
Approximate freeze duration:
Outcome: recovered / reconnected / session ended / manual restart
Workstation application still responsive: yes / no / unknown
Other headsets or applications affected:

Spatial Runtime and headset client versions:
Headset model and OS version:
Windows version, GPU, and graphics driver:
Streaming application and version:
Active network adapter and driver version/date:
Network setup (Ethernet/Wi-Fi, switch, mesh/backhaul, VPN/dock):
Access-point model/firmware, SSID, and connected AP/BSSID if available:
Wi-Fi band, channel, channel width, headset location, and device count:

Windows events near the freeze (provider, ID, adapter, message):
Access-point events/metrics near the freeze (include time zone):
Application/runtime errors or restarts:
Comparison performed, duration, and result:
Attached: runtime logs, CloudXR logs, System.evtx, headset/AP logs and Application.evtx if available