Gecko dotNET Bugs and Requests

[giantpune]

It happens pretty consistently if i search mem2 and the returned matches are only like 1 or 2 items.

EDIT:

Ok, so I just started recording my desktop and messing with geckoDotNet trying to record the crash so you could reproduce it.  I managed to record it, and this time i spent more time dicking around in the "this program has crashed..." dialog.  It seems it does provide more information than I thought before.  Basically it looks like the exact same issue that was making it crash before ( diss.bin is used by another process ).  But this time it is the .log file that is used by another process.

Anyways, heres the video so you can see if it happens for you.
http://www.multiupload.com/KB8V3VQCUA

Whenever this happens, it turns out that i cannot even save to the .log file using notepad.  I opened up the taskmanager, and there are a couple different instances of geckodotnet.exe running.  I think that one or more of these is a zombie of an instance of the program which i tried to close.  And it still has a lock on the diss.bin & .log file, which is causing the crash.  Is there a way for geckodotnet to detect if there is already an instance of itself running and force it to die?  or something similar?




EDIT AGAIN:

ok, i got another bug.  When i started geckoDotNet, he loaded values into the gui from last time i was using the program ( memory viewer tab ).  you can see the values he loaded in the screenshot below, i have not typed anything into the gui.  Then i click an empty spot in the scrollbar on the left to try to get him to scroll down 1 page.  and he spits out a chain reaction of invalid address messages.
[spoiler]

[/spoiler]

[dcx2]

I'll look at your video soon.  However, diss.bin isn't used anymore, ever.  It's always a unique file name in the temporary folder now.

However, there is a log file for exceptions.  I'll poke around at the logging after I watch your vid.

Also, regarding the bug in your screenshot...I think the problem comes from the Memory Range dropdown showing 80, while the Memory Address is in the 90 range.  I'll look into this, too.

Thanks for catching bugs.  I have a hypothesis...if this search crashing is recent, it might be the SetLatencyTimer...if you build from source, you can try going to USBGecko.cs, find the Connect() function, and there will be a line that sets the LatencyTimer = 2.  Try something like 10, and see if you keep getting crashes.

If you don't build from source, I can furnish a special test build just for you. :)

[giantpune]

I have formed a hypothesis also.  I think the diss.bin and the .log crashes are both caused by the same thing.  Whenever geckodotnet crashes, or possibly other times when it closes, the program doesnt actually get terminated.  This is the only reason I can think of for there to be several different instances of geckodonten.exe running in the task manager.  And since those paths are hard-coded, the new instance will try to access the exact same files that the zombie processes are still locked onto.  I havent noticed the zombie instances when the program exits normally.

So, If you stop all other occurrences of the program crashing, and it always exits normally, it should probably fix this crash by itself :P .

Also, IDK how the C# api is, but it seems that there would be a way to try to open the files and check their return value of the opening without the program crashing.  I can see it crashing if you just try to open a file and start writing without checking that you can access that file.  This wouldnt really allow the program to work like it should, but it would at least keep it from crashing.

[dcx2]

http://code.google.com/p/geckowii/source/browse/trunk/GeckoDotNET/Gecko%20dNet/disassembly.cs

Starting at line 225

[spoiler]            FileStream values;
            string filename = System.IO.Path.GetTempFileName();
            try
            {
                values = new FileStream(filename, FileMode.Create);
            }
            catch (Exception e)
            {
                return new String[] { "Couldn't open diss.bin!" };
            }

            try
            {
                gecko.Dump(address, eAddress, values);
            }
            catch (EUSBGeckoException e)
            {
                exceptionHandling.HandleException(e);
                return result.ToArray();
            }
            finally
            {
                // This will always close the FileStream, even if the exception is handled
                values.Close();
            }
[/spoiler]

Note that every disassembly dump anymore is a unique file name in the temporary folder.

If a file is write-protected, or otherwise illegal to touch, the FileStream constructor will throw an exception.  It shouldn't bring down the app, it should just say "Couldn't open diss.bin!"

