Gecko dotNET Bugs and Requests

[Stuff]

My gecko driver was at 2.2.4.0 and for some reason, windows didn't want to update it. Gecko.net says it's fine, so I didn't know until now after reading this. Updating now, and it'll hopefully stop the random disconnects. Looks like Sharkbyte was having the same problem just on windows 7 64-bit, which I am upgrading to as soon as my laptop gets here. It's the only reason I found the thread. XD
------------

Anyway, moar bugs to queue:

The gct list is awkward. I think it happened because you did the gct tab speed up thing. It's hard to click on a different code without swapping them and it does some kind of loading thing when that happens and also when you check/uncheck the code. It might be related to Bully's bug.

Also with the gct tab, this is a bug(imo) and a request at the same time. I wish I said something earlier cuz this was always there, just not important. I don't want to rename the code when I click it while it's selected. If I want to rename it, I should have to double click it. It sounds silly, but I click already selected codes because the swapping thing confuses the hell outta me and I just want to make sure I'm looking at the right code. And the renaming thing also happens when I am trying to swap to codes. It bugs me now because my code list is cluttered with unnamed experimental codes that I don't bother to delete, and yeah. Pretty bootleg.
------
Another thing was the connection error message. It needs to not be centered with Gecko.net. When the message pops up it's just behind Gecko.net cuz it's set to always on top and you can't move the window to get to the popup box. Instead, you have to right click the error message in the taskbar and select move so you can move it from behind Gecko.net. The next message box with the red X too.
------

I did have a request, but I haven't posted due to the hiatus, but now I can't remember what it was. It was a big deal at the time...Well any future ideas, I'll be posting from now on so that doesn't happen. Give you a nice big queue to take care of when you get back to this. XD

[biolizard89]

Hmm, so I was trying out the latest Gecko.NET, and did some searching in F-Zero GX (USA version), and then tried to dump the RAM... got a USB Gecko error.  Here's the log:

9/18/2011 4:29:45 AM: Opened log
4:29:45 AM: Exception occured!
Exception: FTDIUSBGecko.EUSBGeckoException
FTDIInvalidReply
Message: Exception of type 'FTDIUSBGecko.EUSBGeckoException' was thrown.
Stack Trace:
   at FTDIUSBGecko.USBGecko.Dump(UInt32 startdump, UInt32 enddump, Stream[] saveStream, Dump memdump)
   at GeckoApp.MemSearch.VerifyDump(Dump checkDump, Int32 leftIndex, Int32 rightIndex)
   at GeckoApp.MemSearch.SafeDump(UInt32 startdump, UInt32 enddump, Dump memdump)
   at GeckoApp.MainForm.ToolsDump_Click(Object sender, EventArgs e)
Inner Exception:

I haven't updated my Gecko.NET install in months and months, so I'm not exactly sure when this behavior got introduced... but I've gotten at least 3 different crashes in F-Zero GX tonight, and I'm fairly confident that r115 (the previous version I was using) didn't have any of these problems.   One of the other crashes I got was when I had auto-update in the memview turned on, while the game was paused... it went up to like 500 updates per second, and then suddenly got a USB Gecko error.  Unfortunately I don't think I have a log of that one.  I'm using Neogamma beta 50, so it's a current code handler.

Is this a known bug?  Any other info I can provide to help diagnose it?

[dcx2]

Hmm, so I was trying out the latest Gecko.NET, and did some searching in F-Zero GX (USA version), and then tried to dump the RAM... got a USB Gecko error.  Here's the log:

...

I haven't updated my Gecko.NET install in months and months, so I'm not exactly sure when this behavior got introduced... but I've gotten at least 3 different crashes in F-Zero GX tonight

When you say "the latest Gecko.NET", are you using the latest test build?  I haven't updated the "official build" link in some time.  The About tab should say 0.66.8; if it doesn't, click "latest test build" in my sig.  The errors you describe appear to relate to bugs I believe I already found.  Especially the Memory Viewer thing.

Also, you didn't try to switch tabs during the Tools tab dump, right?  That would screw things up.

