Issue with .NET callback events and Access Violations

[Petemeister]

Hello,

I am having an issue with access violations, which I believe are coming from .NET event callbacks. The issue exists also in the vendor's example code and I have reached out to them as well. But, I also reach out here to open up the possible support base.

I am working to implement a low-pass filter from Alligator Technologies, model USBPGF-S1. I've attached the manual for this just in case it's helpful. They implement interaction using a helper DLL, which they recommend is registered with the OS and placed in the system32 directory.

Here is a picture of their example code and the callback VI. The example code is saved in LV 2010. Their example code is also in ZIP form attached to this post, along with the DLL.

Getting Started with your USBPxx.vi

DeviceConnectedEventCallback.vi

I've tested with their example code, and the basic functions interacting with the hardware work if everything is connected when the VI launches. I can read and write parameters to the device using the command structure specified in the manual. 

The issue arises when connecting or disconnecting the device after the 2-second delay following the callback event registration. When disconnecting or connecting a device, the following error occurs:

Addresses vary from call to call, but the structure of the error is the same every time.

Any thoughts? Hopefully there is something obvious being missed.

[Petemeister]

Investigating a little more, it seems I made an incorrect statement regarding the error.

It turns out I have two distinct and separate issues, both related with the callback:

1. After 2-second delay following the callback event registration, the callback VI specified is not called when the event triggers. But, during this delay, the callback executes properly. It's possible the event isn't actually triggering, but I'm not sure how to test this.

2. After the callback event is unregistered, a subsequent connection or disconnection throws the error dialog "Access violation at address ..."

[mfaltin]

Hi Petemeister,

If the issue arrises only when connecting/disconnecting hardware while the VI is running, the question must be asked: Why are you disconnecting/connecting hardware while running the VI?

[Petemeister]

Hi Mfaltin,

Agreed - this is not a typical use case, but rather is an edge case which still needs to be handled appropriately. I could work around the callbacks not triggering outside of the initialization phase, but handling of this edge case is greatly simplified when the event is fired and can be handled nicely. Additionally, it goes against my understanding of how event callbacks are supposed to work... once the event callback is registered, the referenced VI will execute each time the event is triggered, until the event callback is unregistered.

But, the issue of access violation even occurs once the VI has stopped, making it more severe.

[mfaltin]

Hey Petemeister,

Its not unexpected that you are getting "Access Violation" errors that occur when you disconect a device while the program is running. Simply put, the Access Violation errors are occuring because the program cannot access what is not there. When you disconnect the hardware, the computer/program cannot connect or communicate with the device any longer and is informing you of this via an "Access Violation" error. 

[Petemeister · Accepted solution]

So, it turns out the vendor did not document the DLL's bitness correctly. They have since updated their documentation and software package.

The issue is on their side, with how they are handling pointer sizes. The DLL I was using was for 64-bit systems, but I had called it using 32-bit LabVIEW. Therefore, LabVIEW allocated a 32-bit pointer, but the DLL tried to treat it as a 64-bit pointer. Therefore the memory was outside of the allocation and generated the access violation error.

Using the DLL matching LabVIEW's bitness solves the access violation problem.