If something happens while dumping memory from the USB Gecko, the finally block will ensure that the FileStream is always closed.  The finally block always executes, whether or not an exception happens.  I believe the only time a finally block *won't* fire is if you get an exception in a catch block, because the second exception wipes out the first.

Now, there's still a chunk where vdappc plays with this file.  I'm going to assume vdappc isn't the problem, although I've had assumptions like this nail me before.

If a finally block fails to execute, that usually means the CLR was brought down (the .NET equivalent of the Apocalypse).  This isn't normal...this isn't even abnormal.  This is paranormal.  This is where you jump up and down a few times to make sure gravity is still working...

[dcx2]

I've been giving this some more thought.  The next time you have zombie processes, try disconnecting the USB Gecko from the PC.  I've seen that if USB devices don't play nice with memory they can lock up their associated application until the device is disconnected.

The log file error you're seeing is definitely the result of a zombie process holding on to it.  The question is...what causes your zombie process?  It just so happens that the log file is written to after a search, and that's why searching seemed to trigger the exception.  But it's weird...you say it doesn't always trigger that exception?

In the mean time, I'm going to make a sub-folder for logs, and I'm going to create uniquely-named date/timestamped files.  This will solve that part of the problem.  I'm also going to stop logging the search sort times...that might help too.

As far as bringing down other instances...I'm not sure how OS-specific that may or may not be.  And it would probably require UAC elevation/root to kill another process.  I'm more interested in what causes the instance to hang around after it's been closed...

BTW...what's that funny call-graph-looking app?

EDIT:

I have a new theory.  The watch list is a little...dirty.  It's being terminated with Thread.Abort(), which doesn't give a thread a chance to shut down gracefully...and that means we could get zombies.  I'll see if I can end the thread more gracefully.

[giantpune]

are you talking about the disassembler or the hex editor?  the disassembler is ida pro 5.2.  the hex editor is hex workshop 6.

[Bully@Wiiplaza]

Request:

- Better adress recognition:
If you enter for example C2xxxxxx into the memory viewer text box and click update (hit enter) , it should automatically recognise 80xxxxxx as the input (but without a notification message box pls) and no invalid adress like before.
Same with all the 80,81 prefix codestypes (00,02,04,05...) The same for the 90,91,92,93 codestypes (10,12,14,4A,48...) but this time, it should recognise 90xxxxxx as the adress. :p

Wouldn´t it be useful? ;)

[dcx2]

I can see how automatically interpreting a ba code type might be useful, since the vast, vast majority of the time it is used as 0x80000000.  But there definitely won't be any interpreting of the po.

I think you misunderstand the po codes.  They are not MEM2 codetypes...the po can be used for anything, even 0x80000000.  You can also use the ba to touch MEM2.

[Bully@Wiiplaza]

I can see how automatically interpreting a ba code type might be useful, since the vast, vast majority of the time it is used as 0x80000000.  But there definitely won't be any interpreting of the po.

I think you misunderstand the po codes.  They are not MEM2 codetypes...the po can be used for anything, even 0x80000000.  You can also use the ba to touch MEM2.

wait, I meant this:

48000000 9y00000
14xxxxxxx zzzzzzzz
E0000000 80008000

Yeah, I failed a bit lol. It´s the 48 codestype, only 10,12,14... :eek:
what do you say now? ???

[dcx2]

Yes, I know how to use the po and write to MEM2.  The problem is that you want to copy a code type - say, 14567890 - and paste it into an address text box.  Then you want the app to figure out what you really wanted it to do.

Most people assume ba = 0x80000000.  So it's not hard to take C2567890 and turn it into 80567890.  Most people would not be surprised to see this happen, so this is okay.

However, it is still possible for ba = 0x90000000 or 0x92000000.  But this is not common.

I still think you misunderstand po code types  (10/12/14/16/D2/etc).  They are not by default in MEM2.  You must use po with pointers in MEM1.  I think most people would be surprised if they put in 14567890 and got 90567890.

[live2play]

