2

I have developed some Selenium tests for an AngularJS website. These tests work fine using Chrome Driver and Firefox Driver. I am in the process of also adding the option to run these tests in Internet Explorer Driver. Most of the time the tests work in Internet Explorer too, but I have experienced the following exception over five times:

OpenQA.Selenium.WebDriverException: 'A exception with a null response was thrown sending an HTTP request to the remote WebDriver server for URL http://localhost:53472/session/4a73e505-772d-4ef0-beeb-cc15e8b1e647/elements. The status of the exception was KeepAliveFailure, and the message was: The underlying connection was closed: A connection that was expected to be kept alive was closed by the server.'

Inner Exception

WebException: The underlying connection was closed: A connection that was expected to be kept alive was closed by the server.

The first time this exception ocurred, the tests had been ongoing for several minutes; the second time, the tests had been running for over 3 hours and were near completion.

Possibly relevant information:

  • IE Version: 11.778.18362.0

  • Selenium Version: 3.141.0

  • Selenium IE Driver (32-bit) Version: 3.150.1

  • OS Build 18363.778

The IEDriver is initialised as follows:

            InternetExplorerOptions options = new InternetExplorerOptions
            {
                EnsureCleanSession = true,
                EnableNativeEvents = true
            };
            InternetExplorerDriverService driverService = InternetExplorerDriverService.CreateDefaultService();
            driverService.HideCommandPromptWindow = true;
            IWebDriver webDriver = new InternetExplorerDriver(driverService, options);

The line of my code that usually causes the exception is:

ICollection<IWebElement> webElementsIncludingDisabled = searchContext
                     .FindElements(pageElement.By);

where searchContext is the driver and the selector is a simple CssSelector.

The relevant part of the stacktrace is:

OpenQA.Selenium.WebDriverException
  HResult=0x80131500
  Message=A exception with a null response was thrown sending an HTTP request to the remote WebDriver server for URL http://localhost:53472/session/4a73e505-772d-4ef0-beeb-cc15e8b1e647/elements. The status of the exception was KeepAliveFailure, and the message was: The underlying connection was closed: A connection that was expected to be kept alive was closed by the server.
  Source=WebDriver
  StackTrace:
   at OpenQA.Selenium.Remote.HttpCommandExecutor.MakeHttpRequest(HttpRequestInfo requestInfo)
   at OpenQA.Selenium.Remote.HttpCommandExecutor.Execute(Command commandToExecute)
   at OpenQA.Selenium.Remote.DriverServiceCommandExecutor.Execute(Command commandToExecute)
   at OpenQA.Selenium.Remote.RemoteWebDriver.Execute(String driverCommandToExecute, Dictionary`2 parameters)
   at OpenQA.Selenium.Remote.RemoteWebDriver.FindElements(String mechanism, String value)

One one occasion, a similar exception is instead caused by the line in my code:

webElement.SendKeys(toSend);

The relevant part of the stacktrace is then:

OpenQA.Selenium.WebDriverException
  HResult=0x80131500
  Message=A exception with a null response was thrown sending an HTTP request to the remote WebDriver server for URL http://localhost:50818/session/72b73c2e-d7b2-4e2d-be83-54c343db4109/element/aef8dad2-4c50-41a1-aa36-34957765812a/value. The status of the exception was KeepAliveFailure, and the message was: The underlying connection was closed: A connection that was expected to be kept alive was closed by the server.
  Source=WebDriver
  StackTrace:
   at OpenQA.Selenium.Remote.HttpCommandExecutor.MakeHttpRequest(HttpRequestInfo requestInfo)
   at OpenQA.Selenium.Remote.HttpCommandExecutor.Execute(Command commandToExecute)
   at OpenQA.Selenium.Remote.DriverServiceCommandExecutor.Execute(Command commandToExecute)
   at OpenQA.Selenium.Remote.RemoteWebDriver.Execute(String driverCommandToExecute, Dictionary`2 parameters)
   at OpenQA.Selenium.Remote.RemoteWebElement.Execute(String commandToExecute, Dictionary`2 parameters)
...
  This exception was originally thrown at this call stack:
    System.Net.Sockets.NetworkStream.Read(byte[], int, int)

Inner Exception 1:
WebException: The underlying connection was closed: A connection that was expected to be kept alive was closed by the server.

Inner Exception 2:
IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.

Inner Exception 3:
SocketException: An existing connection was forcibly closed by the remote host

What could be causing this issue?

Is there a way I can affect the Keep Alive timeout that the WebDriver server uses?

Is this related to the webDriver.Manage().Timeouts().PageLoad timeout (currently at its default)?


If I instead try to use the 64-bit version of IEDriver (version 3.141.59), I experience a different issue: selenium always does not appear to communicate with the browser after the initial page load. The line that actually throws the exception in my code is

 WebDriver.Url = expectedURL;

though, through observation, two attempts to SendKeys and a Click have already been unsuccessful by this point.

The relevant part of the stacktrace is:

OpenQA.Selenium.WebDriverException   
HResult=0x80131500   
Message=The HTTP request to the remote WebDriver server for URL http://localhost:55918/session/988d31c6-feb8-4cf0-8335-7c9eaecef6d1/url timed out after 60 seconds.
Source=WebDriver
StackTrace:
at OpenQA.Selenium.Remote.HttpCommandExecutor.MakeHttpRequest(HttpRequestInfo requestInfo)    
at OpenQA.Selenium.Remote.HttpCommandExecutor.Execute(Command commandToExecute)
at OpenQA.Selenium.Remote.DriverServiceCommandExecutor.Execute(Command commandToExecute)
at OpenQA.Selenium.Remote.RemoteWebDriver.Execute(String driverCommandToExecute, Dictionary`2 parameters) ...

