Another Question on c# Generic Hid v5.0 using filestreams

[GaryM]

I have been using this code example as a basis for a GUI to communicate with an embedded device I am developing.  Been using it for several months as I add capabilities to the GUI and embedded device and it has worked GREAT.  Many runs have been over a solid week with no issues

A few days ago, I figured it was time to handle device removal and attachment.  One thing I ran into was after reattaching and running FindTheHid and trying to read interrupt reports, I would get the following exception:

"Attempted to read or write protected memory. This is often an indication that other memory is corrupt."

on the following statement
fileStreamDeviceData.BeginRead(inputReportBuffer, 0, inputReportBuffer.Length, new AsyncCallback(GetInputReportData), inputReportBuffer);

So I spent way too much time trying to debug this.  Finally decided to go back to the original generic_hid example and run it in the following manner.

1.) Start Generic HID GUI
2.) Enter my vendor and product ID
3.) Click on "Find Device" --- device found fine
4.) Click on "Send and Receive Data->Once" -- report read correctly
5.) Physically Disconnect/Reconnect Device
6.) Either Do "Find My Device followed by Once", or just do "Once"

Doing this recreates the problem/exception

I did spend time researching this on this forum but got the impression that the streams version was updated to include issues found earlier but was a little confused as some of the bugs seemed to imply it was stream related.

Any ideas?

Love your books Jan!

Gary

[GaryM]

On a side note, I added a button to my GUI which simply calls the Close Connection Function.  Once I am up and running and reading reports, clicking this button causes the same behavior once I call FindTheHid and start trying to read reports again.

Gary

[Jan Axelson]

I'll take a look at it, but my guess would be that it has to do with leaving something open that needs to be closed on detach.

Jan

[GaryM]

Thanks for the quick response.

Yes, that is what I think is going on as well,  it appears that fileStreamDeviceData and hidHandle never get set to null when closing.  Not sure what this means.  I am by no means a c# or .net person.

        private void CloseCommunications()
        {
            // The next attempt to communicate will get new handles and FileStreams.
            myDeviceDetected = false;

            if (fileStreamDeviceData != null)
            {
                fileStreamDeviceData.Close();
            }

            if ((hidHandle != null) && (!(hidHandle.IsInvalid)))
            {
                hidHandle.Close();
            }


        }

[Jan Axelson]

I did this:

1.) Start Generic HID GUI
2.) Enter my vendor and product ID
3.) Click on "Find Device" --- device found fine
4.) Click on "Send and Receive Data->Once" -- report read correctly
5.) Physically Disconnect/Reconnect Device
6.) Either Do "Find My Device followed by Once", or just do "Once"

and didn't get the error you're seeing.

You could try placing a breakpoint at CloseCommunications and see if everything closes properly.

Here are a couple of suggested fixes that aren't on the web version of the code yet:

http://www.lvr.com/forum/index.php?topic=696.msg2584#msg2584
http://www.lvr.com/forum/index.php?topic=708.msg2634#msg2634

Jan

[GaryM]

Spent about 30 hours debugging this without success, monitored the hidHandle and fileStreamDeviceData and nothing looked out of the ordinary, both looked identical before and after reconnecting after the disconnection. Tried literally hundreds of things with no success including the first link you posted.  The second link does not compile as posted (looking at MSDN, it seems like it should but doesnt) so I used this instead

IntPtr pDevicePathName = new IntPtr(detailDataBuffer.ToInt64() + 4);

That being said, none of this worked.

So I read the post about having issues with HidP_GetValueCaps so I commented that out of Hid.cs->GetDeviceCapabilities and it all works fine.

Perhaps some USB devices cause this error and some dont.  I would like to understand what is going on but after a solid 3+days of this, I think I need a break.

Gary

[Jan Axelson]

Yes, my code doesn't use HidP_GetValueCaps and there is no harm in commenting out the call to it.

Jan

[vanweric]

Gary -

I ran into something that might be similar, and wrote about it in this post: http://www.lvr.com/forum/index.php?topic=668.0

Long story short, the allocated memory was too small, so HidP_GetValueCaps was overwriting "something else"... I never tracked it down.  I think fixing the definition of the structure will do the trick, but I gave up because I didn't need those results either.

Also, it is safe to do pointer arithmetic in C# without wrapping it with ToIntXX and new IntPtr.  Your line should simply read  IntPtr pDevicePathName = detailDataBuffer + 4;