Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ArgumentOutOfRangeException calling InitializeAsync (Set Buffer Size Manually WindowsHidDevice) #63

Closed
bryans69 opened this issue Jun 17, 2019 · 37 comments

Comments

@bryans69
Copy link

commented Jun 17, 2019

Simple test project at this point in time, but get System.ArgumentOutOfRange when calling InitializeAsync

Device has been found OK

var deviceDefinitions = new List
{
new FilterDeviceDefinition{ DeviceType= DeviceType.Hid, VendorId= 0x043D, ProductId=0x0235 }
};
var devices = await DeviceManager.Current.GetDevicesAsync(deviceDefinitions);
var device =new WindowsHidDevice( devices.FirstOrDefault().DeviceId); <- device points to expected USB device
await device.InitializeAsync(); <- Exception here

Running this in a simple windows form at this point in time

System.ArgumentOutOfRangeException
HResult=0x80131502
Message=Positive number required.
Parameter name: bufferSize
Source=mscorlib
StackTrace:
at System.IO.FileStream..ctor(SafeFileHandle handle, FileAccess access, Int32 bufferSize, Boolean isAsync)
at Hid.Net.Windows.WindowsHidDevice.Initialize()
at Hid.Net.Windows.WindowsHidDevice.b__24_0()
at System.Threading.Tasks.Task`1.InnerInvoke()
at System.Threading.Tasks.Task.Execute()
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Hid.Net.Windows.WindowsHidDevice.d__24.MoveNext()
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.GetResult()
at WindowsFormsApp1.Form1.<button2_Click>d__4.MoveNext() in C:\Users\bryans\source\repos\WindowsFormsApp1\WindowsFormsApp1\Form1.cs:line 94

@MelbourneDeveloper

This comment has been minimized.

Copy link
Owner

commented Jun 17, 2019

Thanks for reporting!

I'll go over the code and see if we can find something wrong there. It looks like that device isn't allowing some kind of access though... Maybe there are two device IDs you can connect to?

Any chance you can turn on first chance exceptions , debug and send me a screenshot?

@MelbourneDeveloper

This comment has been minimized.

Copy link
Owner

commented Jun 17, 2019

@bryans69 it looks like the issue is here. It is expecting that the ConnectedDeviceDefinition will have a ReadBufferSize, and a WriteBufferSize. However, it looks like those things are not being obtained for some reason.

You could modify the code so that you can specify those two values by adding setters here.

If this solves your problem, I'd really like to hear about it. If it does, I could make these values writable so that others can solve the same problem.

@bryans69

This comment has been minimized.

Copy link
Author

commented Jun 17, 2019

@MelbourneDeveloper

This comment has been minimized.

Copy link
Owner

commented Jun 17, 2019

@bryans69 I can't see your screenshots there. You just need to copy and paste the image in.

@bryans69

This comment has been minimized.

Copy link
Author

commented Jun 17, 2019

image

@bryans69

This comment has been minimized.

Copy link
Author

commented Jun 17, 2019

image

@MelbourneDeveloper

This comment has been minimized.

Copy link
Owner

commented Jun 17, 2019

@bryans69 yep, I understand. As mentioned above, the issue is because the buffer sizes are not being set when the device is initialized. I recommend that you clone the repo, and modify the code so that you can set the buffer sizes.

If this solves your issue, I will put that in a release and push out the NuGet package.

@MelbourneDeveloper

This comment has been minimized.

Copy link
Owner

commented Jun 17, 2019

@bryans69 cloning the repo and adding the project to your solution will help with debugging a lot.

@bryans69

This comment has been minimized.

Copy link
Author

commented Jun 17, 2019

@MelbourneDeveloper

This comment has been minimized.

Copy link
Owner

commented Jun 17, 2019

@bryans69 they are usually 64. But, sometimes they can be 5000 I think.

Something is going wrong with the device though, because this call used here should obtain those values.

@MelbourneDeveloper

This comment has been minimized.

Copy link
Owner

commented Jun 17, 2019

@bryans69 please stay in contact and I'll do my best to help you through this.

@bryans69

This comment has been minimized.

Copy link
Author

commented Jun 17, 2019

@MelbourneDeveloper

This comment has been minimized.

Copy link
Owner

commented Jun 17, 2019

@bryans69

Any suggestions on what the sizes should be?

You will need to check with the manufacturer exactly the device is expecting to receive. These values are the size of amount of data that is written to/from the device. Only they will be able to tell you what that is.

@bryans69

This comment has been minimized.

Copy link
Author

commented Jun 18, 2019

@MelbourneDeveloper

This comment has been minimized.

Copy link
Owner

commented Jun 18, 2019

@bryans69

Cool. Any chance you can fork my repo, your changes in, and send me the link? I won't be able to look for a couple of days unfortunately. But I will certainly do my best to diagnose.

@bryans69

This comment has been minimized.

Copy link
Author

commented Jun 18, 2019

I just changed this where you suggested. I could get the setter to work, and as I was just trying to prove a point, hard coded - WindowsHIDDevice,cs
public override ushort WriteBufferSize => 64;// ConnectedDeviceDefinition == null ? (ushort)0 : (ushort)ConnectedDeviceDefinition.WriteBufferSize.Value;

Can't help thinking I'm connecting to the wrong device instance (if that is the correct terminology for USB devices), hence it effectively being read only

@MelbourneDeveloper

This comment has been minimized.

Copy link
Owner

commented Jun 18, 2019

@bryans69 Yeah, but you have written some code to connect to your device and send data. Can you post that?

@bryans69

This comment has been minimized.

Copy link
Author

commented Jun 18, 2019

very quick and dirty
private async void button2_Click(object sender, EventArgs e)
{
var deviceDefinitions = new List
{
new FilterDeviceDefinition{ DeviceType= DeviceType.Hid, VendorId= 0x043D, ProductId=0x0235 }
};
var devices = await DeviceManager.Current.GetDevicesAsync(deviceDefinitions);
var device =new WindowsHidDevice( devices.FirstOrDefault().DeviceId);
await device.InitializeAsync();
//Create a buffer with 3 bytes (initialize)
var buffer = new byte[10];
buffer[0] = 0xA5;
buffer[1] = 0x00;
buffer[2] = 0x07;
buffer[3] = 0x50;
buffer[4] = 0xE0;
buffer[5] = 0x21;
buffer[6] = 0x01;
buffer[7] = 0x00;
buffer[8] = 0x00;
buffer[9] = 0x00;
//Write and read the data to the device
var readBuffer = await device.WriteAndReadAsync(buffer);
if (readBuffer.Length>0)
{
Console.WriteLine(readBuffer.Length);
}
}

@bryans69

This comment has been minimized.

Copy link
Author

commented Jun 18, 2019

This is actually the command I'm trying to send / get a response from

@MelbourneDeveloper

This comment has been minimized.

Copy link
Owner

commented Jun 18, 2019

@bryans69 I can't see anything funny there. Maybe the device has a Hid and USB device registered. Have you tried seeing if you can send data using the USB Guid?

Try registering the USB factory and then enumerating all devices on the machine. you might find that it shows up as a USB device.

@bryans69

This comment has been minimized.

Copy link
Author

commented Jun 18, 2019

Strangely, that still only returns one device. So not seeing the USB ones at all
image

@MelbourneDeveloper

This comment has been minimized.

Copy link
Owner

commented Jun 18, 2019

@bryans69 do you know for sure that freeusbanalyzer can sniff Hid traffic?

@MelbourneDeveloper

This comment has been minimized.

Copy link
Owner

commented Jun 18, 2019

@bryans69 I mean you can step right in to the code with F11 to see the literal API calls that are sending the data...

@bryans69

This comment has been minimized.

Copy link
Author

commented Jun 18, 2019

This is what I see from the code I posted
image
and this is what I see from the working application
image

Hope that makes sense

I stepped into your code and await _WriteFileStream.WriteAsync(bytes, 0, bytes.Length); in WindowsHIDDevices appears to work, ie it doesn't error, but I don't see it in the above, and never get a reply

@bryans69

This comment has been minimized.

Copy link
Author

commented Jun 18, 2019

Just to clarify, the last entry in the top screenshot is the InitializeAsync call

@MelbourneDeveloper

This comment has been minimized.

Copy link
Owner

commented Jun 18, 2019

@bryans69 Odd.

I'll spend some time thinking about it and send you some more things to try. This looks like a good tool, so I'll try it out and see what the other devices I test with show. Sorry, just gonna have to bare with me over the next couple of days.

@bryans69

This comment has been minimized.

Copy link
Author

commented Jun 18, 2019

OK thanks. Will let you know if I have any more success

@MelbourneDeveloper MelbourneDeveloper changed the title ArgumentOutOfRangeException calling InitializeAsync ArgumentOutOfRangeException calling InitializeAsync (Set Buffer Size Manually WindowsHidDevice) Jun 22, 2019

@MelbourneDeveloper

This comment has been minimized.

Copy link
Owner

commented Jun 23, 2019

@bryans69 I have pushed out a new release. The main focus here was error handling and logging around connecting to and enumerating devices. However, I've added a constructor for Windows Hid Devices to accept read/write buffer sizes. I hope this helps you.

I know this doesn't answer your question about the tracing. I will address that at some point soon. I still recommend debugging the literal traffic to the device as the most accurate way of seeing what is coming and going from the device.

@MelbourneDeveloper

This comment has been minimized.

Copy link
Owner

commented Jun 23, 2019

@bryans69 , I have made tracing the data IO the highest priority for the next release.

https://github.com/MelbourneDeveloper/Device.Net/projects/8

I hope to get this done soon.

@MelbourneDeveloper

This comment has been minimized.

Copy link
Owner

commented Jun 23, 2019

@bryans69 I've made a branch where I've fixed up tracing. If you grab this, I'd say that tracing is pretty reliably here:

https://github.com/MelbourneDeveloper/Device.Net/tree/%237-Tracing

As long as you pass a tracer in to the constructor, it will trace IO for you. This should pretty much guarantee that the data is reaching the device. If FileStream.WriteAsync() is not sending the data, and not throwing an exception, I'd be extremely surprised.

@bryans69

This comment has been minimized.

Copy link
Author

commented Jun 25, 2019

@MelbourneDeveloper

This comment has been minimized.

Copy link
Owner

commented Jun 28, 2019

One thing I have discovered is that there appears to be two pipes, one for reading and one for writing

@bryans69 you're definitely dealing with a USB device there and not a Hid device.

I only changed the Hid equivalent because I thought you were dealing with a Hid device. So, the problem is here and here

@MelbourneDeveloper

This comment has been minimized.

Copy link
Owner

commented Jun 30, 2019

@bryans69 I have added an overload in the Develop branch for USB:

public WindowsUsbDevice(string deviceId, ushort? writeBufferSize, ushort? readBufferSize) : base(deviceId)

@MelbourneDeveloper

This comment has been minimized.

Copy link
Owner

commented Jul 2, 2019

@bryans69

One thing I have discovered is that there appears to be two pipes, one for reading and one for writing

Perhaps you're experiencing this problem? Would that be right? Someone else commented on this and maybe it needs a fix.
#19

@bryans69

This comment has been minimized.

Copy link
Author

commented Jul 2, 2019

@MelbourneDeveloper

This comment has been minimized.

Copy link
Owner

commented Jul 3, 2019

@bryans69 there's lots of work been done around the pipes problem here: #19 . I think that branch should fix the issue and I will prep a nuget for it soon.

@MelbourneDeveloper MelbourneDeveloper added this to Todo in 3.0 Jul 6, 2019

@MelbourneDeveloper MelbourneDeveloper moved this from Todo to Done in 3.0 Jul 7, 2019

@MelbourneDeveloper

This comment has been minimized.

Copy link
Owner

commented Jul 21, 2019

@bryans69 I'm closing this particular issue because I believe that all your issues will be fixed in Version 3.0, or you will at least be able to work around them. I will release 3.0 beta today. It would be great if you could grab it and test.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
2 participants
You can’t perform that action at this time.