Another thing to keep in mind.  Gecko.NET applies patches to the debugger in order to fix bugs.  The patches are applied when you connect to the game.  However, if you connect to the game, and it crashes, and you leave Gecko.NET alone and restart the game, and then try to continue using Gecko.NET, it won't know that the game has been restarted and the patches won't be applied.  Therefore, when you restart a game, before using Gecko.NET you should click "Reconnect" so that the patches are re-installed.  If you don't click Reconnect, then you will continue to experience bugs.

Also, you should be able to go to the Tools tab and see what version of the code handler you're running.  It will be either GOSM (Gecko OS Mod), 1931, 1932, or ???

---

The gct list is awkward. I think it happened because you did the gct tab speed up thing. It's hard to click on a different code without swapping them and it does some kind of loading thing when that happens and also when you check/uncheck the code.

I think I know what you're talking about.  The 1932 code handler automatically unhooks C2/D2/F2/F4 codes when you send new codes.  It can do this because it keeps an Unhook List at the end of the code list.  As a result, the Unhook list takes up some space that would otherwise belong to codes.  Therefore, whenever you check or uncheck a code, I dump the code handler to see whether you're using the 1932 code handler (I also check for the extended codes pointer during this step).  And then if you are, I dump the code list and grab the size of the unhook list, and subtract it from the total amount of active codes available.

Unfortunately, I think for 1931 handlers, the step where I examine which handler you're using causes a glitch with the mousedown/mousedrag event for the code listbox.  I'm not quite sure how to fix this.  I think you can compensate somewhat by using arrow keys and the space bar.

I don't want to rename the code when I click it while it's selected. If I want to rename it, I should have to double click it.

I'm not sure this request is possible.  The click-renaming functionality is handled by Windows itself, and I would have to do some research to determine whether you can over-ride how the listbox base class handles clicks for renaming and such.

Another thing was the connection error message. It needs to not be centered with Gecko.net. When the message pops up it's just behind Gecko.net cuz it's set to always on top and you can't move the window to get to the popup box.

hr'm.  Probably because the messagebox should have had the main form as its parent, then it might inherit the value of the AlwaysOnTop property.  By the way, if you hold shift while you start Gecko.NET it won't try to auto-connect.  You should also be able to alt-tab to the messagebox.

[Stuff]

I'm not sure this request is possible.  The click-renaming functionality is handled by Windows itself, and I would have to do some research to determine whether you can over-ride how the listbox base class handles clicks for renaming and such.

:/ Isn't there a onClick and onDoubleClick event? That wouldn't be enough to over ride it? Anyway, I'll try changing window's clicking setting and see if it changes anything.

Therefore, when you restart a game, before using Gecko.NET you should click "Reconnect" so that the patches are re-installed.  If you don't click Reconnect, then you will continue to experience bugs.

Reminds me of a bug. If you reset without disconnecting, first it doesn't notice that you've reset, so no error message for some reason. Probably because of the loading screen fix. :/ But the main bug, after resetting, if you click Reconnect without disconnecting, the game will freeze. You can handle the exception if you do something but the message won't pop up until that something happens. idk what "something" is. I never debugged any of the errors. I always reset. >.<

[dcx2]

Some .NET controls (TextBox is well-known for this) handle some events "beneath" the .NET framework, in "Win32 land".  It can be quite difficult to intercept these things, and occasionally involves sub-classing base classes and forwarding messages and other Win32 voodoo.  It might not be hard to make double-click do a rename, but the tricky part is getting it to stop renaming after a single click.

---

Reminds me of a bug. If you reset without disconnecting, first it doesn't notice that you've reset, so no error message for some reason. Probably because of the loading screen fix. :/ But the main bug, after resetting, if you click Reconnect without disconnecting, the game will freeze. You can handle the exception if you do something but the message won't pop up until that something happens. idk what "something" is. I never debugged any of the errors. I always reset. >.<

Err....what?  You lost me.  Reset = reboot the game?

[biolizard89]

