Gecko dotNET Bugs and Requests

[dcx2]

For mem1 it happens everytime at 4%, once the connection is lost, i can not reconnect, unpluging and replugging the usb cable does not help,and am forced to reboot the wii.

Very odd.  What if you change the dump start/end to 80000000/80001000?  This is less than one packet.

For mem2 it happens at 2%, i was able to reconnect and unpause the game, but the search fields were all greyed out so i had to close/reopen gecko.net, to try again. Same thing at 2% again

If you reconnect and the fields are greyed out, press reconnect again and they should become enabled.

Also...can you try using the Dump on the Tools tab, and see if it can get a full dump?

Also, do you have the same problem with the 0.64 build?  That has no search verification, so that would rule one thing out.

I am not sure, all I do is put it on memory viewer, and within 3 seconds of ticking auto-update, the game pauses and then disconnects. It also does this if auto-update is not ticked but I click the scroll bar area quickly to change pages.

If you scroll too quickly?  What about if you click the Update button quickly and repeatedly?

I do this anytime I get a disconnection, I almost always have to do this if the usb cable is plugged in before I start gecko.net, it tells me there is no connection try again, so I have to unplug it, plug it back in click yes then it works.

That's odd.  I know it complains if there is no game running on the Wii, but once the game is running it starts right up without requiring any unplugging.

This makes me believe that there's something odd with your drivers.  Can you do this?  device manager -> right click the USB Gecko (might be under Ports?) -> properties -> driver tab -> driver details button.  What are the driver file names, providers, and versions?

[strakn]

Very odd.  What if you change the dump start/end to 80000000/80001000?  This is less than one packet.

I did two test where I started with 80000000/80001000 then moved up to 80000000/80002000 and then 80000000/80003000 and so on.
The first time searches all worked until I hit 80000000/80005000
The second time searches all worked unitl I hit 80000000/80009000

Also...can you try using the Dump on the Tools tab, and see if it can get a full dump?

I tried to take a couple dumps of mem1, once it got to 100% but then gecko.net stop responding then connection to usb gecko was lost.
second try It only made it to 20% before not responding then disconnecting.

This is the log from one of those dump attempts
[spoiler]4:45:31 PM: Exception occured!
Exception: FTDIUSBGecko.EUSBGeckoException
FTDIInvalidReply
Message: Exception of type 'FTDIUSBGecko.EUSBGeckoException' was thrown.
Stack Trace:
   at FTDIUSBGecko.USBGecko.sendfail(EUSBErrorCode error)
   at FTDIUSBGecko.USBGecko.Dump(UInt32 startdump, UInt32 enddump, Stream[] saveStream, Dump memdump)
   at FTDIUSBGecko.USBGecko.Dump(UInt32 startdump, UInt32 enddump, Stream saveStream)
   at GeckoApp.MainForm.CUSBGecko_Click(Object sender, EventArgs e)
Inner Exception:
4:45:32 PM: Exception occured!
Exception: FTDIUSBGecko.EUSBGeckoException
FTDIInvalidReply
Message: Exception of type 'FTDIUSBGecko.EUSBGeckoException' was thrown.
Stack Trace:
   at FTDIUSBGecko.USBGecko.sendfail(EUSBErrorCode error)
   at FTDIUSBGecko.USBGecko.Dump(UInt32 startdump, UInt32 enddump, Stream[] saveStream, Dump memdump)
   at FTDIUSBGecko.USBGecko.Dump(UInt32 startdump, UInt32 enddump, Stream saveStream)
   at GeckoApp.MainForm.CUSBGecko_Click(Object sender, EventArgs e)
Inner Exception:
4:45:33 PM: Exception occured!
Exception: FTDIUSBGecko.EUSBGeckoException
FTDIInvalidReply
Message: Exception of type 'FTDIUSBGecko.EUSBGeckoException' was thrown.
Stack Trace:
   at FTDIUSBGecko.USBGecko.sendfail(EUSBErrorCode error)
   at FTDIUSBGecko.USBGecko.Dump(UInt32 startdump, UInt32 enddump, Stream[] saveStream, Dump memdump)
   at FTDIUSBGecko.USBGecko.Dump(UInt32 startdump, UInt32 enddump, Stream saveStream)
   at GeckoApp.MainForm.CUSBGecko_Click(Object sender, EventArgs e)
Inner Exception: [/spoiler]

Also, do you have the same problem with the 0.64 build?  That has no search verification, so that would rule one thing out.

This does not happen with 0.64 through 0.64.3
It does happen with 0.64.4 through 0.64.7

This makes me believe that there's something odd with your drivers.  Can you do this?  device manager -> right click the USB Gecko (might be under Ports?) -> properties -> driver tab -> driver details button.  What are the driver file names, providers, and versions?

