"The TestStand service did not start up promptly"

[CIM1]

I have a LabView Operator Interface startup problem with TS 4.1. If the OI is started immediately after system boot the operator may get apopup error from TestStand:

"The TestStand service did not start up promptly"

The TestStand Service has a dependency on RPC so if either does not startup before the operator launches the OI, he gets the message. If he dismisses the message there is no further error i.e. the software continues to work OK.

The real problem is the end user does not like this message and wants it removed.

Any suggestions how I can get rid of this message?

Only ideas I can see at the moment - either to have some kind of delay timer on startup (this would need to be around 1-2  mins after boot on the system in question to stop it happening) or perhaps some LabView code to poll the status of the TestStand service somehow so that we wait for service to start before the OI communicates with testStand - and thus the popup does not occur.

[dug9000]

The service should not normally take any significant amount of time to startup. There are some issues with service startup that we have noticed in some cases, but I don't remember the details. I will try and find out and get back to you. In the meantime, or as a possible solution, you can use the Windows SDK to check the status of the service and to wait until it is running. I'm not sure if the following can be directly translated into LabVIEW dll calls, but it would definitely be possible to create a C/C++ dll with the following code in it and call it from LabVIEW (If you do not have access to a C/C++ compiler and/or would like me to, I can probably build a dll with this code in it for you):

int MakeSureServiceIsRunning(void)
{
    SERVICE_STATUS serviceStatus;
    SC_HANDLE hService = NULL;
    SC_HANDLE hSCM = NULL;

    // Put variable into a good initial state for return value.
    serviceStatus.dwCurrentState = SERVICE_START_PENDING;

    hSCM = OpenSCManager(NULL, NULL, SC_MANAGER_CONNECT);
    if (hSCM == NULL)
        goto Error;

    hService = OpenService(hSCM, "National Instruments TestStand Service", SERVICE_QUERY_STATUS);
    if (hService == NULL)
        goto Error;

    do
    {
        if(!QueryServiceStatus(hService, &serviceStatus))
            goto Error;

        if(serviceStatus.dwCurrentState != SERVICE_RUNNING)
            Sleep(100); // don't just do busy waiting, give up cpu time to other threads.
    }
    while(serviceStatus.dwCurrentState == SERVICE_START_PENDING);

Error:

    if (hService != NULL)
        CloseServiceHandle(hService);

    if (hSCM != NULL)
        CloseServiceHandle(hSCM);

    if (serviceStatus.dwCurrentState == SERVICE_RUNNING)
        return 1;
    else
        return 0; // An error occurred, or service is in an unexpected state.
}

Or alternatively, if you want to do the polling inside of LabVIEW you could just do the following in the C/C++ dll:

int GetTestStandServiceStatus(unsigned int *serviceStatusReturnResult)
{
    SERVICE_STATUS serviceStatus;
    SC_HANDLE hService = NULL;
    SC_HANDLE hSCM = NULL;

    hSCM = OpenSCManager(NULL, NULL, SC_MANAGER_CONNECT);
    if (hSCM == NULL)
        goto Error;

    hService = OpenService(hSCM, "National Instruments TestStand Service", SERVICE_QUERY_STATUS);
    if (hService == NULL)
        goto Error;

    if(!QueryServiceStatus(hService, &serviceStatus))
        goto Error;

    *serviceStatusReturnResult = serviceStatus.dwCurrentState;

    CloseServiceHandle(hService);
    CloseServiceHandle(hSCM);

    return 1; // success

Error:

    if (hService != NULL)
        CloseServiceHandle(hService);

    if (hSCM != NULL)
        CloseServiceHandle(hSCM);

    return 0; // An error occurred. Perhaps TestStand service isn't registered.
}
 

[dug9000]

Just wanted to follow up and let you know, one situation in which we've seen services take a long time to start up is on machines that are on a local network, but that do not have a connection to the internet. In such cases we've seen one of the default Windows services take a long time to start up (about 60 seconds) which in turn delayed the TestStand service from starting up. Without this issue, the services generally start up within a few seconds, but there seem to be some situations in which a service outside of our control will block (perhaps waiting for a timeout), that, in turn, delays the startup of the TestStand service.

Is your machine on an isolated network (i.e. on a local network, but not on the internet)?

-Doug

[CIM1]

Hi, thanks for the code, I will try to build a dll in CVI as soon as I get SDK support installed (I am out of office and don't have Dev Suite disks to hand) and try it.

I think polling from LabView should be acceptable although obviously speeding up the TestStand startup would be preferable overall.

The target system is off the network completely - one theory which a colleague has suggested was that maybe it was looking for some network drives at startup from when it *had* been networked, but this is not yet clear.

The test system includes a PXI chassis with various instrumentation which takes a while to initialise at startup - needs further investigation but it seems that when the NI digital I/O cards in the system display a green ready light, this appears to happen around the same time after boot-up as the TestStand service is started.

[dug9000]

In order to try and figure out which service is taking so long, you might want to try launching the Adminitrative Tools->Services control panel as soon as possible after rebooting the machine and see if you can find a service that is consistently in the "starting up" state. If so, that might be the service that is causing the problem. If you are able to narrow down which service it is, please let us know.

Thanks,

-Doug

[CIM1]

Thanks for latest suggestion - I had looked at services already but only checked RPC as a listed dependency (which starts up quickly...)

Turns out the Workstation service is in Starting mode for an extended period of over 1 minute. When it starts, a load of other services start soon after, including TestStand.

I tried disabling the Workstation service and the TestStand service started promptly so I was able to launch our Operator Interface without error pop-up, soon after Windows boot.

This may be a viable fix (assuming there are no other problems caused by disabling the workstation service) as the target system is not on a network.

That said, Workstation lists the following dependencies

Alerter

Computer Browser

Messenger

Net Logon

RPC Locator

Any idea if TestStand, LabView or CVi runtime will have any problems with that lot being disabled?

Thanks again for your help on this.

[CIM1]

"Just wanted to follow up and let you know, one situation in which we've seen services take a long time to start up is on machines that are on a local network, but that do not have a connection to the internet".

 I forgot to add - although our target system is off the network, the test system on which I just disabled the Workstation serivce and found it booted up quickly does have a connection to the Internet.

[dug9000]

According to the description of the Workspace service "Creates and maintains client network connections to remote servers using the SMB protocol. If this service is stopped, these connections will be unavailable. If this service is disabled, any services that explicitly depend on it will fail to start.", it sounds like it's related to file server network connections. SMB is primarily used to share files over a local network (http://en.wikipedia.org/wiki/Server_Message_Block). You might want to check to make sure you don't have things set to try to reconnect to a local file server at startup (i.e. mapped network drives). If so, that might be the cause of the 1 minute hang.

Either way, it might ok to have that service disabled as long as you don't need the network connection capabilities. You might want to check if any other important services depend on that service though just to make sure.

-Doug