Is there a way to allow DLLs to call sup-application in TestStand?

[marek d]

Hi,

I've got a TestStand sequence that calls a DLL function which is generating an EAccess Violation.

Now this particular function seems to run two seperate sub process of some kind. I can't figure out what they are, but when I run the DLL function in a CVI environment, two items appear on my windows taskbar and then disappear just prior to the function finishing successfully.

I've been told that TestStand likes to control its environment... my current theory is that the error generated in TestStand during the funciton call has something to do with the function attempting to launch a thread (or some kind of application) and TestStand not allowing it to do so. Is there a way to let the function run mul
tiple threads without TestStand's permission? Or turning off TestStands control for one step? Or something to that effect?

I've tried making a DLL wrapper for the DLL function... but it has the same effect since a sub-thread is trying to be created.

Thanks,
Marek D.

[Shiner]

A few questions...

Who wrote the DLL ? Is it a 3rd party vendor ?

Most Access Violations I have come across are due to one thread trying to access data in a thread that has been terminated already...

One example of this is say creating a TCP connection and installing a callback to respond to data. You pass the pointer to that call back function into the TCP application, and it will call your callback function when data is ready (for example). Lets say you close your thread which handles the callback function, but did not terminate the TCP process, when data is next ready, it will try to call the callback function, which is no longer in memory, and it will cause an Access Violation....

See if you have to call other functions in that DLL to create and destroy o
bjects prior to, or post calling the main function you want to.

You may be in the right direction by creating the wrapper to allow a single teststand call to do this.

Let us know more details and I will think on it further....

Regards

Chris

[marek d]

Chris,

It is a third party DLL (written by ScanWorks).

I do not think the DLL is trying to access a thread that has ben terminates, but rather is attempting to launch multiple threads.

As I mentioned before, when I run the function in a CVI environment, two programs launch (I know this because I can see two blank items on the taskbar in my windows environment). Just prior to finishing the DLL the two programs close.

example code:
printf("just before function call\n");
function();
printf("finished function call\n);

The output for this would be as follows:

just before function call
[two items appear in the taskbar]
[both items disappear]
finished function call

So my theory is still this: th
at the DLL function needs to launch seperate threads but TestStand is not allowing it to do so. I beleive this because these two mystery programs are not appearing to launch in the TestStand environment. Regardless of whether I us a wrapper or not, the same error occures.

So is there a way to allow functions to launch other application without TestStand controlling it all?

Marek D.

[Shiner]

Marek...

The number of threads that TestStand can run is not the problem I believe.
I have DLL's that launch many threads that continue to run even after Teststand sequence execution has completed. I don't believe there is an issue with repect to this and TestStand.

It maybe as something as simple as the LOAD property for that step being set to unload as soon as step finishes.
In this example, the Step calls the DLL which executes new threads, but since it returns before those threads execute, the sequence unloads the DLL (or tries to). Since the threads are still running, they may try to access memory no longer under control of the teststand process.
In fact, I am sure this is your problem. You would not see this when in a developement envir
onment outside of teststand.

Have a look at the step properties or the sequence properties, and try setting (or verify), the step type is set to load on Sequence Load, and Unload on sequence unload.
If you sequence is dynamically loaded and unloaded, you may have to play around with that a bit more.

I am still convinced that your 'threads' are running when the DLL has been unloaded, or similar.

Try the above, and let me know how you get on, or if you need a better description, I can go look at TestStand and give you better directions.

Chris

[marek d]

Chris,

I changed the "Load Option" under "Run Options" for each of my steps to Preload when opening sequence file and the "Unload Option" to Unload when sequence file is closed... and it did not fix the problem.

This is what you we wanted me to change, right?

Marek D.

[Shiner]

Yup...

One more thing to try,

Go to the Edit Menu, select Sequence File Properties and ensure that the Load and Unload options are set to use Step Options.

If that don't work, I will have to think some more.

Sorry if I am leading you astray on this, I'm just throwing a few ideas out to see if they help.

Regards

Chris

[Jason F.]

Hi Marek D,

This question appears to be related to another post that you and I were working on before. Does this post -> http://exchange.ni.com/servlet/ProcessRequest?RHIVEID=101&RPAGEID=135&HOID=50650000000800000040520000&UCATEGORY_0=_8_&UCATEGORY_S=0 <- have anything to do with what you are asking now? If it does did you try the suggestion that I mentioned last in the other thread? Your use of the dll in TestStand does not follow the exact same pattern as what you demonstrated in CVI, and this would be a good starting point.

To answer your question though, no, TestStand does not have a problem with a dll that it loads and invokes functions on trying to spawn new threads. This is a rather common scenario in fact. As I stated before it appears that since th
e dll is loading fine and TestStand is able to access its functions ok, there is not really a problem with how TestStand interacts with the dll. In fact if there were a specific problem dealing with this dll trying to create additional threads there could indeed be a problem in that its threads are not being managed properly from within inside the dll itself. Trying to guess at how the dll operates is generally a timewaster, unless you know its exact requirements you may never be able to get it to work. It appears that there is either an external dependency you are not taking into account with this particular dll or you are using it improperly in TestStand. Trying my previous suggestion of trying to reproduce the CVI setup exactly is your best bet.

Jason F.
Applications Engineer
National Instruments
www.ni.com/ask