[Bug] TOTK wont launch with certain mods unless hypervisor is enabled (MacOS)

[MR-UNI]

Description of the issue

When using MaxLastBreath's NX Optimizer/TOTK optimizer/UltraCam, TOTK refuses to launch unless either the Memory management mode is set to "Software" or "Use Hypervisor" is on.

The issue with having the hypervisor on is that it creates a plethora of graphics bugs and artifacts that are not present when the Hypervisor is off.

( without the mod the game runs launches properly regardless of memory management mode or hypervisor use, but it still has the graphics bugs when using the hypervisor)

I reported this issue to the mod developer, but I was directed here.

Going off of what i could see in the logs (they didn't give a whole lot of information), it seems to be a pointer authentication error.

This issue has been present for a while now, but i thought it was something I was doing wrong setting up the mod, but it appears as though that is not the case.

Reproduction steps

Must be on MacOS
Must have TOTK Optimizer aka Ultracam aka NX optimizer installed for TOTK

Disable "Use Hypervisor" under CPU Mode,
Use either "Host (fast)" or "Host Unchecked (fastest, unsafe) under Memory Management Mode
Attempt to launch Tears of the Kingdom.

Log file

Apple-Crash-Report.txt
Ryujinx_Canary_1.3.252_2026-02-09_14-36-44.log
Ryujinx_Canary_1.3.252_2026-02-09_15-34-51.log

OS

MacOS Tahoe 26.3

Ryujinx version

1.3.252

Game version

1.4.2

CPU

M3 Pro

GPU

Apple Silicon Graphics

RAM

18GB

List of applied mods

TOTK Optimizer (aka NX Optimizer/UltraCam)

Additional context?

I am rather stumped on this one.

I think it is a pointer authentication error because the game will launch when in the hypervisor (has its own PAC rules) but wont launch outside of it unless Memory management mode is set to software (Meaning the memory is being emulated entirely in UserSpace)

[sh0inx]

continued from #224

Can you see if you can replicate this with a local build? The issues we've seen with hypervisor are weird and plentiful, but it seems to be somewhat alleviated by self-compiled builds.

[MR-UNI]

I opened this as a separate issue stemming from the conversation on #224 and an updated version of #246 now that I know a bit more about whats going on.

[MR-UNI]

continued from #224

Can you see if you can replicate this with a local build? The issues we've seen with hypervisor are weird and plentiful, but it seems to be somewhat alleviated by self-compiled builds.

Ill try!

[MR-UNI]

continued from #224

Can you see if you can replicate this with a local build? The issues we've seen with hypervisor are weird and plentiful, but it seems to be somewhat alleviated by self-compiled builds.

The following Error is what showed when using local build:

"💣 Program crashed: Bad pointer dereference at 0x69696904e72d0969
Platform: arm64 macOS 26.3 (25D122)
Thread 83 "" crashed:
0 0x00000004ff36a568
1 0x00000004ff369b1c
2 0x00000004ff362a64
3 0x00000004ff35ea60
4 0x00000004ff35e568
5 0x00000004ff351344
6 0x00000004ff2e2554
7 0x00000004ff2d4528
8 0x00000004ff2d410c
9 0x00000001112b1d84
10 0x00000001112ae8d8
11 0x00000001112ae714
12 0x00000001108ca850
13 0x00000001103b6908
14 0x000000010891a274
15 0x0000000106168330 CallDescrWorkerInternal + 132 in libcoreclr.dylib
16 0x00000001060003e0 DispatchCallSimple(unsigned long*, unsigned int, unsigned long, unsigned int) + 276 in libcoreclr.dylib
17 0x0000000106013ac0 KickOffThread_Worker(void*) + 144 in libcoreclr.dylib
18 0x0000000105fd1748 ManagedThreadBase::KickOff(void ()(void), void*) + 236 in libcoreclr.dylib
19 0x0000000106011efc KickOffThread(void*) + 212 in libcoreclr.dylib
20 0x00000001061a7924 CorUnix::CPalThread::ThreadEntry(void*) + 352 in libcoreclr.dylib
21 0x000000019c57fc08 _pthread_start + 136 in libsystem_pthread.dylib
"
(this was with hypervisor disabled, memory management mode host)
Running in hypervisor resulted in the same behavior as seen in the precompiled build.

[MR-UNI]

Full log:

Ryujinx_1.0.0-dirty+1260f93aaf7b2cf30084c668709ec7b2d6d9ee99_2026-02-11_14-50-31.log