Unable to Launch Recorder Error

Hi Glenn,

I am sorry to hear you have encountered such misbehavior after the Windows update and I will be happy to assist you further. 

Based on the logged error message there are few things you can verify on your end. Please read further to find out what these are. 

Attach the recorder to an already running IE instance 

Internet explorer is the only browser, which you can attach the recorder to and this is the first thing to give a try to. Please, start the browser without Test Studio and navigate to the page you need to automate. Once this is loaded, you can try to attach the recorder to the web page. Please, let me know what the outcome will be? 

Admin permissions 

If the above is still not attaching the recorder to the browser, next to thing to verify is whether the user you are logged in has full admin rights on the current Windows installation. You may need to contact your IT department to check if there are any changes related to the user permissions after the update, which you are not aware of. You can also check the UAC settings and if these are disabled - Test Studio requires admin rights and turned off User Account Control because of the way it plugs in IE and WPF applications. 

Antivirus software 

Possibly, there could be a newer version of an Antivirus system deployed, or its settings could be changed with the Windows update. This could be another possible change that might affect Test Studio recorder and Internet Explorer browser. If it will be possible, you can disable the antivirus and try the recording again. Will there be any change in the behavior? 

I hope that any of the above will turn out to be the showstopper and you will be able to fix this. However in case you need any further assistance, please get back to me. Thank you in advance for your cooperation. 

Regards,
Elena Tsvetkova
Progress Telerik

The recording to the existing browser works, but this brings up another issue: How do I execute this test afterwards?   When I try to execute the test, it tries to bring up the browser and I have the same issue again with not being able to attach.

Hello Glenn, 

Thank you for your cooperation.

Since the recorder gets attached to the running browser, probably the issue is not related to insufficient user permissions. What you can try for the execution is to increase the ClientReadyTimeout - by default this is 60 seconds, and for the current case you may need to even double it. Please give this a try and let me know of the outcome. 

As a side note, can you please elaborate more on what is the reason that IE takes that longer time to start and load the page? Is this related to the available resources for the machine, or it is anything else specific? Is there any option to allow additional resources for that computer? 

Regards,
Elena Tsvetkova
Progress Telerik

Thanks for your reply.  My point here is there is a means to attach to an existing IE browser when recording.  Is there an analogous way to attach to an existing browser when executing?  Or is there no way to do that?  Do I need to add some kind of command at the beginning of the script?  I hope I am making sense.

I dont know exactly why the browser coming up is so slow.  I work as a contractor to the Navy, and I know that their system has a lot of security stuff on it which no doubt slows things down.  However, it worked great until we did the 1803 Windows update, and since then its been very slow to come up.  

Hello Glenn,

Thanks for getting back to me. 

Did you have the chance to increase the ClientReadyTimeout and test it in execution time? Do you observe any improvement in starting the browser with larger timeout? 

The mentioned timeout is the one that can affect how long the execution will wait for the browser to start - this is the reason I am curious to find out if you had tested this on your end. I have to admit that there is no other approach - even a coded one, to control that. So, if you hadn't yet tried to run a test with larger ClientReadyTimeout, please take some time and give it a try and please share your observations. 

As far as I understand, the IE browser is starting too slow in general and it is not only Test Studio affected, since the latest OS was installed - is that correct or I have misread the details? However, if the IE misbehavior can be observed in all cases, you might need to contact the IT department of the company you work for and possibly discuss if there are any particular settings affecting the browser. There might be any solution on OS level which will allow you to use the IE browser without troubles. 

Please, do not hesitate to get back to me with any additional details or concerns you may have. 

Regards,
Elena Tsvetkova
Progress Telerik

Hi again.   Yes, I increased the Client Ready field to 600000 ms, but it doesnt seem to help.  I notice that my test fails after only 10 seconds, which is suspicious.   I decided to make a simpler script, so in my test I only have one command, 'Navigate to: 'https://www.google.com/'.  But it fails before the browser even comes up.  Here is the log:

