Unity Crash upon swapping from Controllers to Hand Tracking

[Zyro1331]

Describe the issue.

When swapping from Hand Tracking, to Controllers, than back to Hand Tracking, Resonite will Immediately crash upon closing the Quest Universal Menu.

To Reproduce

1. Launch Resonite with Hand Tracking, don't touch your controllers yet.
2. Once Resonite has finished booting and you can see your hands, grab your controllers from your desk.
3. Swap over from Hand Tracking to Controllers, your interactions carry on being just fine for this step.
4. Try to switch back to Hand Tracking without Crashing.

Best way I've gotten the issue to be more reproducible is by disabling the Quest's auto-switch feature, and just using the Quick Settings to swap between controllers and hands manually. It becomes more common to crash when closing or opening the Quest's Universal Menu while Resonite is running. If you don't crash the first time, try to repeat Steps 3 and 4 a few times to see if anything changes.

Expected behavior

N/A

Screenshots

No response

Resonite Version Number

Beta 2024.10.10.1348

What Platforms does this occur on?

Windows

What headset if any do you use?

Meta Quest 3 + SteamVR Beta 2.8.5 + SteamLinkVR Beta 2.0.11

Log Files

MANGOVRG - 2024.10.10.1348 - 2024-10-10 18_39_57.log
Player.log

Additional Context

No response

Reporters

@Zyro1331

[Frooxius]

Can you include the crash dump too please?

Does this happen even if you don't open the Quest Universal Menu at all?

[ModernBalloonie]

I jut reproduced this by using contollers, switching to hand tracking, Using contollers again, then switching back to hand tracking.DESKTOP-QBGCSAQ - 2024.10.10.1348 - 2024-10-10 19_07_06.log

[ModernBalloonie]

Oh, hmm. I then got a unity crash myself after going into the oculus menu.DESKTOP-QBGCSAQ - 2024.10.10.1348 - 2024-10-10 19_11_36.log

[Zyro1331]

Player.log
crash.dmp
error.log
Here's the full dump and logs from another similar crash. I'll try to get a video of what I was doing before the crash prepared but dealing Meta Quest file transfer jank

[ohzee00]

It seems weirdly inconsistent, I am seeing crashes too when it switches but only sometimes?

I had one happen when opening up the Quest Universal Menu however this one I just had a crash when turning on my index controllers while I had handtracking:
DESKTOP-V75BHJO - 2024.10.10.1348 - 2024-10-10 22_07_27.log
Player.log
crash.dmp
error.log

Note, I am using Steamvr beta with the Quest pro, I started with handtracking then turned on my controller for this test.

[ModernBalloonie]

I had my hand turn into a tracker, funnily enough. It appears that only sometimes it does this.

[Frooxius]

Also another important question - does this NOT occur on the main build at all?

[ohzee00]

Also another important question - does this NOT occur on the main build at all?

I just tested on main and I was able to recreate the above crash by switching between my index controllers and hands. (I turn off the controllers and try to go into my quest dash to refresh it)

Before when I tested on main a month or so ago with the same conditions I crashed before getting past the loading screen, I mistakenly thought it would be the same so I did not test it on main originally.

I do not have a crash dump weirdly enough but I do have a player.log of the MAIN BUILD crashing here:

Player.log
and regular log:
DESKTOP-V75BHJO - 2024.10.8.1349 - 2024-10-10 23_35_09.log

[Frooxius]

Hmm... This one seems pretty weird so far. The crash is coming from UnityPlayer.dll itself, which might indicate this is a bug in Unity itself, which would make fixing this problematic.

[FlameSoulis]

I'll try to replicate it, but this happened a month ago when I tried it for a friend. I can confirm the same occurs even if you don't use the pre-release so that it may be unrelated to anything involving the upgrade.

[shiftyscales]

This sounds like a duplicate of #2041. I don't think this is a new issue with prerelease, @Frooxius @FlameSoulis @ohzee00 @Zyro1331 @ModernBalloonie.

[FlameSoulis]

That'd add up to the experiences I was having a month ago. Always on top of things, Shifty!

[Frooxius]

Yeah based on this I don't think it's any of the pre-release stuff, so I'll remove the label. We might want to merge these up, but I think it might be better to just leave this one for the crash specifically, because the other part (the hands not switching) is fixed, so they're technically two separate problems anyway.

[ko-tengu]

I've managed to cause this crash in the pre-release by causing controller disconnects without using the hand tracking. I can leave my guardian area or lock the headset a few times and it's a pretty consistent crash.

BUFU - 2024.10.10.1348 - 2024-10-11 11_35_11.log
Player.log
crash.dmp
error.log
Player.log

edit: for the sake of science I reproduced this in the current release build also

BUFU - 2024.10.8.1349 - 2024-10-11 13_12_12.log
crash.dmp
error.log
Player.log

[ModernBalloonie]

Sadly with the steamVR update, this happens with it too...

[Frooxius]

@ModernBalloonie Does this happen even when not swapping the hand/controller tracking?

[ModernBalloonie]

@ModernBalloonie Does this happen even when not swapping the hand/controller tracking?

It happens with both swapping to hand tracking (sometimes) and also going to the oculus menu.

[Frooxius]

@ModernBalloonie Do you swap the hand tracking when going to the Oculus menu?

[ModernBalloonie]

@ModernBalloonie Do you swap the hand tracking when going to the Oculus menu?

Nope, it can just happen when hitting the oculus button.

[Frooxius]

Can you provide logs please?

[ModernBalloonie]

Can you provide logs please?

Do you want the player.log as well?

[Frooxius]

