Game card launch error after using the application.

[DarkMatterCore]

This is a known bug and it's related to fsp-srv. The error displayed by Horizon is not a kernel panic and doesn't get logged in the error history. It doesn't force the user to reboot the console.

Just reinserting the game card seems to do trick. But an alternate solution would be preferrable.

[DarkMatterCore]

This has been a tough nut to crack so far. I have spent hours trying to find the source of the problem (which is definitely related to fsp-srv) to no avail.

Any help on this matter will be greatly appreciated.

[DarkMatterCore]

According to some tests, it seems that the source of the problem are the calls to GetGameCardHandle (IDeviceOperator cmd 202). If it isn't called at least once, the game card launching bug isn't triggered. However, it is crucial to get any of the dump procedures to work, so we can't just skip that.

Even though the IDeviceOperator instance is closed and the fsp-srv service handle is deinitialized, I believe these game card handles are not closed properly. Ejecting and re-inserting the game card while on Horizon probably invalidates the handles that were previously opened, thus fixing the problem. That's my current guess, at least.

The original codebase from MCMrARM also had this problem. The difference is that it was only triggered after starting a partition dump. However, since gcdumptool actually relies on the root HFS0 header information from the game card to create precise HFS0 partition dumps and not complete IStorage interface dumps, GetGameCardHandle is called right when a new game card is detected.

It seems there are no IDeviceOperator calls to invalidate game card handles. I tried calling FinalizeGameCardDriver (IDeviceOperator IPC cmd 204) but instead of helping, it seems to turn off all game card I/O, making the problem even worse.

I'll keep looking into this matter. Any kind of help will be greatly appreciated, as usual.

[DarkMatterCore]

Upon further inspection, it seems the source of the problem is not the GetGameCardHandle IPC call, but rather the OpenGameCardStorage call (IFileSystemProxy cmd 30). It doesn't matter if at least a single call fails, the error can still be triggered after going back to Horizon.

I compared the argument order used in the OpenGameCardStorage call (which has remained largely untouched since the original codebase by @MCMrARM, as well as the other fs functions) with the information from SwIPC and, since the order doesn't match, I thought the code was somehow at fault in this case. I swapped the argument order and got an invalid argument error, so I'm back to zero.

Then again, any kind of help will be greatly appreciated.

[MCMrARM]

I have a note about this topic:
I have had the first OpenGameCardPartition call fail. As you can see, the code tries to call it twice (the workaroundPartitionZeroAccess function), with the first call failing with some weird error and the second one working. I do not know what exactly happens, but the first call takes a weirdly long time, so I'd assume it's remounting the card in a different mode. I imagine the crash is later caused by something trying to call a function in the 'other', previous mode again, and the thing crashes in the end. However, I'm no expert in the subject and this is merely a hypothesis.

[TechGeekGamer]

Why not just do reboot to payload?

[DarkMatterCore]

@DanielC-08 It's out of the question. In the end, it's faster to just take out the gamecard and reinsert it. A proper fix would be preferred.

[DarkMatterCore]

After asking SciresM about the potential source of this problem, he said:

Pretty sure this is because opening a gc handle reinitializes lotus comms
and so normal gamecard usage can't resume
dunno if there's a way to reset it off-hand

Fixing this issue will probably require messing with the fs sysmodule to interact directly with the gamecard ASIC.

[DarkMatterCore]

@Thealexbarney let us know about the internal nn::gcsrv interface available within fs, as well as the implementation he came up with in LibHac a few months ago. This means we finally have a proper explanation for this issue: it is related to the fact that the internal gamecard handle from the nn::gcsrv interface is never updated, which is used by HOS (specifically ns) while launching a gamecard-based program.

The gamecard handle itself is incremented if an action that deactivates the gamecard ASIC is performed. One of these actions is performing a secure -> normal mode transition, which is (sadly) done by nxdumptool right after a new gamecard is detected, in order to parse information from it that's not provided by FS IPC calls.

Furthermore, @shadowninja108 also explained that whenever a secure -> normal mode transition is required, the LAFW just resets the whole driver -- there's no real handling for this particular scenario.

The proposed solutions include:

1. Forcing ns to get a new handle before the application exits, which would most likely require a partial reimplementation of ns as part of Atmosphère -- I'm not willing to deal with custom KIPs for obvious reasons.
2. Debugging ns at runtime to inject new gamecard handle values, which honestly sounds terribly nasty.

But hey, at least we're no longer threading the unknown, which is certainly nice! Progress is progress.