Are Wii U eshop digital downloads supported?

[d18-builder]

Hi,

I have tried to debug 3 games purchased/free from the eshop. All 3 have the similar DSI error with registers dump upon loading.

I am on 5.5.3, running HBL via the browser exploit.

These are the steps I followed:

1. Spawned HBL via the browser exploit.
2. Loaded diibugger.elf
3. Black screen come with diibugger options and I selected “exit to Home without connecting”
4. Ran the eshop game which I installed

Now the DSI error comes all the time.

Any special steps for eshop games?

Best Regards

[kinnay]

Hi, I just tested it on one of my own eShop games (Captain Toad) and it worked fine. Which games did you try to run? I can try to run them under the debugger myself, so we can see if the problem is caused by the game or by something else.

[d18-builder]

Hi,

If you can try Pokemon Rumble USA for example. It cannot work for this eshop game at all.

I can debug it via other tools like jam1garner/diibugger-hbl + diibugger-cli.py but I would prefer a non CLI version.

And I can dump Memory via JGecko U.jar + TCP Gecko as well.

Best Regards

[kinnay]

Pokemon Rumble U is not a free game. You said that you also tried to debug a free game. Which game is this? I don't really want to buy a game just to test the debugger.

[d18-builder]

Hi,

What I meant by "free" is actually π-rated (sorry)... I did not want to post π-racy related topics in your github.

So what happened was, I first tried to debug a "free" (π-rated) copy of Pokemon Rumble and I got that DSI error message. I thought maybe the SigPatches was causing the errors and so I bought the same game legitimately from the eshop only to find out that I got the same errors as before.

Again sorry to mislead you but none of the games I tried were actually "free". The same DSI errors appear for both the π-rated and the legitimate copy anyways. I hope that clears up everything.

Best Regards,

On Sat, Feb 15, 2020 at 6:37 PM Yannik Marchand [email protected] wrote:

Pokemon Rumble U is not a free game. You said that you also tried to debug a free game. Which game is this? I don't really want to buy a game just to test the debugger.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Kinnay/Wii-U-Debugger/issues/2?email_source=notifications&email_token=AOQQQKL3257WRPELESWJKOLRC7AVZA5CNFSM4KSOZIZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL3HHVQ#issuecomment-586576854, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOQQQKLRFGAKQTTUNSEVZDTRC7AVZANCNFSM4KSOZIZQ .

[kinnay]

Ah, makes sense. Could you show me the exception details? I might be able to see what's crashing. It's difficult for me to figure out the issue if I can't reproduce the error though.

[d18-builder]

Here you go:

https://ibb.co/cDpdDfw

Steps Done:

1. SigPatcher2HBL (Version 0.1 by dimok)
2. Wii-U-Debugger
3. "Install and return to system menu"
4. Pressed the home button to continue without debugger...
5. Tried to run Pokemon Rumble U (USA).
6. Got DSI Exception.

[kinnay]

Looks like memory allocation for the screen buffer failed. Maybe I should add a check to my memory allocation functions, such that it prints a useful message to the screen when memory allocation fails instead of letting it crash. That wouldn't solve the problem though.

I have a theory about what might be causing the memory allocation to fail:

• Some games export a __preinit_user function that's executed even before the main function of the game is called.
• Many games allocate all available memory from the system when they're launched and use their own heaps to allocate memory later on.
• I think the homebrew launcher executes homebrew applications right before the main function of the game is called, but after __preinit_user is called.
• If a game allocates all available system memory in __preinit_user there might be no more memory left for the debugger.

Pokemon Rumble U might be a game that allocates its memory in __preinit_user. If my theory about the crash is correct, the best solution would probably be to apply a patch in coreinit.rpl that lets the debugger allocate memory before __preinit_user is called.