Yes. That's important one for crashes.

[ModernBalloonie]

DESKTOP-QBGCSAQ - 2024.10.23.15 - 2024-10-25 18_41_42.log
Player.log

[ModernBalloonie]

Actually, it must have something to do with the hand tracking because I just restarted SteamVR and never initalized hand tracking in the first place and now it seems to not crash... hmm... Sorry, correction: in Resonite i never used the hand tracking on that launch, but steamVR still had hand tracking as another controller at that point, it just wasn't being used.

[ModernBalloonie]

Yeah, I just confirmed it. Sorry, my bad.

[Frooxius]

@ModernBalloonie Thanks for the additional info. Can you describe what happened for the logs you sent? Did you ever switch to hand tracking?

I only see to one set of controllers being connected, which indicates that there's no swap to hand tracking from the controller registered, but I want to confirm.

[Frooxius]

@ModernBalloonie Also do you have a crash dump? I don't see anything in Player.log, not even indication of crash.

[Mrdabup]

Player.log
error.log
crash.dmp
DESKTOP-893KKM6 - 2024.10.23.15 - 2024-10-26 16_48_46.log
Here are my log files as requested

[ModernBalloonie]

@ModernBalloonie Thanks for the additional info. Can you describe what happened for the logs you sent? Did you ever switch to hand tracking?

I only see to one set of controllers being connected, which indicates that there's no swap to hand tracking from the controller registered, but I want to confirm.

So I never switched to hand tracking in Resonite itself on that launch, but in steam VR it had the hands greyed out, They un-grey out when you switch to hand tracking though, it seems like since I switched to hand tracking before I even opened Resonite, it causes the crash if they're "initialized" in steamVR.

If I start resonite without ever having used the hand tracking in SteamVR on that particular launch of SteamVR, it will not crash.

[FlameSoulis]

Yeah... the issue is that the Quest loves to turn hand tracking on by default, and if you are in full body tracking, you get greeted with Valve's still unsolved chest tracker screen. This was how I could tell with one of the crashes I was about to meet the Unity death screen.

DEMONDOGGO-PC - 2024.10.23.15 - 2024-10-27 03_50_24.log
error.log
Player.log
crash.dmp

[ModernBalloonie]

Hey so, Froox, I sent you some stuff on Telegram related to the controller crash as I was kind of running into github file size issues.

[Frooxius]

I did some more analysis on the crash dumps. This is definitely a Unity bug in their XR input system. I'll see if there's any way to upgrade this, but I'm not certain there is, since it's in UnityPlayer.dll itself.

Posting the call stack from the crash dump here for reference:

>	UnityPlayer.dll!UnityXRInputDeviceState::GetFeaturePtr(unsigned int)	Unknown
 	UnityPlayer.dll!XRToISXDevice::CopyFeatures(enum UnityXRInputFeatureType,struct dynamic_array<unsigned int,0> const &,struct UnityXRInputDeviceState const &,void const *,int,void const *,int)	Unknown
 	UnityPlayer.dll!XRInputToISX::OnDeviceStatesUpdated(enum UnityXRInputUpdateType)	Unknown
 	UnityPlayer.dll!XRInputSubsystemManager::Update(enum UnityXRInputUpdateType)	Unknown
 	UnityPlayer.dll!CallbackArray::Invoke(void)	Unknown
 	UnityPlayer.dll!`InitPlayerLoopCallbacks'::`2'::PostLateUpdatePlayerSendFrameStartedRegistrator::Forward()	Unknown
 	UnityPlayer.dll!ExecutePlayerLoop(struct NativePlayerLoopSystem *)	Unknown
 	UnityPlayer.dll!ExecutePlayerLoop(struct NativePlayerLoopSystem *)	Unknown
 	UnityPlayer.dll!PlayerLoop(void)	Unknown
 	UnityPlayer.dll!PerformMainLoop()	Unknown
 	UnityPlayer.dll!MainMessageLoop()	Unknown
 	UnityPlayer.dll!UnityMainImpl(struct HINSTANCE__ *,struct HINSTANCE__ *,wchar_t *,int)	Unknown
 	UnityPlayer.dll!UnityMain()	Unknown
 	Resonite.exe!00007ff7498111f2()	Unknown
 	kernel32.dll!BaseThreadInitThunk()	Unknown
 	ntdll.dll!RtlUserThreadStart()	Unknown

[ohzee00]

May I ask what version of the XR input system we are on if you know? I found the changelogs for them here and curious if I could find a version that states they fixed something related to this:

https://docs.unity3d.com/Packages/[email protected]/changelog/CHANGELOG.html

Knowing our luck when it comes to unity, it will probably be on a higher 2019 version than we can do.

[Frooxius]

I don't know, I haven't looked yet. I'll look into it soon, but I'm working on a higher priority item now.

[ohzee00]

Hopefully this isn't being overbearing nor trying to force the issue, I'm just bored and thought the information might be helpful.

The Unity.InputSystem.dll found in Managed says its version number is 1.0.2.0 which correlates to the above changelog version.

According to that changelog 1.0.2.0 is the last version to target Unity 2019.1, however I believe we are on 2019.4 which all the future versions of the Unity input system seem to target.

The minimum version requirement for the Input System package has been moved up to 2019.4 LTS.

Could mean a upgrade is possible! However there is a lot of changes even going to the 1.10 version, which could complicate a possible upgrade.

[shiftyscales]

Updating this issue- we attempted to upgrade to 1.11.2.0 in #3174 but reportedly it did not resolve this issue- so further testing / implementation of that has been cancelled indefinitely.