Source and Target seem to be reversed in the FST tab.  If I select a file and then "Set as Source", then select another file and select "Set as Target", the source file is replaced with the target file.

[hawkeye2777]

Code Select Expand

System.ArgumentOutOfRangeException: ControlCollection does not have that many controls
Parameter name: index
2
  at System.Windows.Forms.Control+ControlCollection.get_Item (Int32 index) [0x00000]
  at System.Windows.Forms.TabControl.GetTab (Int32 index) [0x00000]
  at (wrapper remoting-invoke-with-check) System.Windows.Forms.TabControl:GetTab (int)
  at System.Windows.Forms.TabControl+TabPageCollection.get_Item (Int32 index) [0x00000]
  at System.Windows.Forms.TabControl.get_SelectedTab () [0x00000]
  at System.Windows.Forms.TabControl.OnLeave (System.EventArgs e) [0x00000]
  at System.Windows.Forms.Control.FireLeave () [0x00000]
  at System.Windows.Forms.ContainerControl.set_ActiveControl (System.Windows.Forms.Control value) [0x00000]
  at System.Windows.Forms.Control.Select (Boolean directed, Boolean forward) [0x00000]
  at System.Windows.Forms.Control.SelectNextControl (System.Windows.Forms.Control ctl, Boolean forward, Boolean tabStopOnly, Boolean nested, Boolean wrap) [0x00000]
  at System.Windows.Forms.ContainerControl.ChildControlRemoved (System.Windows.Forms.Control control) [0x00000]
  at (wrapper remoting-invoke-with-check) System.Windows.Forms.ContainerControl:ChildControlRemoved (System.Windows.Forms.Control)
  at System.Windows.Forms.Control+ControlCollection.Remove (System.Windows.Forms.Control value) [0x00000]
  at System.Windows.Forms.TabControl+ControlCollection.Remove (System.Windows.Forms.Control value) [0x00000]
  at System.Windows.Forms.Control+ControlCollection.RemoveAt (Int32 index) [0x00000]
  at System.Windows.Forms.TabControl+TabPageCollection.RemoveAt (Int32 index) [0x00000]
  at GeckoApp.NoteSheets.DeleteSheet (System.Windows.Forms.TabPage selected) [0x00000]
  at (wrapper remoting-invoke-with-check) GeckoApp.NoteSheets:DeleteSheet (System.Windows.Forms.TabPage)
  at GeckoApp.NotePage.DelCurSheet_Click (System.Object sender, System.EventArgs e) [0x00000]
  at System.Windows.Forms.Control.OnClick (System.EventArgs e) [0x00000]
  at System.Windows.Forms.Button.OnClick (System.EventArgs e) [0x00000]
  at System.Windows.Forms.ButtonBase.OnMouseUp (System.Windows.Forms.MouseEventArgs mevent) [0x00000]
  at System.Windows.Forms.Button.OnMouseUp (System.Windows.Forms.MouseEventArgs mevent) [0x00000]
  at System.Windows.Forms.Control.WmLButtonUp (System.Windows.Forms.Message& m) [0x00000]
  at System.Windows.Forms.Control.WndProc (System.Windows.Forms.Message& m) [0x00000]
  at System.Windows.Forms.ButtonBase.WndProc (System.Windows.Forms.Message& m) [0x00000]
  at System.Windows.Forms.Button.WndProc (System.Windows.Forms.Message& m) [0x00000]
  at System.Windows.Forms.Control+ControlWindowTarget.OnMessage (System.Windows.Forms.Message& m) [0x00000]
  at System.Windows.Forms.Control+ControlNativeWindow.WndProc (System.Windows.Forms.Message& m) [0x00000]
  at System.Windows.Forms.NativeWindow.WndProc (IntPtr hWnd, Msg msg, IntPtr wParam, IntPtr lParam) [0x00000]
