System.AccessViolationException .Net Interop Assembly if passing LabView class as output parameter

[StefanVogel]

I'm using LabView 2015 f3 and want to make a .Net Interop Assembly to use in my .Net 4.5 Application. My LabView Project has a class called "Vehicle" with one VI called "calc.vi" which I want to call from .Net. If I pass the class object as input parameter, my assembly works fine. As soon as I also want to return the class object as output parameter, I get this exception:

System.AccessViolationException wurde nicht behandelt.
HResult=-2147467261
Message=Es wurde versucht, im geschützten Speicher zu lesen oder zu schreiben. Dies ist häufig ein Hinweis darauf, dass anderer Speicher beschädigt ist.
Source=NationalInstruments.LabVIEW.Interop
StackTrace:
bei NationalInstruments.LabVIEW.Interop.DataMarshal.MarshalOutputLVClass(IntPtr entryPointDataSpace, Type lvClassType, Int32 terminalIndex, IntPtr lvClient)
bei VehicleNamespace.Vehicle.calc(Double y, Double& u, Vehicle vehicleIn, Vehicle& vehicleOut)
bei DotNetInteropAssemblyTest.CalcClass.calcVehicle(Vehicle vehicle, Vehicle& vehicleOut) in c:\DotNetInteropAssemblyTestMin\DotNetInteropAssemblyTest\CalcClass.cs:Zeile 13.
bei DotNetInteropAssemblyTest.Program.Main(String[] args) in c:\DotNetInteropAssemblyTestMin\DotNetInteropAssemblyTest\Program.cs:Zeile 31.
bei System.AppDomain._nExecuteAssembly(RuntimeAssembly assembly, String[] args)
bei System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args)
bei Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
bei System.Threading.ThreadHelper.ThreadStart_Context(Object state)
bei System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
bei System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
bei System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
bei System.Threading.ThreadHelper.ThreadStart()

The exception occures only after many calls (Stress-Test after around 1'000'000 calls), but it's reproducable. It's even always around the same count of calls. I added the test project in the attachement.

[NikoNR]

Hi Stefan,

could you post the VI that is calling your .Net assembly?

When i run the "DotNetInteropAssemblyTest.exe", I get the error message that the SpreadsheetTest has stopped working.

I would like to reproduce it in order to check if it is a CAR (correction action request).

Best regards,

Niko

[StefanVogel]

Hi Niko

The exe you tried to call is in probably from the obj folder and is not ment to be running. You should be able to open the .Net-Solution (*.sln) file with Visual Studio Express 2013 to build and debug your own exe. However I put the comiled exe in the attachments.

Thanks, Stefan

[NikoNR]

Dear Stefan,

can you do a LabVIEW Project where you call your calc.VI from another VI? This excludes that Visual Studio might cause the problem.

Can you contact your local NI service branch and open a service request? 

best,

Niko

[StefanVogel]

Hi Niko

I added a file called testCalc.vi in LabView project which terminates with an error message (see Attachments) and closes LabView if executed. So it obviously seems not to be a Visual Studio Problem only.

Thanks

Stefan

[NikoNR]

Hi Stefan,

I am in contact with R&D and reported the behaviour. I will let you know as soon as I hear back from them.

Best,

Niko

[NikoNR]

Hi Stefan,

I heard back from R&D and indeed, and what is happening is that you open a new reference to the current object. The Limit of that is indeed a bit over a Million (1048575) which is 14bit. 

A possible workaround would be that If you do hit the limit, you could add code to handle the condition by exiting and restarting a subVI that handles the .NET reference creation and deletion.

I hope this was helpful for you!

Best, Niko

[StefanVogel]

Hi Niko

Thanks for the Info. But this workarount can't really be the long term solution, is it? Creating new references in this case is also consuming unnessesary memory. So will there be a patch for this bug in the future? 

Thanks, Stefan