Teststand 2023 Q3 Login / Sequence editor does not close

[Pius]

Hi

I'm using now Teststand 2023 Q3.

Normally we disable the login form in the Station options under User Manager:

But, with this settings, after Exiting the Sequence Editor, he runs further as background process in Task Manager and keep the License until I manually end the Task.

Before closing:

After closing it is still open in Background processes:

When I change the Login settings to login On Start:

I can close the Sequence Editor and there is no process in Task Manager running. As it should be.

How do you handle the Login Settings on Production Machines?

I don't care about this NI User and it has worked sinces Teststand 2010 with disabling the Login.

In my opinion this is a Bug from Teststand.

I know that this does not appear on NI Teststand 2020 and NI Teststand 2022.

regards

Pius

[Scott_Richardson]

Pius -

Based on my previous knowledge of how the Sequence Editor was written, it is likely that something is not getting cleaned up properly. In general the Sequence Editor uses app domains to try to have more control over the shutdown process. Likely that either the required two stage TestStand shutdown is erroring internally, or that are .NET threads that are not exiting as expected and this is preventing the process from exiting. 

Questions:

1. When you experience this issue, are you just launching the Sequence Editor and then closing it?
2. Does this station have any custom Login/Logout or Station callback functionality implemented?
3. You images suggest you are using TestStand 2023 Q4 32-bit, does it occur with 64-bit? Do you see this on only one system or more than one? I tried TestStand 2023 Q4 64-bit and could not reproduce the issue.
4. Is the LabVIEW ADE getting launched automatically when this occurs?

You might already know this but a possible workaround is to define a TestStand user that matches the name of the Windows user, specify a blank password, and then leave Login on Start enabled, and also enable the "Automatically Login Windows System User" option. This is what I do with my development system and I also leave Check for Privileges enabled.

[Pius]

Hi Scott

Thanks you for following up.

Here my answer to your questions:

1. I just open and close the Sequence Editor
2. I do not load any sequence. So no callback is used to custom login.
3. It happens also on 3 other machines, one Win11, two with Win10. All are using Teststand 2023 Q3 32-bit.
   I have only on one machine the 64-bit also installed, and it is the same behaviour. Without login on start, it keeps a process running after closing the Sequence Editor.
4. No Labview is not started. Labview is set to run with Run-Time Engine, not as Development System.

Your pointing on the Callback, this made me the following test: 

• We are using a modified SequenceModel, so I set back to the original SequenceModel
• With original SequenceModel, the process is getting closed, even with no login on start!

Now, I will start searching for the issue on our modified SequenceModel.
I migrated our modified SequenceModel from NI Teststand 2020 to the original SequenceModel NI Teststand 2023.

I will keep you posted.

[Pius]

It seems the Callback SequenceFileUnload makes some problems:

When I add this Callback Sequence to my SequenceModel, the process keeps open without the settings "Login on Start". Even the Sequence is empty.

When I delete this Callback from my SequenceModel, it works!

I reproduced it, by adding this empty Sequence Callback SequenceFileUnload to the original SequenceModel.

May be I need to do the workaround with adding the Windows User as Teststand User.🤔

[Scott_Richardson]

The TestStand sequence editor and engine internally control when the default process model is loaded and unloaded, and it is likely that the unload is occurring later during shutdown and something is not being handled correctly. I personally do not like the use of load and unload callbacks. I think using them in a model is obviously problematic. I think you need to look at what you are trying to accomplish in the unload callback and determine if it is really necessary and/or if there are any alternatives that do not require an unload callback.

If you really need the unload callback, you will likely need NI to look at the underlying cause of what you are experiencing.