.net dll make labview crashing

[Pierre_F]

hello

I have to work with a recent DLL made by someone in visual studio 2015 .NET
this new DLL is built as a "wrap" to another "lower level" DLL that is approx 1 year old older.
this DLL contains usual procedures : initialize, close, read  get etc... for an external device

I used successively implement each one of those DLL inside my programs. the old one worked fine, the new don't.

the behaviour is strange: I can use every procedure stored in the new DLL and it seems to work fine, but the "stopping" button in the labview ribbon crashes labview completely below, even if I "close" the dll reference before stopping

do you have any idea about the origin of the problem?

[GregPayne]

Hi Pierre,

---

, but the "stopping" button in the labview ribbon crashes labview completely below,

---

Do you mean the abort button? Pressing this will stop your code instantly without closing the references which might be causing your problem.

Another possibility could be the way .NET does garbage collection. If you have control over the dll source code, try disposing the object references in the class destructor. This will then be called when you close the reference from LabVIEW.

Also make sure you are closing all references from LabVIEW, it's easy sometime to miss one.

I hope this helps,

Greg 

[Pierre_F]

, but the "stopping" button in the labview ribbon crashes labview completely below,

Do you mean the abort button? Pressing this will stop your code instantly without closing the references which might be causing your problem

I mean this button:

 it crashes even if I close my references before.

Another possibility could be the way .NET does garbage collection. If you have control over the dll source code, try disposing the object references in the class destructor. This will then be called when you close the reference from LabVIEW.

the other people that made this DLL tells me that "garbage collection" and "class destructor" are automatically managed by windows when VisualStudio is compiling the dll .

Also make sure you are closing all references from LabVIEW, it's easy sometime to miss one.

strangely it is not supposed to crash anyway, isn't it?

[GregPayne]

Hi Pierre,

I don't have extensive .NET experience, but I have seen a similar problem to you with a dll that I wrote. I also don't know the exact details how .NET handles garbage collection, but believe its a task that happens at any time after the program has closed, managed by the environment. Leading on from that, from the reading that I have done, how this garbage collection is managed when run from a LabVIEW application is unclear, other than closing the references.

So from my own experience, when I used the dll that I wrote in a .NET (C#) application, I had no problems when stopping the application, or even aborting it. The .NET environment seemed to handle the open reference and dispose of it automatically when it wanted to.

As soon as I included the dll in LabVIEW I started to see problems. If I closed all references properly I had no crashes. As soon as I stopped the LabVIEW application without closing a reference, LabVIEW reliably crashed. My conclusion was that although the .NET runtime was OK with leaving a reference open until it wanted to clean it up, LabVIEW wasn't, which caused the crash.

This then lead me to explicitly dispose all the references in the dll destructor. From a LabVIEW application point of view, this meant that closing the references when the LabVIEW application stops still worked as before. When the LabVIEW application was aborted, just before the dll went out of memory, its destructor was called disposing all the references. When doing this, LabVIEW was OK and didn't crash.

For my case, closing the references in the destructor fixed dll and I haven't had a crash since.

I've just come across this very old KB which might help http://digital.ni.com/public.nsf/allkb/8D323E2921DDEBD3862574F8007F5377

[billko]

You know the joke about the patient going to the doctor and saying "Doctor, when I do this, it hurts?" and the doctor says, "Well don't do that?"  Well, don't do that.

When you press the abort button, all bets are off as to what happens next; you are stopping LabVIEW dead in its tracks.  Since the vi is very likely inside the dll when you abort, even less is known about what will happen, since LabVIEW has handed off control to the dll and expects the dll to hand it back when it is done.