System.ArgumentException: A null reference or invalid value was found [GDI+ status: InvalidParameter]
  at System.Drawing.GDIPlus.CheckStatus (Status status) [0x00000]
  at System.Drawing.Font.GetHeight (Single dpi) [0x00000]
  at System.Drawing.Font.GetHeight () [0x00000]
  at System.Drawing.Font.get_Height () [0x00000]
  at (wrapper remoting-invoke-with-check) System.Drawing.Font:get_Height ()
  at System.Windows.Forms.TextBoxBase.get_PreferredHeight () [0x00000]
  at System.Windows.Forms.TextBoxBase.FixupHeight () [0x00000]
  at System.Windows.Forms.TextBoxBase.OnHandleCreated (System.EventArgs e) [0x00000]
  at System.Windows.Forms.TextBox.OnHandleCreated (System.EventArgs e) [0x00000]
  at System.Windows.Forms.Control.WmCreate (System.Windows.Forms.Message& m) [0x00000]
  at System.Windows.Forms.Control.WndProc (System.Windows.Forms.Message& m) [0x00000]
  at System.Windows.Forms.TextBoxBase.WndProc (System.Windows.Forms.Message& m) [0x00000]
  at System.Windows.Forms.TextBox.WndProc (System.Windows.Forms.Message& m) [0x00000]
  at System.Windows.Forms.Control+ControlWindowTarget.OnMessage (System.Windows.Forms.Message& m) [0x00000]
  at System.Windows.Forms.Control+ControlNativeWindow.WndProc (System.Windows.Forms.Message& m) [0x00000]
  at System.Windows.Forms.NativeWindow.WndProc (IntPtr hWnd, Msg msg, IntPtr wParam, IntPtr lParam) [0x00000]
System.ArgumentException: A null reference or invalid value was found [GDI+ status: InvalidParameter]
  at System.Drawing.GDIPlus.CheckStatus (Status status) [0x00000]
  at System.Drawing.Font.GetHeight (Single dpi) [0x00000]
  at System.Drawing.Font.GetHeight () [0x00000]
  at System.Drawing.Font.get_Height () [0x00000]
  at (wrapper remoting-invoke-with-check) System.Drawing.Font:get_Height ()
  at System.Windows.Forms.TextBoxBase.get_PreferredHeight () [0x00000]
  at System.Windows.Forms.TextBoxBase.FixupHeight () [0x00000]
  at System.Windows.Forms.TextBoxBase.OnHandleCreated (System.EventArgs e) [0x00000]
  at System.Windows.Forms.TextBox.OnHandleCreated (System.EventArgs e) [0x00000]
  at System.Windows.Forms.Control.WmCreate (System.Windows.Forms.Message& m) [0x00000]
  at System.Windows.Forms.Control.WndProc (System.Windows.Forms.Message& m) [0x00000]
  at System.Windows.Forms.TextBoxBase.WndProc (System.Windows.Forms.Message& m) [0x00000]
  at System.Windows.Forms.TextBox.WndProc (System.Windows.Forms.Message& m) [0x00000]
  at System.Windows.Forms.Control+ControlWindowTarget.OnMessage (System.Windows.Forms.Message& m) [0x00000]
  at System.Windows.Forms.Control+ControlNativeWindow.WndProc (System.Windows.Forms.Message& m) [0x00000]
  at System.Windows.Forms.NativeWindow.WndProc (IntPtr hWnd, Msg msg, IntPtr wParam, IntPtr lParam) [0x00000]

Not sure what the cause of this was; GDN crashed when I was working on a different workspace. I think it has to do with the Notepad though. Might be Mono only, not sure.

[Link]

Source and Target seem to be reversed in the FST tab.  If I select a file and then "Set as Source", then select another file and select "Set as Target", the source file is replaced with the target file.

That's the way I developed it and that was my understanding. THe game tries to access the source file however its access gets redirected.. to the new target file. However, it could be swapped easily in worst case!

[giantpune]

maybe just rename the labels instead...
"file the game tries to read" & "file the game will read instead"

i dont see there being any way somebody will get confused about what they do then :P

[live2play]

I guess that the FST Source/Target functionality makes sense after reading your response.  Thanks!