'3/25/2019 4:29:16 PM' - Executing test: 'HomePage Services 2', path: 'HomePage Services 2.tstest.'
'3/25/2019 4:29:16 PM' - Using .Net Runtime version: '4.0.30319.42000' for test execution. Build version is '2019.1.212.0'.
'3/25/2019 4:29:16 PM' - Starting execution....
'3/25/2019 4:29:26 PM' - Failure detected during execution. Details:
------------------------------------------------------------
'3/25/2019 4:29:26 PM' - System.ApplicationException: Exception thrown attempting to launch Internet Explorer. Please make sure Internet Explorer is properly installed and you are able to launch it. ---> System.TimeoutException: Wait for condition has timed out
   at ArtOfTest.Common.WaitSync.CheckResult(WaitSync wait, String extraExceptionInfo, Object target)
   at ArtOfTest.Common.WaitSync.For[T](Predicate`1 predicate, T target, Boolean invertCondition, Int32 timeout, WaitResultType errorResultType)
   at ArtOfTest.Common.WaitSync.For[T](Predicate`1 predicate, T target, Boolean invertCondition, Int32 timeout)
   at ArtOfTest.Common.WaitSync.For[T](Predicate`1 predicate, T target, Int32 timeout)
   at ArtOfTest.Common.Win32.Connector.Attach(IntPtr& handle, Boolean findTabWindow, Int32 waitTimeout)
   at ArtOfTest.WebAii.BrowserSpecialized.InternetExplorer.InternetExplorerActions.LaunchNewBrowserInstance(Int32 timeout, ProcessWindowStyle windowStyle, String pipename, String url)
   --- End of inner exception stack trace ---
   at ArtOfTest.WebAii.BrowserSpecialized.InternetExplorer.InternetExplorerActions.LaunchNewBrowserInstance(Int32 timeout, ProcessWindowStyle windowStyle, String pipename, String url)
   at ArtOfTest.WebAii.Core.Manager.LaunchNewBrowser(BrowserType browserToLaunch, Boolean waitForBrowserToConnect, ProcessWindowStyle windowStyle, String arguments)
   at ArtOfTest.WebAii.Design.Execution.ExecutionEngine.InitializeWeb(ExecutionEngineCreateParams initParams)
   at ArtOfTest.WebAii.Design.Execution.TestExecuteProxy.CreateAndInitializeEngine(Test test, ExecutionEngineCreateParams cp)
   at ArtOfTest.WebAii.Design.Execution.TestExecuteProxy.ExecuteTest(ExecuteTestCommand command)
------------------------------------------------------------
'3/25/2019 4:29:26 PM' - Test completed!

Interestingly Im not seeing the "Unable to Launch Recorder Error" anymore, it just fails after ten seconds.

And yes, it did work before the Windows 10 1803 update and it doesnt now.   Not sure really what to do, could be a setting needs to be changed.   Dont know why its failing before it even gets to 60 seconds and the browser is seen.

 

Hello Glenn,

Thank you for sharing the error details from the test execution attempt.

Based on that execution log there are few suggestions from my end. Please, go through these below: 
- verify if the User Account Control is set to 'Never Notify'
- verify if you can record and execute a sample test against Chrome or Firefox
- verify if the user you login with, has full admin rights 

If you are not able to change the UAC level and tests can be recorded and executed against Chrome or Firefox, the most probable reason for the observed misbehavior is the lack of sufficient user permissions.If turns out this is the case, you might need to discuss this with your management and what options there are to change the user rights provided and grant you admin permissions for this machine. 

Please, do not hesitate to get back to me in case of any questions or concerns you might have. 

Regards,
Elena Tsvetkova
Progress Telerik

Hi Elana.  I see one problem right off the bat from your last post.  My UAC is set to "Always Notify".  Dont know if that is something I am allowed to change.  I will look into it.

Thanks,

Glenn W.

Hello Glenn,

Please, take the time to verify if any of the shared suggestions may be causing the troubles since the Windows update. Once you have anything on the case, do not hesitate to get back to me. 

Regards,
Elena Tsvetkova
Progress Telerik

Update:  Having the same problem with Chrome; actually Chrome is worse in that the app seems to crash when I try to record with it (note: thats with UAC at "Always Notify").   Then I ran with Admin privileges and changed UAC level to "Never Notify" for IE, but I had the same issue.  Not sure what else to try at this point.  So weird that it worked until I did the 1803 update and now it doesnt.

 

 

 

Hi Glenn,

I am sorry to hear you have troubles with Chrome as well. And since I can confirm we are using that Windows OS build without any troubles, I can only suggest you to double check the permissions level of the account you log in with - the permissions, which can be applied for a user, may vary and I believe it will be useful to discuss the case also internally.  Did you have the chance so far to discuss the matter with the IT department of the organisation you are working for? 

You mentioned you managed to set the UAC to 'Never Notify' - as this is a setting which requires restart to take effect, did you verify if this is still set to "Never Notify" after the reboot? Sometimes, again depending on the user permissions granted, the setting is set back to the default value after the restart. 

Can you, please, let me know if it is possible to run Test Studio with full admin rights and verify if the same misbehavior will persist.

Then, trying to run tests without antivirus system, is our next option to find out if this is what prevents Test Studio. 

I am not sure if you had the chance until now to upgrade to the latest Test Studio version - 2019 R1 (v.2019.2.212), but you can give this a try. In addition to that, i am happy to announce that in the upcoming days we will publish a Service Pack, which supports the latest Visual Studio 2019. So if you decide you can wait for this official version. 

Please, let me know any additional information, you manage to collect on your end, on the topic with user permissions - this will be helpful for us as well to possibly identify what the issue could be caused by. 

Thank you in advance for your cooperation in this discussion. 

Regards,
Elena Tsvetkova
Progress Telerik