Steps to reproduce
I have a Windows 10 VM (Version 1607 (OS Build 14393.321)). I am using WebDriver 3.14393. This is a virtual machine so I have many test to run on it, but to do that I have to remote into that machine and kick-off the test bucket. The issue that I see is, when I leave the remote session on, the tests run fine. However, once I close the remote session -normal thing to do- and then connect to it again after a while, I find that all of the tests have failed. I get the following stacktrace
org.openqa.selenium.WebDriverException: Unknown error Command duration or timeout: 562 milliseconds Build info: version: '2.53.0', revision: '35ae25b', time: '2016-03-15 16:57:40' System info: os.name: 'Windows 10', os.arch: 'amd64', os.version: '10.0', java.version: '1.8.0' Driver info: org.openqa.selenium.edge.EdgeDriver at sun.reflect.GeneratedConstructorAccessor64.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:57) at java.lang.reflect.Constructor.newInstance(Constructor.java:437) at org.openqa.selenium.remote.ErrorHandler.createThrowable(ErrorHandler.java:206) at org.openqa.selenium.remote.ErrorHandler.throwIfResponseFailed(ErrorHandler.java:158) at org.openqa.selenium.remote.RemoteWebDriver.execute(RemoteWebDriver.java:678) at org.openqa.selenium.remote.RemoteWebDriver.startSession(RemoteWebDriver.java:249) at org.openqa.selenium.remote.RemoteWebDriver.<init>(RemoteWebDriver.java:131) at org.openqa.selenium.remote.RemoteWebDriver.<init>(RemoteWebDriver.java:144) at org.openqa.selenium.edge.EdgeDriver.<init>(EdgeDriver.java:152)
The code that I use to kick off the browser is the following -this the part that fails in my test suite-
DesiredCapabilities capabilities = DesiredCapabilities.edge(); EdgeDriverService service = new EdgeDriverService.Builder().usingDriverExecutable(edgeDriverPath) .usingAnyFreePort().build(); WebDriver result = new EdgeDriver(service, capabilities); result.navigate().refresh();
I tried a different build of Windows 10 on a different VM and I used WebDriver 2.10586. and the issue is not present in that one. I tried using the Insiders build of the driver (3.14959) and still, the same issue is present in that one too.
I hope that you guys can reproduce this issue as it causing a lot of unwarranted stress.
Comments and activity
Forgot to mention that when I connect back into the VM, the Edge WebDriver has not quit. It just sits there in the task manager list. Sometimes there are more than instance. I believe that that the problem is not with the my test bucket, because the test bucket gets ran against other browsers with no issues.
- Microsoft Edge Team
Changed Assigned To to “Ibrahim O.”
Thank you for your feedback. I am having trouble reproducing this issue which Webdriver successfully keep running on the remote machine despite ending RD session, terminating the connection, login off etc. Could you please provide us a runnable sample or reduced repro sample code? This will help us investigate the issue. Could you please also let us know if you experience this issue only with VM or actual remote machine as well?
All the best,
The MS Edge Team
I have commented some other details in https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/10319887/
-After reboot the machine that hosts the remote web driver, the first time I run the tests, there is no problem, all my tests pass.
-But if I run the tests again, all my tests fail with the message “A window size operation failed because the window is not currently available”
Maybe you could reproduce by running the tests several times?
- Microsoft Edge Team
Changed Assigned To from “Ibrahim O.” to “Steven K.”
Just to confirm that I also have the same issue.
The easiest way to reproduce is to have a set of several tests, start them (e.g. C# Selenium tests with SpecFlow & nunit3) from nunit3-console, they will start running normal, then close the Remote Desktop Connection - and they instantly start to fail with above message.
I saw you assigned that recently, should we expect fix soon? If not is there any workaround? I think there are programs which keeps the RDP session alive - that might do it temporary - also FYI the same scenario works for IE, Chrome & Firefox.
Looks like indeed the RDP disconnect is the problem since this solution solve the issue:
Create a batch file with this code: for /f "skip=1 tokens=3" %%s in ('query user %USERNAME%') do ( %windir%\System32\tscon.exe %%s /dest:console ) Create a desktop shortcut to this file. To do this, right-click the batch file and select Send to | Desktop (create shortcut). In the shortcut properties, click Advanced and select Run as administrator.
Now, when you need to disconnect from Remote Desktop, double-click this shortcut on the remote computer (in the Remote Desktop window).
Thanks to https://support.smartbear.com/testcomplete/docs/testing-with/running/via-rdp/keeping-computer-unlocked.html for the script :)
- Microsoft Edge Team
Changed Assigned To to “Mara P.”
Changed Assigned To from “Mara P.” to “Mike J.”
Changed Assigned To from “Mike J.” to “John J.”
Changed Title from “Edge WebDriver throws Unknown error exception after closing RDC session” to “Edge WebDriver throws Unknown error exception after closing RDC session”
Still getting the issue on 1703.15063. However, the problem does not occur on 1703.15063 nor 1511.10586.
Is there any update with this issue ? Here are repro samples: github repo
Hoping this will help
Any recent updates on that issue? It’s really annoying to use the above workaround every time I RDP the machine.
Issue is still there on:
Windows 10 Pro
OS Build 16299.192
Edge driver Release 16299
- Microsoft Edge Team
Changed Assigned To from “John J.” to “Clay M.”
Changed Status to “Confirmed”
Changed Status from “Confirmed” to “Duplicate”
This is a dupe. The issue is that when the machine get’s locked (by closing the RDP session) the app model disconnects the core window of Edge, causing commands that go to it to fail. It’s similar to when Edge is minimized, some commands will run but most will fail in this state. The best way to avoid this is to ensure the VM doesn’t lock after you close the RDP session. We’re looking at fixes for the bug this is a dupe of but it will likely require some feature work.
This bug has marked as duplicate. Please follow the parent issue to get new updates.