CosmoCortney
Hacker
Jr. Member
Karma: 8
Posts: 85
Mensch-Maschine, halb Wesen & halb Ding
|
|
« on: May 06, 2013, 10:04:12 AM » |
|
hello, i'm trying to to do a memory dump when a freeze occured. i can create a log file (with gecko reader) and see the breakpoints points (using Wiird). but the connection to the usb gecko gets lost when the game is freezed. i can't dump the memory anymore. same for Gecko dotNET.
is there an easy way to solve this problem?
|
|
« Last Edit: May 06, 2013, 11:33:48 AM by CosmoCortney »
|
Logged
|
|
|
|
Bully@Wiiplaza
Hacker
Legendary Member
Karma: 93
Posts: 1853
|
|
« Reply #1 on: May 06, 2013, 07:47:34 PM » |
|
No. If you freeze AND lose connection you can´t do anything anymore.
|
|
|
Logged
|
|
|
|
dcx2
Computer Engineer
Moderator
Legendary Member
Karma: 165
Posts: 3468
|
|
« Reply #2 on: May 07, 2013, 01:58:14 AM » |
|
If the game freezes and you lose connection, it means the Gecko code handler is no longer being executed. There are two ways for this to happen.
1) Your game has some sort of code protection that causes an infinite loop. The instruction would look a lot like "b 0" or something similar, and the CPU will no longer move forward. Most games don't have this protection, so if you check the thread for the associated game you'll probably find out whether it was this or not. (my first instinct is to guess that it's not)
2) The freeze was caused by an exception and you don't have the Gecko interrupt handler patched in for that exception. Typically if you're using recent versions of Gecko.NET, when you connect to a game, a series of patches are applied to memory. Some of these patches install the Gecko interrupt handler for additional exceptions, like an ISI exception (I think there was another one or two).
Notably, exceptions are just breakpoints. One of the technical issues with WiiRDGUI is that if you connect to a game and then cause a crash, you will lose communication because WiiRDGUI has not yet patched the interrupt handlers. Therefore, pre-Gecko.NET, every time I connected I would set an XBP on 800018A8 so that way the interrupt handler would get installed. Once that's installed, WiiRDGUI can catch a few exceptions (notably, DSI)
Again, these interrupt handlers must be installed BEFORE the game crashes. That way, when the game crashes, control gets directed to the Gecko code handler and we can inspect memory and even un-crash the game.
|
|
|
Logged
|
|
|
|
CosmoCortney
Hacker
Jr. Member
Karma: 8
Posts: 85
Mensch-Maschine, halb Wesen & halb Ding
|
|
« Reply #3 on: May 07, 2013, 03:20:11 AM » |
|
the debugger was already connected to the game before it freezed. so.. if i set the XBP on 800018A8 and the exception occures, i still can do a memory dump, because the interrupt handler is installed (and does not "lose" its functionality during the freeze)? if yes, how do i set the handler?
and what exactly is that pre-Gecko.NET (another releaso of Gecko dotNET?)?
|
|
|
Logged
|
|
|
|
dcx2
Computer Engineer
Moderator
Legendary Member
Karma: 165
Posts: 3468
|
|
« Reply #4 on: May 07, 2013, 03:25:46 AM » |
|
Just being connected isn't enough if you use WiiRDGUI, you need to set a breakpoint at some point in time after the game is loaded. 800018A8 is a nice breakpoint, it's the first instruction of the code handler so it's guaranteed to execute. You don't need to do that with Gecko.NET, because it's one of a couple things that happen automatically.
WiiRDGUI doesn't patch all the exceptions, so it depends on what's causing your crash. If it's a DSI exception, like a bad memory access, WiiRDGUI can catch that once the handler is installed. But if it's an ISI exception, like branching to a bad address, only Gecko.NET catches that.
|
|
|
Logged
|
|
|
|
megazig
Hacker
Full Member
Karma: 4
Posts: 127
|
|
« Reply #5 on: May 07, 2013, 05:57:33 AM » |
|
and if it's an OSPanic it won't hook anymore because PPCHalt is just a deadloop
|
|
|
Logged
|
|
|
|
Bully@Wiiplaza
Hacker
Legendary Member
Karma: 93
Posts: 1853
|
|
« Reply #6 on: May 07, 2013, 07:43:32 AM » |
|
How come the codehandler crashes a lot when I send definite non-faulty codes? Most of the time it can recover but sometimes it doesn´t after confirming to fix a codehandler crash and I have to restart.
Also happened on identical lists being sent again while using undo's and everything.
The breakpoint either shows a li or stw instruction within the codehandler memory. High likely you´ll know.
Once in a blue moon, it even loses connection while the game is frozen due to "sending codes".
|
|
« Last Edit: May 07, 2013, 07:53:02 AM by Bully@Wiiplaza »
|
Logged
|
|
|
|
dcx2
Computer Engineer
Moderator
Legendary Member
Karma: 165
Posts: 3468
|
|
« Reply #7 on: May 08, 2013, 12:14:42 AM » |
|
Without telling me which li or stw, or showing me the codes you sent, I can't say. Had I run into such a problem I would have fixed it.
There's a chance it's the undo codes. Those aren't exactly the most stable.
|
|
|
Logged
|
|
|
|
megazig
Hacker
Full Member
Karma: 4
Posts: 127
|
|
« Reply #8 on: May 08, 2013, 12:21:43 AM » |
|
it was a deadloop that caused the codehandler to not be hooked anywhere anymore.
code called an OSPanic that print out some debug info that got used as bad exception info. then it goes into PPCHalt which just "b 0"
|
|
|
Logged
|
|
|
|
dcx2
Computer Engineer
Moderator
Legendary Member
Karma: 165
Posts: 3468
|
|
« Reply #9 on: May 08, 2013, 12:26:31 AM » |
|
I think Bully is talking about something different. He's talking about trying to recover from a crash and failing.
Although you bring up a good point. It's probably not a bad idea to replace all dead loops with traps instead. This way the Gecko code handler stays hooked.
EDIT:
BTW, all that reset during a code handler crash does is reset the instruction pointer to just after pushing all the registers. it assumes you already fixed whatever caused the crash. It doesn't actually "fix" anything on its own, other than getting the PPC execution context where it belongs. You should only see this option if your crash happens in the code handler, which is usually a sign of a code handler bug or a bad code (like a 14 write to a bad pointer)
|
|
« Last Edit: May 08, 2013, 12:32:35 AM by dcx2 »
|
Logged
|
|
|
|
Bully@Wiiplaza
Hacker
Legendary Member
Karma: 93
Posts: 1853
|
|
« Reply #10 on: May 08, 2013, 05:45:04 AM » |
|
Like stated above, the code handler crashes quite often for me while using undos. It´s quite random.
Here´s where it usually breaks: 80001904: 3AA00000 li r21,0
No registers, sorry. Not at my Wii right now.
If it then asks to reset the code handler, I directly say "yes" and click "run game". It´s fixed. Well, mostly. The game may not run anymore in the last step if "unlucky". I can still do everything but the game won´t unfreeze no matter what. Setting a bp, nothing.
It definitely has to do with the undos, it does not occur without.
|
|
« Last Edit: May 08, 2013, 05:49:52 AM by Bully@Wiiplaza »
|
Logged
|
|
|
|
dcx2
Computer Engineer
Moderator
Legendary Member
Karma: 165
Posts: 3468
|
|
« Reply #11 on: May 09, 2013, 01:38:44 AM » |
|
I'm pretty sure 80001904 is the address that the code handler is reset to whenever there's a crash in the code handler. 80001904 is essentially the first instruction after the code handler pushes the current register values onto the stack.
|
|
|
Logged
|
|
|
|
|