This exception was originally thrown at this call stack:
System.Net.HttpWebRequest.GetResponse() 
OpenQA.Selenium.Remote.HttpCommandExecutor.MakeHttpRequest(OpenQA.Selenium.Remote.HttpCommandExecutor.HttpRequestInfo)

Inner Exception 1: WebException: The request was aborted: The operation has timed out.

I believe this 64 bit version problem is the same issue as Selenium IE driver hangs after navigating to URL

Sepia
  • 447
  • 6
  • 21

1 Answers1

0

In one old thread, I found that if you try to reduce the polling interval then issue can be fixed.

Example:

WebDriverWait myWait = new WebDriverWait(driver, TimeSpan.FromMinutes(5));
myWait.PollingInterval = TimeSpan.FromMilliseconds(500); //I reduced this from checking every 5 second to checking every half second and it started working.
bool waitOnUser = myWait.Until(t =>
            { ...});

Reference:

Selenium - Exception - Connection getting closed

Another thing you can try is to reduce the timeout value to see whether it helps to fix this issue.

You can have a test on your side and let us know about your test results.

Deepak-MSFT
  • 10,379
  • 1
  • 12
  • 19
  • Thanks for the suggestion. I had read the thread you link before asking my question. I am not using Selenium's Explicit Waits, but the polling interval of the method in question is 100ms, I don't think lowering it any further is likely to help. From testing with Firefox and Chrome, I have already carefully chosen the timeouts to be as low as they safely can be without causing errors. – Sepia May 01 '20 at 08:33
  • Are you trying to use sleep in your code? If yes, please let us know about it. It can be a possible cause of this issue. – Deepak-MSFT May 01 '20 at 09:48
  • Yes, the code does make extensive use of Thread.Sleep() through a helper function. If this is likely to be the cause I can look through alternatives again. – Sepia May 01 '20 at 11:00
  • I have switched over to using Task.Delay(toSleep).Wait(); instead of Thread.Sleep(toSleep) as suggested at the end of the following answer: https://stackoverflow.com/a/6024667. I will set up a large number of tests to run over the weekend and see if this resolves the issue. – Sepia May 01 '20 at 11:13
  • The same failure still occurrs when the test does not use Thread.Sleep() anywhere. – Sepia May 01 '20 at 17:17
  • I want to confirm with you does error occurs on the same line every time? Did you test the issue on any other machine? Does another machine also generate the same error? – Deepak-MSFT May 04 '20 at 12:52
  • The great majority of the occasions that line is reached, the exception does not occur. I have updated the question to add a related exception and stacktrace that has occurred once. I do not have another machine to test this on and, because it can take hours for it to appear, I can't easily ask a coworker to check it for me. If the problem is likely to be related to my machine, I could set up a VM to run the tests on. – Sepia May 04 '20 at 13:28
  • If possible then you should try to test the code on your VM. It can help us to know whether the issue is machine-specific or it can be produced on any machine. It may help to narrow down this issue. – Deepak-MSFT May 04 '20 at 13:38
  • I ran the tests on a VM for around five hours without the exception occurring once. This is significantly longer than it has ever taken for the exception to appear on my machine, suggesting that I will not be able to reproduce the issue on the VM. It is also possible the same exception could later occur on the VM, just with much less frequency. The version of the code and IE Driver is identical on both, but the IE version on the VM is IE 11.535.18362.0 . As I undersand it, the IE version is tied to the version of Windows used and I cannot easily change the version of Windows the VM is using. – Sepia May 05 '20 at 08:33
  • As per your test result, it can be possible that the issue can be produced using the specific version of the IE browser or it can be some configuration related issue on your machine. I suggest you if possible then try to install the latest updates for your Windows OS to check whether it fix this issue on your machine. Other than that I did not get any alternative solution for this issue. – Deepak-MSFT May 05 '20 at 09:26
  • Thanks for the suggestions. I am currently on the latest version of Windows, with no updates available on my own machine. – Sepia May 05 '20 at 09:44
  • Can you please inform us about the OS build you are using? If you are using a 64 bit OS then just for testing purposes, can you please also try to install the Selenium web driver 64 bit and check whether it makes any changes in the results? If you make any test then please let us know about your test results. – Deepak-MSFT May 07 '20 at 07:56
  • My OS build is 18363.778 and it is 64-bit. I have edited the question to include the problem when attempting to use the 64-Bit Internet Explorer Driver. – Sepia May 07 '20 at 09:18
  • I found in one documentation that antivirus software can also cause this issue. I am not sure whether this is the case with your code but you can try to disable it for testing purposes and see whether it works or not. Other than that I did not get any other suggestions for this issue. – Deepak-MSFT May 07 '20 at 10:03
  • Thank you for your help. The 64-bit driver still does not work at all with antivirus disabled. I will set up a long run of the tests later to see if I am able to reproduce the issue using the 32-bit driver with antivirus disabled. – Sepia May 07 '20 at 10:54
  • Did you test the issue with the 32-bit driver? If you had tested it then did it work? – Deepak-MSFT May 11 '20 at 08:42
  • I ran the tests with antivirus disabled, native events disabled and an eager page load strategy. With this combination, the tests completed running once. I will run tests later to try seeing if this is consistently a solution and, if so, which of these changes is the cause of the success. – Sepia May 11 '20 at 09:39
  • Thanks for updating us about the test results. With further tests, if you think that it can help to solve the issue then please do share your solution here. – Deepak-MSFT May 11 '20 at 10:25
  • I have now tested further with the same combination. It appears that none of disabling antivirus, using an eager page load strategy, and disabling native events is sufficient to prevent the exception from occurring. The test run that completed with IE was just a lucky one - which makes sense as the exception occurs intermittently and infrequently. – Sepia May 13 '20 at 08:18
  • 1
    I will do further research and if I get anything useful then I will try to provide you that information. Thanks for your understanding. – Deepak-MSFT May 13 '20 at 10:49