I have a project that is using networked colocation sessions for MR experiences. I needed a way to view what the players were doing as a supervisor role and thus used the VR Spectator camera. The issue is that I needed to build a windows version that allows me to connect and control the camera (Which works), but whenever one of the players spawns in with a pawn that has ISDK (Meta Interaction SDK), it immediately crashes the windows version.
From your description it sounds like the crash may be related to how the Meta ISDK components are initialized in a non-HMD Windows build. The spectator client is not running in VR, but the pawn that spawns likely still creates XR or interaction subsystems that expect a valid headset and tracking context.
If the ISDK pawn initializes hand tracking, input routing, or OpenXR features on BeginPlay without checking the platform or XR availability, that could cause an access violation on Windows spectator builds.
You may want to:
Check if the ISDK components are wrapped with platform checks (for example, only initialize when running on Android/Quest).
Disable hand tracking and interaction subsystems on the spectator build.
Review the crash log for module load failures related to OpenXR or MetaXR.
Test with a stripped pawn (remove ISDK components one by one) to isolate which component triggers the crash.
This looks less like a spectator camera issue and more like a subsystem initialization conflict between ISDK and a non-VR Windows runtime.
Hey Zoe, sorry I didnt see any notification about your reply. I am currently running Meta XR V85, and unfortunately for me it is not just a windows build issue. When I have a client join in a second headset, it crashed both client and host.
Issue: In a networked multiplayer setup (listen server + Quest client), the client crashes inside
UIsdkHandRigComponent::BeginPlay() when its replicated VR pawn arrives. The host (authoritative) runs the same code
fine.
Cause: UIsdkRigComponent::BeginPlay() calls:
UGameplayStatics::GetPlayerController(this, 0);
GetOwner()->EnableInput(PC);
BindInputActions(EIC);
On a replicated client pawn, even when Pawn->IsLocallyControlled() returns true at BeginPlay (possession often
replicates before BeginPlay fires), the underlying PlayerControllerList / InputComponent setup isn’t fully ready yet.
The input-binding path crashes. This is specific to replicated pawns — locally-spawned authoritative pawns don’t hit
it.
Fix: Subclass UIsdkHandRigComponentLeft/Right, force bAutoBindInputActions = false before calling Super::BeginPlay(),
and rebind input manually in TickComponent once the controller is fully ready.