Why does LabView crash upon closing if I use a .NET 2.0 assembly?

[georgedev]

I'm using a .NET 2.0 C# assembly in a LabView project with a invoke method node.  The invoke method nodes work, but LabView crashes when the project closes.  I'm closing the class references at the end of the project.  Any ideas on what could be causing the crash?

[Lycangeek]

Not off the top of my head - I use .NET 2.0 myself and haven't seen this problem...can you tell me what version of LV are you using? (8.0, 8.01, 8.20?)

Also, can you supply me with any information on the crash - do you have a crash log file?

Is it possible for you to post the files? If you don't feel comfortable with that, can you email them to me (bloggingbrian@gmail.com)?

[georgedev]

After a lot of testing I've narrowed it down to something in the .NET 2.0 code that labView doesn't like.  My .Net DLL works without any issues in a .NET 2.0 app, but LabView crashes upon exit.  I created a brand new .NET 2.0 DLL, and LabView didn't crash until I ported code from the other .NET DLL into it.  I don't want to give out source code, but thanks for offering.  I'll continue to look at it and let you know what I find.

[Lycangeek]

The main thing I can think of that is different is how LabVIEW uses AppDomains. In most .NET applications, you have the DefaultDomain created for you and it's wiped out when you stop the app. LabVIEW, however, creates a specific AppDomain for each project you create (in fact, we create one for edit time and one for runtime). This allows you to have different projects loaded with different "home bases" for loaded your private assemblies.

In addition, we do a careful shutdown of the appdomains when we exit - I'm not certain how much shutdown goes on when you exit out of a simple .NET app since the process itself is being wiped out - the LV process isn't destroyed until quite a while after we destroy the appdomains.

If you have any native code interops w/ threads, events, etc., it might be that something is trying to call back into the .NET appdomain we've destroyed before the process is gone. For example, are you using the .NET container at all?

[georgedev]

You might be on to something there.  The .NET assembly that the LabView project loads directly has a reference to another .NET assembly that implements a state machine.  The state machine is multi-threaded and uses delegates.  One of my thoughts was that on cleanup a null reference was being accessed, but it is difficult to prove.  It appears right now that the state machine is the problem, because calls to start the state machine in a class seem to make LabView class.  Meaning that I commented out those calls and LabView didn't crash, but of course the code didn't work.  That seems to correspond with what you're saying.  I'm going to try terminating the threads explicity before exiting.

Do you have any other suggestions?

[Lycangeek]

No, sounds like your going down the right path. I'd make sure you don't explicitly terminate the threads, but instead "unblock" them and allow them to exit normally - killing threads can leave your process in a bad state.

[georgedev]

I'm setting all of the custom thread objects to a terminating state and that causes the Run method to terminate eventually.  I'm still working on it.

[georgedev]

I've found the culprit after extensive testing.  The .NET code uses the "timeSetEvent" function in the Win32 multimedia library via a DllImport.  That function creates a timer that has a true 1 millisecond period, and that's why it is used instead of the other timer implementations.  I call the function "timeKillEvent" to destroy the timer, and it returns zero indicating success.  The "timeSetEvent" function creates a thread for the callback, however "timeKillEvent" doesn't destroy that thread.  Windows also re-uses the thread across multiple calls to "timeSetEvent" and "timeKillEvent".

Just as a test, I replaced the multimedia timer with a .NET timer and LabView didn't crash any more.  I'm still looking for a fix for the "timeSetEvent"-created timer though.

Thanks for your help so far, Brian.