I have already uninstalled and reinstalled the drivers many times, once using your method through the command line (It was me who started the thread "USB Gecko not finding Search Values) below is what is installed currently.
ftdibus.sys, FTDI Ltd., 2.08.02
ftbusui.dll, FTDI Ltd., 1.2.0.1
ftd2xx.dll, FTDI Ltd., 3.02.00
FTLang.dll, FTDI Ltd., 1.5.0.1

**Good News
All of the latest versions (0.64.4 and up are working perfectly on my windows xp machine.
I dont know why my Vista and Win7 machines do not work I can only speculate maybe its drivers (Xp is using older preinstalled 2.04.xx drivers) or .NET Framework (xp is still at 2.0 while vista and 7 are at 4.0)

Maybe a few others can post how the latest versions of gecko.net are working for them and what os they are using.

[dcx2]

I develop Gecko.NET on Windows XP SP3.  I have the same driver files as you, but my versions are different: ftdibus.sys (the actual kernel-mode driver) is 2.06.02.  ftd2xx.dll (user-mode interface driver) is 3.01.19.  FTLang.dll (probably some internationalization library..?) is 1,4,0,1.  Yes, those are commas.

The timing of the bug is odd.  Major USB Gecko changes were made in .3, and yet there was no problem for you.  However, .4 only modified the searching, not the USB Gecko interface.

I have a theory.  I'll get you a custom build to see if it resolves this problem.  Thanks for the extra effort you put into finding which version introduced the problem.

[spoiler=my theory]I did make a somewhat hacky move with search verification.  Because of the extra accidental byte in the stream, there's actually one byte left over in the transfer buffer that hasn't been read.  I didn't want this leftover byte to interfere with the next command, so I tried to consume it.

However, there is a cost to consuming a byte.  If there is no byte to consume, you must wait until the transfer times out.  This meant that each time you finished dumping a block, you would sit uselessly for 500 ms before asking for the next block.

To mitigate this cost, I tried to do a "fast read" which temporarily reduced the timeout to 5 ms, read, and then restored the normal timeout.  This appeared to work without any problems on my machine, so I left it in.  I figured, 24 blocks * 5ms = 120 ms, no one should notice the slow down, it keeps the transfer bug from screwing other things up, and it didn't cause any problems...so it was a fair trade.[/spoiler]

[strakn]

A quick test of the r123 and r124 you linked me to show no difference.

On Vista, searching, full mem dumping and memory viewer (w/auto update, fast scrolling or fast clicking of update) all cause the game to freeze, connection to be lost, and unable to reconnect until wii has been reset.

On Win7 searching and dumping work (I did notice once a disconnect on a search but it reconnected and continued), but the same problem using memory viewer as on Vista.

Also as a note, Vista and Win7 are both using the exact same driver files and version numbers, I listed previously.
I will track down an older version of the drivers and see how they work.

EDIT:

I upgraded the drivers to 2.08.12 on both the Vista and Win7. This fixed the bug in memory viewer. So now the Win7 machine is working perfectly.

I installed a very old version 2.02.04 on Vista, and the bug with the memory viewer is also not present, however searching and full mem dump still not possible on any driver version for Vista machine.

Put 2.08.02 back on Vista and checked memory viewer, and it crashed with auto update on (just confirming its 2.08.02 causing the issue with memory viewer)

As a side note 2.08.02 was the version that the Win7 machine downloaded automatically from windows update, but the newer version is on the ftdi website, it just hasn't been WHQL Certified yet.

[dcx2]

On Vista, searching, full mem dumping and memory viewer (w/auto update, fast scrolling or fast clicking of update) all cause the game to freeze, connection to be lost, and unable to reconnect until wii has been reset.

On Win7 searching and dumping work (I did notice once a disconnect on a search but it reconnected and continued), but the same problem using memory viewer as on Vista.

:eek: ???  This makes no sense.  Let me make sure I got all this...

-Everything works on XP.
-Nothing works on Vista.
-Everything but MemView works on 7.

I keep forgetting to ask, what's the 64-bitness of your various systems?

hmmm....I trimmed the timeout from 2000 to 500 to make some things snappier...I wonder if the shorter timeout confuses the driver somehow?

EDIT:

Just saw your edit.

-Everything works on XP
-With 2.08.12, everything works on 7
-With any driver, dumping never works on Vista (r123 and r124?)
-With 2.08.02, MemView doesn't work on Vista or 7

[strakn]

I keep forgetting to ask, what's the 64-bitness of your various systems?

All 32 bit OSs

The Vista machine has an Athlon 64 dual core cpu(s)

-Everything works on XP
-With 2.08.12, everything works on 7
-With any driver, dumping never works on Vista (r123 and r124?)
-With 2.08.02, MemView doesn't work on Vista or 7

Yes

XP drivers are stock - 2.04.xx

r124 same result as r123 and 0.64.4+

[hetoan2]

I am also getting these issues on the latest version. not fun. Occasionally, the gecko will even control my mouse and other system inputs. After the game has crashed (whenever you even attempt to go into disassembly tab), and GeckoDotNet has been forcefully shut down (exiting the window will leave process still open), the gecko will generate huge outputs of data to geckoreader. They are nonsensical, just random bytes.

[dcx2]

WTF?

Are you using Vista?

Are you using the latest FTDI driver?

[hetoan2]

Windows 7 64 bit :S


I'll look into those FTDI drivers.

[hetoan2]

2.08.12 made everything work, before this i was using 2.04.x, which microsoft says is the most up to date ._.

EDIT: nevermind, that just fixed somethings. Just got a random crash when trying to do autoupdate in memviewer :\

[ropers]

2.08.12 made everything work, before this i was using 2.04.x, which microsoft says is the most up to date ._.

EDIT: nevermind, that just fixed somethings. Just got a random crash when trying to do autoupdate in memviewer :\

same here i got the newest driver 2.08.0 im on windows 7 32 bit it when i goto mem viewer it crash
and i have to restart my computer to get it to work.

[dcx2]

Make sure you're using 2.08.12, from the FTDI website.  Windows Update will not give you the latest driver.  Go here to get them.  http://www.ftdichip.com/Drivers/CDM/CDM20812.zip

Use this procedure to verify what version is installed.  Note: in these screenshots, I have 2.06.02, but I'm using XP, which has not had any problems yet.

[ropers]

ok i got the new divers now ill let you know if it helps

[Deathwolf]

The new Gecko dNet works fine on Wii games but it freez Gamecube games during hooking the game after patching the hook address 8034b09c. Why is that? However, the Pointer Search tab is great too. Thanks a lot.

[dcx2]

ropers - did the new drivers resolve your problem?

deathwolf - What Windows are you using?  Are you playing GameCube games with Gecko OS Mod?  I've never tried it, so I don't if it would work.