Ayyyy, welcome to the **macOS: Fix Hypervisor BadArgument Launch Crash PR!**
We are so so back my friends.
This PR fixes the macOS Hypervisor `BadArgument` launch crash, while also sneaking in some improvements to help _potentially_ mitigate those lovely 0 FPS deadlock on macOS in certain games with Vulkan + Hypervisor enabled (there will be a separate PR in the future to address this).
The PR is slightly different in terms of the PR messages that I write, but I hope that it'll provide the necessary context to those unaware of the reasoning/causes of the issue.
Also, this is a bit of a read, so grab some snacks, pour a drink, get comfortable, and enjoy some…
### STORY TIME!!!
_Before we proceed forward, we must properly understand what Hypervisor is._
_Hypervisor refers to using Apple's built-in virtualization technology, the Hypervisor Framework, to accelerate CPU emulation._
_There are two main ways to do this:_
_1. **Interpreter** – executes instructions one by one (very slow)._
_2. **JIT (Just-In-Time)** recompilation – translates Switch CPU instructions into native code (much faster)._
_On Apple Silicon Macs (M1, M2, M3, etc.), the guest CPU and host CPU are both ARM64-based. As the Nintendo Switch itself is ARM64, The Hypervisor Framework can allow Ryujinx to execute large amounts of guest code more directly, reducing emulation overhead. The architectural similarity makes hardware-assisted execution practical. On Intel Macs, there isn't the same direct ARM-to-ARM advantage, so the benefits are much more limited or unavailable._
_When Hypervisor mode is available and working correctly, it can provide higher frames, reduced CPU bottlenecks, faster shader compilation in certain instances, smoother gameplay, and lower CPU usage._
_The improvement depends heavily on the game. CPU-heavy titles tend to benefit the most._
_There are downsides though. Sometimes, certain games may have compatibilities issues, certain feature may not work exactly the same, bugs in the actual Hypervisor implementation can cause crashes or issues, and performance gain vary significantly on a game-to-game basis._
_In terms of a simple analogy:_
_**Without Hypervisor:** Ryujinx acts like a translator who rewrites every sentence before speaking it._
_**With Hypervisor:** Ryujinx can let the Mac's CPU understand and execute much more of the Switch's code directly, so less translation work is needed._
_Anyway, now that we have the background, onto the story!_
Once upon a time, around ~December 2025 / January 2026, users — and yes, even devs (though let’s be honest, macOS devs are basically cryptids at this point)
_(Authors note: Cryptids - animals or other beings whose present existence is disputed or unsubstantiated by science)_
Started noticing inconsistent behaviour with the macOS Hypervisor. In other words, Hypervisor began showing inconsistent launch behaviour for users who've upgraded to the then current macOS versions (15.7.3 / 26.2). This behaviour continued as macOS got updated, and is still present on the latest version (Tahoe 26.5.1).
Initially, Hypervisor was mostly crashing with an `Unexpected result "Denied"`. The likely cause is two fold:
1. macOS security permissions changed during that update.
2. Hypervisor framework got updated, but nothing what communicated to the devs.
(It is likely to be the former, not the later. This is the main theory, at least.)
However, this crash later evolved into (because of course it did) into `Unexpected result "BadArgument"`.
We'll come back to this in a bit.
For users who wished to run games with Hypervisor enabled, they had a simple solution - build Ryujinx locally. Yes, this is an effective solution in its own right, as that does bypass certain macOS signing and certain .app bundle-related constraints, as well as certain security permissions.
However, this doesn't explain why:
* Official server builds were the only builds that were affected
* Users on _older macOS_ (below 15.7.3 / 26.2) could run games with Hypervisor enabled as if nothing had ever gone wrong in their lives.
* Users on _newer macOS_ versions _could still run certain older_ Ryujinx builds as intended — specifically, the last or close-to-last version they had lying around in their Downloads folder.
* Users on macOS above 15.7.3 / 26.2 could still run games with Hypervisor enabled, on builds downloaded from the server, for whatever reason.
So now we’re here:
* Same macOS versions → Different outcomes
* Different Ryujinx builds → Different behavior
* `Denied` → Evolved into `BadArgument`
* No consistent reproduction steps
And so, after attempting to fix this for quite some time, I've determined it to be unfixable. Ryujinx should drop macOS support because development has been held back far too long, and there is nothing we can possibly do. Every possible solution was tested and the results were null.
So, it is with great sadness that, here and now, I proclaim that Ryujinx will terminate further macOS support.
Bye-bye, Ryujinx on macOS! You had a great run, and you'll always be remembered. Thank you for bringing so much great memories to us, macOS users!
...
...
...
...
...
HAHA - NOT SO FAST!
(_Please tell me I got you there_)
Not all hope is lost - there is light at the end of the tunnel!
**The key insight is this:** `BadArgument` is not just “`Denied` but newer and worse”. It’s something else entirely.
* `Denied` → macOS refuses the request at the security boundary. Nothing even starts.
* `BadArgument` → macOS accepts the request, but the data being passed is now invalid under newer constraints.
So instead of:
_“You shall not pass.”_
We now have:
_“You may pass… but what is THAT?”_
And this brings us to this PR!
### The PR
Users on macOS were experiencing two major issues when Hypervisor was enabled:
**1. Hard Crash – "Unexpected result `BadArgument`"**
The most frequent stack trace pointed to:
```
System.Exception: Unexpected result "BadArgument".
at Ryujinx.Cpu.AppleHv.HvResultExtensions.ThrowOnError(...)
at Ryujinx.Cpu.AppleHv.HvExecutionContextVcpu.GetX(Int32 index)
at Ryujinx.HLE.HOS.Kernel.Threading.KThread.GetCurrentContext()
at Ryujinx.HLE.HOS.Kernel.Threading.KThread.GetThreadContext3(...)
```
This crash occurred very early during game initialization, most often inside supervisor calls such as `GetThreadContext3`.
**2. Intermittent Permanent 0 FPS Freezes with Vulkan (unrelated to `BadArgument`, but somewhat addressed in this PR)**
The game would run normally for a while, then drop to 0 FPS permanently. Disabling Hypervisor eliminated the freezes but performance was at times inconsistent.
### The Explanation
`HvResult.BadArgument` is returned by Apple's Hypervisor framework (`hv_vcpu_get_reg`, `hv_vcpu_get_sys_reg`, `hv_vcpu_get_simd_fp_reg`, etc.) when it determines that the requested operation cannot be performed in the current vCPU state.
**Common reasons why this happens:**
* Timing races - the guest tries to read registers before the vCPU has fully synchronized its internal state after context switches, exceptions, or vCPU pool reuse.
* Stricter validation in newer macOS versions.
* vCPU state inconsistencies during early boot or heavy syscall activity.
Because the original implementation called `.ThrowOnError()` unconditionally on every Hypervisor call, even a single transient `BadArgument` would immediately terminate execution. This was the direct cause of the crash.
The 0 FPS issue was a separate but related symptom: when Hypervisor is enabled, the guest CPU runs significantly faster than MoltenVK's presentation queue expects, leading to command buffer starvation and queue deadlock.
### The Changes
* **Implemented: Complete Shadow Register Cache (`HvExecutionContextVcpu.cs`)**
* Added full in-memory shadow copies of every relevant register:
* General-purpose registers: `private readonly ulong[] _x = new ulong[32]`;
* Vector/SIMD registers: private readonly `V128[] _v = new V128[32]`;
* System/special registers: `_pc`, `_elrEl1`, `_esrEl1`, `_tpidrEl0`, `_tpidrroEl0`, `_fpcr`, `_fpsr`, and `_pstateRaw` (stored as `ulong` internally to avoid type conversion issues).
* **Reasoning:** Returning zero or garbage values on failure could corrupt game state. When the Hypervisor returns `BadArgument`, we now have a safe, previously-valid value to return instead of crashing. A shadow cache gives us that last known good value. The cache is updated on every successful read, so correctness is preserved in normal operation. This is the central fix for the `BadArgument` crash.
* **Defensive BadArgument Handling on Every Register Access Path**
* Updated every read operation (`GetX`, `GetV`, `Pstate`, cached getters, etc.) to explicitly check the return value, with the same pattern applied across all accessors.
* **Reasoning:** This directly eliminates the crash while preserving the original error-throwing behavior for genuine failures. Returning cached data is far safer than injecting zero or garbage values that could corrupt guest state:
```
HvResult res = HvApi.hv_vcpu_get_...(..., out value);
if (res == HvResult.BadArgument)
{
_fallbackCount++;
LogHvWarning("..."); // rate-limited
return cachedValue; // safe fallback
}
res.ThrowOnError(); // only throw on real errors
return cachedValue = value; // success path + cache update
```
* **AggressiveMode Global Option** (NOT IMPLEMENTED IN THIS PR, BUT A FUTURE PR WILL ADD THIS FULLY)
* Added:
`public static bool AggressiveMode { get; set; } = false;`
* When true/enabled, all warning logs in LogHvWarning() are suppressed.
* **Reasoning:** Diagnostic logging has overhead. In the future, users will be able to disable/enable this when required. This will also be useful for any dev working on macOS Hypevisor (aka - me).
* **Hot-Path Optimizations**
* Changed index checks from `if (index < 0 || index > 30)` to `if ((uint)index > 30)` in `GetX`, `SetX`, `GetV`, and `SetV`.
* Separated cache initialization into a dedicated `InitializeCacheDefaults()` method called by constructor and `Reset()`.
* **Reasoning:** `GetX` is called millions of times per second. Reducing branches improves CPU branch prediction and overall throughput. The clean initialization pattern ensures reliable behavior when vCPUs are reused from the pool.
* **Improved Logging, Diagnostics & Monitoring**
* Rate-limited warnings with a cooldown timer (`WarningCooldownTicks = 1_000_000_000 ≈ 1 second`).
* Clear, descriptive messages (e.g. "PAC failure on SP_EL0", "PAC failure on X15").
* Added `public long GetFallbackCount()` for runtime monitoring.
* **Reasoning:** We need visibility into fallback frequency during development and testing, but we must not spam the log for end users during normal gameplay.
_Quick side note:_
_The logging mentions "PAC failure" rather than HV `BadArgument`, and this is a shorthand I've added right now for myself.
Technically, we are catching HvResult.BadArgument. It's called "PAC failure" in logs because PAC is a frequent trigger, especially with games like TOTK that use heavy mods (AKA TOTK Optimiser)._
_Right now, I'm calling it a PAC failure, but will later rename to `BadArgument` as I progress further on a certain issue that's been sitting in our GitHub for some time._
_Back to the main stuff:_
* **GPU Synchronization & _Potential_ 0 FPS Mitigation (`HvExecutionContext.cs`) (PR FOLLOW UP IN THE FUTURE)**
* Added adaptive `TryGpuSync()` called periodically in the main `Execute()` loop (every 10–12 execution steps).
* Added strategic `Thread.Yield()` after `SvcAarch64` handling and in sync points.
* Tuned counters based on real gameplay testing (% 10 for light sync, % 6 for stronger sync).
* **Reasoning:** Hypervisor accelerates the guest CPU significantly. Without periodic yielding/flushing, MoltenVK's presentation queue can starve, causing permanent 0 FPS. The adaptive approach gives aims to fix this by performing a "resync". This has been tested and is showing positive progress, but, as mentioned earlier, will continue in a future PR.
These are all of the changes in this PR.
It's been quite a ride getting Hypervisor back up and running, but I loved every second of it.
If there is anything that is unclear in this PR, please let me know and I'll provide more details and update the description above.
Here is a small FAQ section to answer some more questions. These answers come from my own personal testing and behaviour that I observed.
### FAQ
**Q:** Why can some users play games with Hypervisor enabled and others can't on newer macOS versions?
**A:** This needs a bit of clarification.
You _can_ still run games with Hypervisor enabled on latest macOS - just not all games. Games such as Pokémon Legends: Z-A, The Legend of Zelda: Tears of the Kingdom, The Legend of Zelda: Breath of the Wild, can all _run_ and will _boot_ with Hypervisor enabled.
However, some other games, like Beyblade X Xone, Beyblade X Evobattle, Tales of Xillia Remastered, Tales of Berserk Remastered, etc, will _crash_ on boot with `BadArgument` error.
So it's not that Hypervisor works for one user and doesn't work for the other.
_It's that the game doesn't cause Hypervisor to crash._
Games differ in how aggressively they read registers early in boot and how much they rely on modded/JIT code. Games with heavy early supervisor calls and/or mods that manipulate pointers/PAC (pointer authentication errors) are far more likely to hit BadArgument.
(PAC is the reason why TOTK crashes with UltraCam when Hypervisor is disabled on macOS)
Lightweight or less modded titles often avoid the problematic code paths.
––––––
**Q:** How stable is this fix?
**A:** Updating macOS versions (Tahoe -> Tahoe) didn't break this implementation. Current data and testing all provide positive results (i.e. - no crash, hooray!)
––––––
**Q:** What about the `Denied` error?
**A:** This has more so to do with macOS permissions. Currently, Ryujinx is not being shipped in a DMG (which, by Apple conventions, is a more proper way of handling macOS app installations outside of the App Store). There is a theory that packaging Ryujinx into a DMG file will alleviate any permission issues that we currently have, and may help fix this type of error, so this PR may not even be needed (but we'll have to see how it goes).
That said, this error has not appeared in any of the more recent crash logs that I've analysed or acquired myself (from testing), leading to a possible hypothesis that the permission issues have been resolved, but the Hypervisor implementation broke on server builds due to an update to the framework. This is, however, unlikely, because, again, only builds after a particular version (i.e. - the last working version on a users system) broke.
However, DMG packaging is still on a table and something that we want to implement as soon as possible.
––––––
**Q:** So why do local builds run then?
**A:** A lot of different factors - build environment, folder location, lack of permissions associated with running .exe files, different ways of handling pure .exe files and .app bundles, notarisation, and more. There was no "scientific testing" done on each of the factors and seeing which one affects what exactly. Pushing this PR and implementing the DMG will tell.
fixes cursor being at 0 position even when text is present, especially annoying for handheld devices with kde virtual keyboard, which is pretty bad, with no way to move the cursor or delete text backward
This PR is the first in a batch of structural changes to Ryujinx.
**Changes**
- Added `ProcessIdentity` and `ProcessKind` to describe loaded programs by:
- PID, program ID, application ID, program index, display version, process kind
- Stored identity metadata on `ProcessResult`.
- Added PID-based process lookup helpers to `ProcessLoader`.
- Updated HLE services to resolve application metadata through the caller PID instead of `Processes.ActiveApplication`.
- Added PTC/JIT disk cache initialization logging with PID, title ID, display version, selector, and enabled state.
- Added `ClientProcessId` property to ServiceCtx (/src/Ryujinx.HLE/HOS/ServiceCtx.cs) that uses the handle descriptor PId when available, falling back to `Process.Pid`.
- Updated 15 HLE service files to use `context.ClientProcessId` instead of `context.Process.Pid` for client process access, ensuring services correctly identify the calling process even when invoked via IPC with handle descriptors.
These changes make service metadata resolution more explicit and prepare the emulator for other structural changes later on.
## Description
~~Fixes a fatal CLR crash when `caps` screenshot saving receives an input buffer larger than `0x384000`.~~
~~Resolves a crash in Tomodachi Life: Living the Dream where saving the pictures to the system's album crashes with 0x80131506.~~
Follow up to #18. This PR adjusts the validation and copy behavior to better match real hardware, and adds logging to make invalid screenshot buffer cases easier to diagnose.
Real hardware accepts screenshot buffers with a size greater than or equal to `0x384000`, but only `0x384000` bytes are needed for the 1280x720 RGBA image.
This changes screenshot saving to:
- reject buffers smaller than `0x384000`
- accept buffers equal to or larger than `0x384000`
- copy only the first `0x384000` bytes into the 1280x720 bitmap
## Testing
Tested with a real Switch NRO using `capssuSaveScreenShotEx0`, `capssuSaveScreenShotEx1`, and `capssuSaveScreenShotEx2`.
Observed hardware behavior:
```text
0x384000 => OK
0x384000 - 1 => NullInputBuffer
0x384000 + 1 => OK
0x3C0000 => OK // Tomo life picture size
```
Co-authored-by: yell0wsuit <5692900+yell0wsuit@users.noreply.github.com>
- Fixes `StoreData` layout/update handling so `UpdateLatest` returns the stored Mii data correctly.
- Implements `IDatabaseService.Append` (https://switchbrew.org/wiki/Shared_Database_services#IDatabaseService)
Also adds regression tests for `UpdateLatest` and `Append`.
(Might) fix Mario Kart 8 Deluxe crashing on first boot due to failed Mii verification check (due to custom Mii from emulator), and potentially Tomodachi Life: Living the Dream for the "Import Mii from system" option.
Co-authored-by: yell0wsuit <5692900+yell0wsuit@users.noreply.github.com>
no way this was working before, and if it did, just pure luck, unsafe blind copy of bytes as is and zero checks.
i only tested tomodachi, but should fix all games that were crashing on saving screenshots
the crash was happening because the screenshot buffer was bigger than the bitmap buffer, so marshall.copy() was raising an unhandhled expection crashing the emu.
on top of this, because the data was just copied as is, the result image was garbled.
- Services now use their actual names when creating processes instead of the generic "Service".
- Services now use their names encapsulated in curly brackets for threads, e.g. {HID}, instead of the default "HLE.OsThread", making it easier to see what is actually happening behind the scenes. Client threads should use <> and host threads should use {}.
- Fixed a bug where initiating services would create extra unneeded servers.
This is part 1 of a series of service and Horizon changes i'm working on. More will follow at a later date.
If an npad device was checking for if the device was at rest, we called `GetSixAxisSensorLifo()` -- if the npad was of type `None`, it triggered the `NotImplementedException` in that method because `None` doesn't have a gyroscope, and therefore no data attached to it.
Implement nn::ssl::sf::ISslServiceForSystem -> CreateContextForSystem (100)
Ryujinx implements both ISslService and ISslServiceForSystem in one class so we can just return new ISslContext.
Also fixed the incorrect parameter reading order. (CreateContextForSystem basically has same params as CreateContext)
Fixes the actually insane amount of log spam in games that check for this, such as Luigi's Mansion 3.
Values in HidDevices.NpadDevices.isAtRest may need to be tuned to a better range for resting detection. I originally set them to 0, and my controller rests at definitely NOT 0.
Will need to be revisited when implementing functionality for the global SixAxisActive bool, IHidServer.StartSixAxisTracking, and IHidServer.StopSixAxisTracking.
Fixes a few crashes:
- fixes a crash related to waking threads (priorities were wrong).
- fixes a crash from reusing the SetRenderTargets texture array (left-over data causing issues).
- fixes a mistake and an oversight in the buffer system.
- buffers were getting updated wrong causing bad data to be stored or some times cut.
- modified ranges would extend past their old buffers, crashing on syncs. Old buffers are now skipped as the new buffers already sync instead.
Introduces pooling in a few more places to increase memory efficiency.
simplified RangeList item logic.
- removed RangeItem by making all the range objects use the I(NonOverlapping)Range interface.
- BufferCache class no longer locks its RangeList, as the list is only ever accessed synchronously.
Small change to how keyboard snapshots are stored.
Increase ThreadedRenderer SpanPool size to fit slightly more data (4MB -> 8MB).
Fix games that uses ContextRegistrar (e.g. After the socket blocking issue is fixed, Splatoon 3 and other ModuleSystem games will call this when booting, to create a context for the error, after a connection attempt to the server failed.)
Previously, sockets were only ever closed when the game specifically requested it.
Thanks @comex on GitHub for the patch submitted via the [Ryubing] issues page.
Co-Authored-By: comex <47517+comex@users.noreply.github.com>
General memory improvements to decrease GC pressure and frequency.
Pool big arrays and objects that are created and deleted often.
Skip data copies when they aren't needed.
Inline flag checks to skip unneeded allocations.
From my testing the performance is about the same, but the GC frequency is much lower and collection is faster causing less and smaller spikes.
This lets games such as The Legend of Zelda: Tears of the Kingdom (v1.4.2) and other SDK 20+ games successfully circumvent a crash when calling an applet.
Example: No controller connected on boot -> calls Controller Applet -> no stub = crash.
ObjectPool now uses ConcurrentBag instead if ConcurrentStack, as it has a smaller memory footprint.
Fix compiler warnings related to Audio Command Pools.
Switch gpu command initialization to use pointers, that way skipping the allocation of the command which is unnecessary.
Skip byte array allocation in Ioctl2/3 if it isn't needed (if the source data is all continuous we don't need to copy it to make it continuous).
- Move the message handler into its debugger class part,
- Move all message types into one file and collapse 3 of the ones with no data into a generic, stateless message with a single property being its type,
- Add an Fpscr helper property on IExecutionContext along with a comment about what Fpscr is (similar to the other registers in there)
- Moved the Rcmd helpers (such as GetRegisters, GetMinidump, etc) into a dedicated Debugger class part,
- Fixed the double-collection (ToArray being called twice) in GetThreadUids & GetThread in KProcess
