CVI application error 0xc0000005??

[EleanorWyatt]

Hi,

We are using a CVI 2017 application in our EMS plant for automated testing of electronic parts.
This app has several type of instruments (CAN, DMM..) and drivers. 

Another application, written in C# .net, acts like MES client, it's sending/receiving product information from/to MES system.

When our test application testing electronic units with audio functions, an AP515 audio analyzer is used to validate these functions(it's driver requires .net also). In this case, CVI application stops working randomly. 

The only thing I found is some record in the event viewer in win 10:

Application Error, Exception Code: 0xc0000005, Error position: 0x00584a35

.NET Runtime: Exception Code: c0000005, Exception postition: 00984A35
.NET version: v4.0.30319
Desc.: Process has been stopped due to an unhandled exception

Always these two records. When there is no need to run audio analyzer, no runtime errors occure.
When MES client is not running also no errors occure.

Can you help me?

[rolfk]

Exception C0000005 is an Access Violation error. Basically that software tries to reference a memory location that is not valid, such as an uninitialized pointer. The CPU itself detects that the address is not valid for the currently allocated virtual memory for the process and simply pulls the safety brake. There is nothing you can do about this other than getting the access violation fixed.

And that will mean getting Audio Precision technical support involved. Now they will likely point out that their driver works perfectly fine in their simple C# test executable, and hence the problem must be with LabWindows/CVI but that is most of the times bullshit. Depending on when your version of the driver was released, they may actually already have several new versions anyhow since, so check with them what is the latest driver version available.

The fact that there seems to be a dependency between your MES software and this driver, both being .Net components, will make this however a very tricky thing for sure. AP will point at that MES software and whoever wrote that MES software will point at AP. If that MES software is an inhouse development that would be the first point of attack. Get the developer involved with debugging. Otherwise, good luck with this ping pong game!

Of course if you had a real Instrument Driver in source code for that device rather than a .Net driver, the chances for such an error are pretty much nihil, and if something doesn't work you could actually go and debug it yourself.

[RobertoBozzolo]

I can only add that if you have generated the map file for your application (this is a build option that is not checked by default) you could at least have a clue as to which function in your code is involved in the crash: this may delimit the number of functions called for third party drivers: you may want to supply the function code to driver vendor support service for they to try understanding what's going on.

(There is also the possibility that pointing to a definite function in your code you get and fix some error in that function thus avoiding the call to external support services).

Are the addresses in the error messaged always the same?