"Error Code 1172" .NET Invoke Node returns null after 20+ hours

[Siriusly]

All,

I am using a custom .NET 4 assembly and LabVIEW 2012 SP1 to communicate to our recievers.  The communication works fine up until the 20+ hour mark then a ".NET Invoke Node" with one input returns a null value. The offending ".NET Invoke Node" is called every 200mS for the entire 20+ hour duration.   I have been able to reproduce the issue in the LabVIEW development environment and have proven that the input to the ".NET Invoke Node" is valid.  The .NET developer insists that the "Method/Invoke Node" being called cannot output a null value and therefore the issue is in LabVIEW.  The error out on the invoke node is clean (No Error), but when the output reference is used in the following constructor an error is returned stating that the input is "null".  

This is the error 

Code 1172: Error creating instance of SSPParameter in assembly SPCSDK.Protocols.SSP.SSPParameter, SPCSDK.SSP, Version=1.0.16.25927, Culture=neutral, PublicKeyToken=null, (SPCSDK.Util.Error.InvalidInputParameter: Invalid input parameter(s).) <append><b>SPCSDK.Util.Error.InvalidInputParameter</b>

I have attached an image of the VI with some nomencature explaining where null is created and where error is generated.  I added the "Close .NET Reference" after the invoke node today and do not know if it has fixed the issue as it needs to run overnight to find out.  

How can I find out if this is a LabVIEW issue or a .NET issue?  

What steps would you take?  

What could make this crash after 20+ Hours?

Thanks,

[nathand]

The first thing I'd check is that you don't have any error immediately prior to the constructor input. Maybe you've already checked that, but that's not where you put the arrow so I wanted to confirm.

Why are you passing the same reference to the +.NET Error Info function as both a scalar and an array?

The notifier operations don't make sense to me. You'll always destroy the notifier after the first while loop iteration, which means the second iteration will always return an error, so why have the while loop? Do you need to constantly obtain and destroy a new reference to the same named notifier? Might be better to reuse the same one, and store the notifier in the cluster instead of the notifier name. The Wait on Notification with the note that says "Clear old Notification" does not do that. If you want to clear an old notification, use Cancel Notification. Alternatively you could set the "Ignore Previous" input to True for the Wait on Notification inside the while loop. Wait on Notification does not remove the message from the notifier, and each instance of Wait on Notification independently tracks the last notification that it saw, so what you seem to be trying to do actually has no effect.

What's going on inside the constructor?

[tst]

---

@Siriusly wrote:

How can I find out if this is a LabVIEW issue or a .NET issue?  

What steps would you take? 

---

Other than what Nathan suggested, you can also ask the .NET dev to add logging to the constructor and the CreateUN8 method and add your own logging to the code (try typecasting the reference to a U32 or U64 to get a value). You could probably log the reference value, the errors and maybe some other relevant values. This could at least show you where the issue is coming from.

[Yamaeda]

20h hours sounds like either a ms rollover issue or enough unclosed references to run into memory issues. My primary guess is the latter. If you can turn down the loop time to 1 or 10ms instead of 200 i bet you get the issue alot faster?

/Y

[Yamaeda]

When are the UN8s closed?

/Y

[Siriusly]

Wow thanks for the quick feedback guys,

Nathand,

   There is no error immediately prior to the constructor.  The "+.NET Error Info" is a VI that I used for troubleshooting purposes only, it adds values to the error cluster upon error which is later written to a log file.  So the references needed to be "split" to feed this "Add Error Information" VI.  

   As for your notifier comments, I appreciate your knowledge on this subject and have made the changes you have suggested.  I have attached a image of the newly modified VI which includes a diagram disable that illustrates the "Constructor Node 1" VI.  

Tst,

   I have added the logging on the LabVIEW side with the "+.NET Error Info" VI.  This has helped prove that the error is not generated from the Create UN8 method and that it is outputting a Null value into the "Constructor 1" VI.

Yamaeda,

  I am unfamiliar with the MS Rollover issue you mentioned but I was also leaning towards the unclosed references idea.  I have closed the references on the "SSPParameter Create UN8" invoke node.

   Are you stating that I should close the Create UN8 output that is feeding the "Constructor 1" VI as well?

I have also created a VI that runs this command with a loop rate of 30 mS

Currently, I have made a new EXE with the aforementioned changes which will be running overnight on a worker laptop in its intended program.  Also in source code I will be running this command with a faster then normal loop rate.  I will update this thread as soon when the results are in.

Again thanks for all of your support it is greatly appreciated.

[Siriusly · Accepted solution]

I have found a .NET/LabVIEW memory leak. See the attached image.  

The first VI in the  image does NOT close all the .NET references properly because the parameters output is null. 

The “parameters” output from the constructor does not return the references that were input to the constructor therefore the references were left open.  The second VI in the image shows the references being properly closed.  

The Trace Execution Toolkit was very helpful in tracking the .NET memory leak by identifying the handle and resolving the issue.  

Thanks for your help.