NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Intermittent Error 17501 when using .Net object in TestStand

Hello
I have a sequence which creates a .Net object, uses a method  and retrieves a couple of parameters associated with the object. The problem is that sometimes I get the following error:

       Unexpected Operating System Error
       Error code: -17501
       Source: TSAPI

The sequence also contains steps which use the .Net adapter to call various static methods but these are not causing a problem. If I remove the steps associated with the creation and use of the object there is no longer an error. The sequence also has some LabView steps, so the associated runtime for those also runs.

The object I'm creating does the following:
       Creates an IP socket connection
       Sends a command via the socket
       Returns a couple of parameters on request

If I create and use an equivalent object within the VisualStudio IDE there is no problem (the class was written in C#).

Unfortunately the problem doesn't happen every time and I'm having trouble reproducing it repeatedly.

I'm using the following software:
       LabView 8.0
       TestStand 3.5
       .Net 1.1
       WindowsXP

I've searched the forums for this error and there are a number of related posts but none that seem like a solution for this case. Any ideas gratefully received.
Thanks


0 Kudos
Message 1 of 5
(3,293 Views)
0 Kudos
Message 2 of 5
(3,261 Views)
It sounds like you might have a problem with memory corruption. Such problems are very difficult to debug because the errors don't happen consistently or show up right away or necessarily even show up where the error in the code is. Also in environments that use memory less heavily than TestStand (i.e. a simple .net application) it might take longer to show signs of memory corruption even if the same bug exists in both places. Are you by any chance calling any DllImported code from your .net code, or any other calls into unmanaged code? Such calls are more likely to have issues with memory corruption than normal .net code. Also it's possible that memory is being corrupted by a completely different code module in your system and the error isn't detected until later on when the memory is next accessed. Try to narrow things down to the minimum amount of steps and code that reproduces the problem, then examine that code very carefully for correctness. Any sort of memory buffer access in such code modules should be looked at carefully, especially in dll code modules where errors are much more common and easier to make (including dlls called by labview vis if the VIs are being run in process with the run-time engine). You might be able to narrow things down by running code modules in another process where possible and seeing if the problem goes away or is limited to the new process. From teststand if you run VIs in the labview environment they will be running in a different process. Similarly you might be able to run .NET code in a separate process using .net remoting as well.

Hope this helps,
-Doug

0 Kudos
Message 3 of 5
(3,234 Views)
Another issue that might actually be more likely in this case is that your .net objects might be using up a system resource if you are not calling Dispose on the related objects when you are done with the resource. In general the garbage collector will free up the resources from the objects eventually, but it might not happen fast enough to avoid running out of a particular resource unless you explicitly free the resource by calling the Dispose method on the objects involved. Also, if you are able to narrow it down and can post the code involved to the forum, we might be better able to help determine the cause.

-Doug

0 Kudos
Message 4 of 5
(3,224 Views)
Hi
Thanks for the replies. I've found the problem and it was due to a poor understanding of exception handling. The error was occurring due to an exception being thrown by the C# socket related code. Normally when this code is called by other C# classes the exception is passed up to the caller and is handled there. When calling the code from TestStand and an exception is thrown, TestStand doesn't know how to handle it and flags this very general error message/code. I now handle the exception within the code that's called from TestStand and all is well.
Cheers
0 Kudos
Message 5 of 5
(3,198 Views)