.NET object reference invalid

[Mac671]

Hello,

In my company we've run into a wierd problem that we can't explain.

We're three developers and we're using TestStand 4.1.0.228 and LabVIEW 8.6.1.

There is a .NET application that I've written in the form of a DLL.

The idea is to call the constructior of the main object in that dll, and than work with it via methods and properties.

Now on every single one of our machines it works fine when we use only LabVIEW, to create the object and work with it.

We also have a test stand sequence, that creates the .NET reference in one step.

Stores that reference in a local variable of the type of object.

And than uses that reference by passing it to VI's that perform actions on that single object instance throught the test sequence.

On only one of the computers the test stand seqence fails, and gives the message: that the .NET reference has become invalid.

When the first call to consume the step is called.

Does anyone have any ideas on how to track this down?

We're tried using the same files, and same versions of NI Software, we all have .NET framework 3.5 sp1 which is required for the app to run.

Any ideas would be appriciated? I'm dry of ideas for today.

[Mac671 · Accepted solution]

Hi,

I want to follow up on this thing. As for me it's good enough for the X-Files.
We've done some additional testing on that one PC that failed.
We tried repairing / and uninstalling TS 4.1 form that machine.
But it still failed.

After installing TS 4.2 and using LV 8.6.1 it started working.
When we switched back to TS 4.1 and LV 8.6.1 it still broke, but only on that PC.

In the end we tried using TS 4.2 and the LV 8.6.1 VI's saved as LV 8.2 VI's and that didn't work too.
We have a quite considerable code base in 8.2 that is why we hestiated to migrate to LV 8.6.1.

We also use TS 4.1 on production a lot...
but bottom line is that what we're going to do is update to TS 4.2 and LV 8.6.1 to remedy this.
This is what I would call, the practical way to solve the problem:

“The theoretical approach is when we know everything and nothing works,
The practical approach is when we don’t know anything and it works,
In this room we combine the theoretical and practical approaches,
Nothing works and no one knows why”
- That was sign that was on the door of the Circuit Theory Lab back at my university when I used to study.

[dug9000]

What appdomain does the object live in? Is it derived from MarshalByRefObject? I'm not entirely clear on what you are doing. Are you calling a .NET dll from a teststand step, storing a .NET object in a local variable using SetValInterface and then passing that into a labview VI and somehow inside of labview making .NET calls on that object?

One thing you should be aware of is that TestStand and LabVIEW both create separate appdomains in which they load and call .NET assemblies. In the case of TestStand at least, the appdomain will get unloaded once the .NET adapter thinks it's no longer in use. This might happen at different times if the version of TestStand on a particular machine is configured to unload modules earlier than other machines (e.g. unload after step executes). To make sure TestStand doesn't destroy the appdomain you can use the .NET adapter to call a method that returns a .NET object and store it in a TestStand Object Reference variable (NOTE: Storing a dotnet object using SetValInterface is not currently done in a way that keeps the TestStand execution appdomain around). As long as you keep that object stored in the Object Reference variable TestStand will not unload the appdomain. Perhaps you were getting an error because your object was created inside of the TestStand appdomain which was then getting unloaded before the object was done being used. Without more details about what you are doing it's hard to know for sure, but it's something you might want to try.

Hope this helps,

-Doug

[Mac671]

Hello,

What I'm trying to acomplish is to consume a WCF Web Service.

The service has a WebService client genetated with the usage of svcutil.exe.

Compiled to a dll.

That dll is wrapped with some LabVIEW.vi code, that provides VI's that are used in TestStand.

The first VI creates the .NET client, and passes it through a terminal to TestStand's Local Variable of the type object. The other vi's use that Local variable reference to the client, to call methods of the WebService, and do some additional stuff with the data. ( so LabVIEW adapter is used from TestStand's point of view.).

The object is not derived from MarshalByRefObject as I'm using WCF not .NET Remoting.

I've made an example app that is very simple, but it basically has the same architecture as the app we're having issues with.

see the bottom 2 posts of thread:

WCF example

Thanks for the tip about setting the adapter to unload modules after execution, this might be the thing, when I get more feedback I'll post back in here.

Thank You,

Maciej

[Mac671]

My collegue told me that he had looked into the setting od unloading a module after step exectuion. But that din't fix the error he was getting on his PC.

Here is an example that has the similar philosophy to the application I had issues with.

Take look at it if you want to see how the architecure looks like, and maybe you'll have some other suggestions.

Thank You,

Maciej

Message Edited by Mac671 on 10-26-2009 11:37 AM

[dug9000]

I misunderstood. I thought you were using the .NET adapter. It looks like all of the .NET code is in LabVIEW VIs. That should work ok like you have it written, however, one thing I'd like to point out though is that you should probably be closing the references inside of LabVIEW whenever you are done with each .NET reference which LabVIEW gives you (I don't think these are collected automatically in LabVIEW like they are in .NET languages). I'm not entirely sure when/if LabVIEW destroys the appdomain it uses to execute .NET code. It's possible that your VIs getting unloaded could effect this so checking the load options still might be the way to go.

However, another possibility that you should be aware of is that all remote .NET objects potentially have a lifetime timeout. What this means is that if they aren't accessed recently they will become invalid. This is a feature of .NET and will depend on how your server makes use of it. See the following links for more information:

http://msdn.microsoft.com/en-us/library/system.runtime.remoting.lifetime.ilease.aspx

http://msdn.microsoft.com/en-us/library/system.marshalbyrefobject.initializelifetimeservice.aspx

Hope this helps,

-Doug

Message Edited by dug9000 on 10-26-2009 01:27 PM

[Mac671]

Hi Doug,

The example below run on 4.1.0.228 TS and LV 8.6.1 on that "special machine" produces the fault.

It works on all other machines.

Regarding the Marshalbyrefobject suggestion I will need to do some reading. But like I've stated below I'm using WCF not Remoting.

I need to educate myself though about the LabVIEW unload options.

I will get back if I get this, but unfortunately I'm swamped with tons of other sutuff that I need to do by yesterday. So this will probably have to wait.

Thanks,

Maciej

[dug9000]

I checked with some developers here and unloading the VI from TestStand before you are done with the .NET references you got from them will cause the reference to become invalid like you are seeing so that is the most likely explanation. On the machine in which you are seeing this problem, check the both the step and sequence file properties for the unload option you have set. In the sequence file properties dialog the unload option should be set to "Use step unload option", and the step's unload option (in the step settings panel run options) should be "Unload when sequence file is unloaded". Basically you need to make sure that the VIs which you got the references from aren't unloaded before you are done using the references.

Hope this helps,

-Doug

[Mac671]

Hello Doug,

I've recieved feedback from the collegue that had the issue on his PC.

He had also contacted you guys at NI, locally to him.

They have suggested to go to the 

c:\Documents and Settings\All Users\Application Data\National Instruments\TestStand\Cfg\testexec.ini.

Rename it.

And let TestStand replace it to the defaults after start up.

I do not know which setting exactly caused this thing. The most logical would be the one you mention (that is unload module after execution), but I specifically asked to check that one, and got confirmation it had no effect.

Essentially this boils down to your first reply ini your thread that you had correctly suggested that this must be something specific to the configuration of that particular TS installation, on which we're getting the failures.

This has fixed the problem.

Thank you for your interest and posts here.

[Mac671]

Just as a follow up.

The collegue I mentioned has sent his testexec.ini file to his local NI representative, in the hope of finding the setting that caused the behavior.

As I have stated before we've tried multiple settings form TestStand GUI but we coulnt find the one that caused this behavior.

If I get the answer to this I will post it in.

Cheers,

Maciej