Forum Discussion

Fimbultyr's avatar
Fimbultyr
Contributor
7 years ago
Solved

Test Execute/Complete Service not starting reliably

Hi guys,   I am currently researching a phenomenon of my QA Environment regarding the Test Complete Services. To be precise, TestComplete 12 Service does not start automatically, as it is intended...
  • Fimbultyr's avatar
    Fimbultyr
    7 years ago

    I kind of found a workaround for this, but i expect that Smart Bear may have a look in this issue as well.

     

    1. Ine the Networksuite/Jobs set the delay of the Test VMs to 10 Minutes Timeout.

    2. In Client OS, set the TestComplete Service from Automatic to Automatic(Delayed)

    3. In Client OS Registry, modify Timout of Services from 30.000ms to 60.000-120.000ms

     

    The Reg-Entry is:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ServicesPipeTimeout

    If it is not existising, just create it as DWORD.

    Default Value is 30000, i have set it to 120000 and did not get an error after this.

     

    I will still monitor the VMs to see if this could be a longtime fix.

     

    Cheers,

    Constantin

Fimbultyr's avatar
Fimbultyr
Contributor
7 years ago

There are 2 additional Steps you can try.

 

1.)You could as well try to improve the performance of your System.

 

I benchmarked my VM Environment and found some issues with the ESXI HDDs.

 

If I let my VMs run on the normal SATA-HDDs on ESXI, I encountered boot times of around 9 Minutes for Windows 10 VMs.

After moving them to SATA-SDD of the ESXI the VMs now boot up in 30 Seconds.

 

This solved a lot of issues for me.

 

2.) I activated automatic sign in to the OS.

So basically after booting the test VMs, they now log in automatically to the Administrator account.

This is of course a security issue and should only be done in controlled and isolated QA Environments.

 

I had the impression that the RDC Connection from Testcomplete somehow caused an Issue with the bootup of the Service.

If you log in to the account manually before connecting via RDC the Service did run more reliably.