Hmm, so I was trying out the latest Gecko.NET, and did some searching in F-Zero GX (USA version), and then tried to dump the RAM... got a USB Gecko error.  Here's the log:

...

I haven't updated my Gecko.NET install in months and months, so I'm not exactly sure when this behavior got introduced... but I've gotten at least 3 different crashes in F-Zero GX tonight

When you say "the latest Gecko.NET", are you using the latest test build?  I haven't updated the "official build" link in some time.  The About tab should say 0.66.8; if it doesn't, click "latest test build" in my sig.  The errors you describe appear to relate to bugs I believe I already found.  Especially the Memory Viewer thing.

Also, you didn't try to switch tabs during the Tools tab dump, right?  That would screw things up.

Another thing to keep in mind.  Gecko.NET applies patches to the debugger in order to fix bugs.  The patches are applied when you connect to the game.  However, if you connect to the game, and it crashes, and you leave Gecko.NET alone and restart the game, and then try to continue using Gecko.NET, it won't know that the game has been restarted and the patches won't be applied.  Therefore, when you restart a game, before using Gecko.NET you should click "Reconnect" so that the patches are re-installed.  If you don't click Reconnect, then you will continue to experience bugs.

Also, you should be able to go to the Tools tab and see what version of the code handler you're running.  It will be either GOSM (Gecko OS Mod), 1931, 1932, or ???

Yes, I'm on 0.66.8.  I did not switch tabs during the dump.  However, I just tried the old version which worked fine for me before, and I got a crash there too.  So now I'm wondering if my USB Gecko is screwed up.  I have a spare USB Gecko, so I'll try it out and report back on whether that fixes it.

[Stuff]

:/ well don't sweat it. It's really annoying, but even more annoying is that swapping glitch. I'll have to update gecko os.

Err....what?  You lost me.  Reset = reboot the game?

Yeah. Rebooting the game. I forgot there was a reset button. lol. idk if it happens there too. I could check. So rebooting the game without disconnecting the gecko.net, gecko.net doesn't notice, and clicking reconnect without first disconnecting freezes the game. No cheats. Maybe inf rage cuz I'm too lazy to delete the gct. But that's not a C2 code. Disconnecting first clears the funkiness.

