TestStand Debug Options Warning

[davidpcl]

Hi,

We have what appears to be a degrading problem with one of our Sun Sensor Test Systems. We are on a more and more regular basis seeing TestStand completely hang, followed by this dialogue when killing all threads in execution.

This may be purely as a result of killing the execution, and nothing to do with why TestStand is hanging on calling a particular step.

Just to expand a bit, the step that TS is hanging on is nothing more than a LabVIEW dialogue box with a few radio buttons and an event handler in it.

In terms of our system, we are running LabVIEW 2012, and TestStand 2012 on a Windows 2007 Business Server.

Any ideas or pointers where to look gratefully received,

Thanks,

Dave

[~jiggawax~]

I usually get that error when I don't call ReleaseSequenceFileEx after explicitly opening a sequence file.  This is from the TS Help:

http://zone.ni.com/reference/en-XX/help/370052M-01/tsapiref/reftopics/engine_getsequencefileex_m/

Are you calling that method?  If so you need to properly release it.  Sometimes you could be calling it in a loop.  You need to to release it for every iteration.  Sometimes you could be having a race condition where the test terminates or something and the release doesn't get called.  Or the release is inside of a conditional block that sometimes evaluates to not execute.

Just some things to consider.

Regards,

[~jiggawax~]

I think it is because you are killing it prematurely.  If your VI is hanging TestStand then you can try changing the preferred execution system to be Other 1 in the VI options.

[davidpcl]

Hi Jigg,

Thanks for your responses - this turned out to be a bit of a red herring and was, as you've mentioned down to killing it prematurely and not the actual problem which was causing us to have to kill things prematurely.

Sadly, we never quite figured out what the problem was and had to take the nuclear route and re-install our software packages which fixed things so it looks as though some sort of corruption had got in there somewhere which again, we cannot pin down.

Dave