Ways I would imagine you could fix this would be to make it check for the patches on every connect(which I'm not too exited about. But I believe it has to do with it expecting the patches to be there.), or make it notice that you've turned of the game(which would probably bring back the loading bug. No liek :/)

Another thing was if you BP, and disconnect, you can't unpause the game when you reconnect. It's not a big issue since my random disconnects is fixed, but it was annoying before when I would try to follow some asm and suddenly I disconnect. I'd have to reset and it doesn't catch that exception. But it still haunts me. The other day I was in a BP for a while and forgot about it. Then I clicked disconnect turned around and "ffffff >.<". I tried to reconnect and run game, but nope. It was paused forever.

What do you mean by latest test build? You released 0.66.8.

[dcx2]

:/ well don't sweat it. It's really annoying, but even more annoying is that swapping glitch. I'll have to update gecko os.

Actually, there's no real motivation to use 1932.  It has a significantly smaller code list, and the two primary fixes (unhooking C2 codes, and debugging code handler crashes) are handled via GCT Code Undo and a debugger patch, respectively.  1932 was useful before I started patching debuggers, but these days loaders with 1931 are the way to go.

Yeah. Rebooting the game. I forgot there was a reset button. lol. idk if it happens there too. I could check. So rebooting the game without disconnecting the gecko.net, gecko.net doesn't notice, and clicking reconnect without first disconnecting freezes the game.

Very odd.  I know for a fact that it doesn't happen for me like that.  I have reconnected after a crash several times.

I do know that during boot, the USB Gecko sends a byte to the PC.  I have a special (Visual Studio) breakpoint in the source code when running with the VS Debugger attached to Gecko.NET.  It is for catching left-over bytes like that.  But it discards any bytes it wasn't expecting, and the breakpoint isn't triggered if no debugger is attached to Gecko.NET.

Ways I would imagine you could fix this would be to make it check for the patches on every connect(which I'm not too exited about. But I believe it has to do with it expecting the patches to be there.)

I'm pretty sure it already does this.  Immediately after connecting, I dump the code handler and search for the checkexisend routine.  I use the address of checkexisend to determine which version of the code handler you're running.  Then I check exireceivebyte, which gets the rx debugger patch, to see whether the handler has been patched or not.  If exireceivebyte is unpatched, I poke all the patches in a very specific order to prevent any crashes, because pokes are always invalidated and flushed, which is important when modifying ASM that might be executed soon.

Another thing was if you BP, and disconnect, you can't unpause the game when you reconnect.

I'm not sure what you mean here.  If you're at a BP, with the game currently frozen?  If you set a BP, but it hasn't been hit yet? 

What do you mean by latest test build? You released 0.66.8.

I refer to "official builds" as a build which is relatively stable, and gets promoted to the first post of the release thread with a summary of the major changes since the last official build.  I refer to "test builds" as builds which are posted at the end of the release thread.  They're like beta builds; they're stable enough for me but I want some other people to bang on it to see if anything breaks.  You can see this reflected in my sig; the "release thread" points to the first post and the "latest test build" points to the last post.

---

Yes, I'm on 0.66.8.  I did not switch tabs during the dump.  However, I just tried the old version which worked fine for me before, and I got a crash there too.  So now I'm wondering if my USB Gecko is screwed up.  I have a spare USB Gecko, so I'll try it out and report back on whether that fixes it.

Hm.  I was pretty sure I fixed the problem that was causing this issue.  I don't think it would really be a USB Gecko issue...if the USB Gecko was bad you'd wouldn't even get a connection.

Others had the same issue where Memory Viewer auto-update would cause a freeze.  But that was fixed in between the last official and the most recent test build.  That's why I wanted to verify that on the Tools tab, that it says "Driver Good" and "Handler: 1931"

[Stuff]

Very odd.  I know for a fact that it doesn't happen for me like that.  I have reconnected after a crash several times.

I do know that during boot, the USB Gecko sends a byte to the PC.  I have a special (Visual Studio) breakpoint in the source code when running with the VS Debugger attached to Gecko.NET.  It is for catching left-over bytes like that.  But it discards any bytes it wasn't expecting, and the breakpoint isn't triggered if no debugger is attached to Gecko.NET.

I'll get back to you on this. It might be related to something else. I would've made a video to demonstrate it, but it didn't freeze on reconnect. Gecko.net didn't notice the disconnect, though.

When you hit a BP and the game freezes, if you disconnect for whatever reason, you can't unpause when you reconnect. Another fun fact is that you can step into once. And then you can't step into anymore. Clicking the button makes the asm "jiggle" like it was gonna go to the next one but it can't.

You might want to classify 2.2.4.0 as something other than "Good". Updating the driver seemed to stop the random disconnects. So it's no good. lol. Windows update didn't want to update it, though. Not even on Windows 7. W7 installed 2.2.4.0 automatically and said it was the best match for this device. No need to update. :/

What is the utilities for? I can browse to them and select them, but for nothing. I thought it would've let me open pyiiasmh by clicking a button there, but it just becomes a non link without adding extra functionality. It does have a button for tracer. Whatever that is. But nothing else.

[dcx2]

You might want to classify 2.2.4.0 as something other than "Good". Updating the driver seemed to stop the random disconnects. So it's no good. lol. Windows update didn't want to update it, though. Not even on Windows 7. W7 installed 2.2.4.0 automatically and said it was the best match for this device. No need to update. :/

I don't label 2.2.4.0 as "good".  It should only accept a driver with a version at or above 2.8.14.0.  Gecko.NET checks the driver version when connecting to the USB Gecko, so if you aren't connected it might show "Driver Good" when it's not.

Windows Update rarely has the latest driver for any hardware.  You will have to go to the manufacturer's web site in order to get the latest version.  http://www.ftdichip.com/Drivers/D2XX.htm  They have a beta version, 2.8.17, but 2.8.14 is WHQL signed so I would go with that one.

What is the utilities for? I can browse to them and select them, but for nothing. I thought it would've let me open pyiiasmh by clicking a button there, but it just becomes a non link without adding extra functionality. It does have a button for tracer. Whatever that is. But nothing else.

ASMWiiRD and PyiiASMH can be launched by right-clicking a code in the listbox on the GCT tab.  It checks to see if an instance of ASMWiiRD or PyiiASMH is already open.  If so, it brings it to the front; if not, it launches one.

Then, for ASMWiiRD, it will automatically copy and paste the full contents of the code into the appropriate textbox and have it converted to ASM, using some magic win32 tricks.

For PyiiASMH, because it's built in Python I can't perform those win32 tricks.  So instead, the contents of the code are put into the clipboard.  You will have to paste and convert on your own.

The Pointer search is required for the Pointer tab to work.

Tracer is a SNES disassembler.  It's useful if you're hacking SNES VC games.  You can pipe the output of Tracer into the RiiTracer app that I package with Gecko.NET, too.

[biolizard89]

Yes, I'm on 0.66.8.  I did not switch tabs during the dump.  However, I just tried the old version which worked fine for me before, and I got a crash there too.  So now I'm wondering if my USB Gecko is screwed up.  I have a spare USB Gecko, so I'll try it out and report back on whether that fixes it.

Hm.  I was pretty sure I fixed the problem that was causing this issue.  I don't think it would really be a USB Gecko issue...if the USB Gecko was bad you'd wouldn't even get a connection.

Others had the same issue where Memory Viewer auto-update would cause a freeze.  But that was fixed in between the last official and the most recent test build.  That's why I wanted to verify that on the Tools tab, that it says "Driver Good" and "Handler: 1931"

It did indeed say Driver Good and showed 1931 handler.  It occurs to me that I'm on a new laptop and I'm not 100% sure that the FTDI driver is the latest.  But since Gecko.NET said "Driver Good" I didn't consider that that could be an issue.  Based on what you and Stuff said, I'll check the driver version and I'll see if it needs an update.

EDIT: It's 2.8.14.0.  So I doubt it's the driver.

[Bully@Wiiplaza]

when no usb gecko is connected and one moves to the "tools" tab there´s a button that says "update driver".
Clicking it gives an error message instead of guiding one to a site where the newest driver can be found. (Unhandled error, bla bla)

---

I hate those code sending bugs (gecko.net 0.66.8.)
It is NEVER my fault that it crashes.

Most of the games I tried just freeze when I send a code that doesn´t crash when it is poked (e.g. 04 code).
It then shows some .word instruction (or sometimes valid ASM that crashed with legit codes) as crash breakpoint.
Also, if I set a XBP on moving assembly and it then moves -> game pauses and is crashed (tested on Mario Sports Mix):
[spoiler]
800028D0:  00000000   .word   0x00000000

 CR:88222888  XER:00000000  CTR:81601AA4 DSIS:00000000
DAR:00000000 SRR0:800028D0 SRR1:00089032   LR:81602668
 r0:00000001   r1:805D8C58   r2:805CA980   r3:00000000
 r4:80ACC2A0   r5:81640000   r6:81630000   r7:00000004
 r8:636F6E00   r9:000000E0  r10:805D8D28  r11:805D8CA8
r12:81601AA4  r13:805C87C0  r14:00000000  r15:00000000
r16:00000000  r17:80ACE740  r18:00000000  r19:80ACE740
r20:00000000  r21:00000000  r22:00000000  r23:80ACE740
r24:81637368  r25:80B7A040  r26:81636CB8  r27:80ACC728
r28:816375B0  r29:81640E30  r30:81641158  r31:43300000[/spoiler]
[spoiler]
800028C8:  04ACC878   .word   0x04acc878

 CR:88200888  XER:00000000  CTR:81601AA4 DSIS:00000000
DAR:00000000 SRR0:800028C8 SRR1:00089032   LR:81602668
 r0:00000001   r1:805D8C58   r2:805CA980   r3:00000000
 r4:80ACC2A0   r5:81640000   r6:81630000   r7:00000004
 r8:636F6E00   r9:000000E0  r10:805D8D28  r11:805D8CA8
r12:81601AA4  r13:805C87C0  r14:00000000  r15:00000000
r16:00000000  r17:80ACE740  r18:00000000  r19:80ACE740
r20:00000000  r21:00000000  r22:00000000  r23:80ACE740
r24:81637368  r25:80B7A040  r26:81636CB8  r27:80ACC728
r28:816375B0  r29:81640E30  r30:81641158  r31:43300000
[/spoiler]
The game doesn´t recover.

Another example, I sent the following code (Mario Sports Mix again)

284CDDA2 FDFF0200
04ACC878 00000100
04ACC8A0 07000100
04ACC8C8 07000100
E0000000 80008000

INSTANT freeze. (No crash BP, gecko.net disconnects from the game)
The button activator obviously wasn´t pressed, so the code didn´t do anything.

However:
This bug doesn´t occur on all games, but on too many.

---

In opposite to these crashes, everything works fine with WiiRd GUI (and older Gecko.net builds).
It must be one of the patches... if a patch crashes, it definetely missed the point. :-\

[Stuff]

when no usb gecko is connected and one moves to the "tools" tab there´s a button that says "update driver".
Clicking it gives an error message instead of guiding one to a site where the newest driver can be found. (Unhandled error, bla bla)

This didn't happen to me. It takes me to the site with no problems.

The crashing thing...it might be your wii. I know that sounds weird and maybe I should just try another game, but before that, I don't experience that in monster hunter. Except for sometimes with 1 code that I can't share. I thought the issue was solved, but I was having trouble with it the other day. It was a memory copy code. Anyway, I used the usbgecko on my friend's wii, and at some point I was stuck in a black screen. I didn't know what happened, but I immediately said "your wii is bootleg". I was testing some C2 codes and looking at his friends list(s) in memory cuz he has more than 1 capcom id. I just wanted to see if they are all in memory. But...I messed up with his friend requests and ended up making him friend me in the same slot as his 1st id and with the same character >.>. And the crashing thing just f***ed the mood up. But I don't think this is the same crash. Yours is as soon as you send codes. I don't remember if I sent more codes during the crash, but that was out of nowhere and unexpected and doesn't happen on my wii even with my old unstable connection when I had the old drivers.

Is it possible to use wild cards in memview searches searches? If so, how? If not, that would be a nice feature. The standard wild cards would be nice. # for any number(in ansi), ? for any character(I think), and * for any string. This way I could do a hex search for ??????03??????02??????03??????01??????01 and whatnot and find a 20 byte string with 03 on the 4th, 02 on the 8th and so on. Because I have no idea what I'm looking for except for the fact that the last byte might be an item's rarity.

[Bully@Wiiplaza]

well, sometimes it works again on some games with code sending.
Pretty weird...

@Stuff:
MH3 is fine, only some specific games have code sending crashing issues.
"CoD Black Ops Zombie Mode" "Mario Kart Wii" "Mario Sports Mix" are critical with codes sending for me.

Okay, the "update driver" link does work.
Probably my fault.

[Stuff]

I know a while back I asked for dumps to be "read only" in the disassemble tab, but now I've found an awesome bug. Assembling doesn't change the..assembly. >.> This is what happened

originally:
8011F924:  A87D083C   lha   r3,2108(r29)
8011F928:  7C7B1850   sub   r3,r3,r27

So I assembled this:
8011F928:  38600000   li   r3,0

Tail wasn't coming off. I didn't understand. So I step into:

8011F924:  A87D083C   lha   r3,2108(r29)      ##r3=35
8011F928:  38600000   li   r3,0                 ##r3=26 (wuuuuut? shouldn't it be 0?!) r27 happens to be 9

Well that was bootleg. I thought maybe the game was being stubborn so I sent this code:
0411F928 38600000
Tail came off from my weakest hit which was definitely < 26 dmg. I can't understand how that works. A change in asm fails but a change in asm doesn't?