New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 196 users

Issue metadata

Status: Fixed
Owner:
Closed: Nov 2014
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug-Regression

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment
link

Issue 422218: Chrome 38 doesn't work anymore with Karma test runner for Javascript from a UI-less service

Reported by renaissa...@gmail.com, Oct 10 2014

Issue description

Chrome Version       : 38.0.2125.101 m
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 6:
Firefox 20:
IE 8/9/10:

The problem appears when running the Karma webserver for automated JS unit testing together with Chrome, ONLY from a UI-less build agent. E.g. Bamboo or TeamCity agent. These agents launch Karma which then in turn launches Chrome and communicates with it through some configurable mechanism (in my case websockets). The Bamboo agent is a Windows Service.

When running Karma as a normal user, with a UI, the connection between Karma and Chrome is successful. When running it from an agent (which is normally a windows service) the connection cannot be established. The agent runs under the same account as the user, so I guess it's not a permissions issue.

What steps will reproduce the problem?
1. Install Karma 0.12.24 (npm install karma)
2. Configure it to run using Chrome
3. Run it from a UI-less service


What is the expected result?
Karma runs and successfully connects to the opened Chrome instance.


What happens instead?
Karma cannot connect to the opened Chrome instance and times out.

Please provide any additional information below. Attach a screenshot if
possible.
The problem DOES NOT reproduce with Chrome 37, only Chrome 38. I also tried the latest beta (40) and the problem still reproduces there as well.
 

Comment 1 by theodor...@gmail.com, Oct 15 2014

For me the problem isn't isolated to Karma. It occurs when I launch the chrome executable from a service account. Chrome opens, but hangs when trying to load any page (even the new tab page!). It eventually shows a popup saying "The following page(s) have become unresponsive."

Comment 2 by p...@philipwigg.co.uk, Oct 15 2014

We have the same issue running Selenium tests, using Chromedriver, via a TeamCity build agent.

We receive 'UnknownError: unknown error: cannot get automation extension'

Comment 3 by p...@philipwigg.co.uk, Oct 15 2014

I should add, the problem resolved as soon as we rolled back to an earlier version of Chrome.

It took ages to find a link to download an old version of Chrome though. Why Google doesn't provide an easy way to do this is beyond me.

Comment 4 by ate...@gmail.com, Oct 15 2014

Ditto with TeamCity, Selenium and SpecFlow. Different error (connection error when getting a cookie) but every test fails.

Comment 5 by Deleted ...@, Oct 15 2014

For team city you can workaround the problem by running the team city agent from the command line instead of running it as a service.

Comment 6 by timschle...@gmail.com, Oct 17 2014

I'm having the same problem using Chrome 38.0.2125.104m on Windows Server 2008 R2 sp1

Comment 7 by thib...@gmail.com, Oct 17 2014

Also having same problem here with Team City, Chrome and Karma/Protractor

As mentioned above, starting agent from command line works, but the agent must be left logged in which is a security issue as described here: https://confluence.jetbrains.com/display/TCD8/Known+Issues under "Issues with automated GUI and browser testing"

Comment 8 by arsuc...@gmail.com, Oct 20 2014

Same problem here with Windows 2008 R2, CCNet/Karma running as service and Chrome 38.0.2125.104. It was working until Chrome Update 38.0.2125.101 (2014/08/10) and running CCNet from commmand line works ok.

Comment 9 by Deleted ...@, Oct 21 2014

Same issue here, I hope they fix this soon.

Comment 10 by jorandir...@gmail.com, Oct 22 2014

We are also having problems with websockets in Chrome 38.0.2125.104m.

Comment 11 by phistuck@chromium.org, Oct 22 2014

Cc: ricea@google.com
Labels: Needs-Feedback
This sounds like the new fragmented message feature.
See https://groups.google.com/a/chromium.org/forum/?utm_medium=email&utm_source=footer#!msg/net-dev/QuiTHBbMM6M/ddD4De7TXAkJ for details and context.

You might need to update your WebSocket implementation to one that supports receiving fragmented messages and see if it fixes the issue.

Comment 12 by pric...@gmail.com, Oct 22 2014

That explanation seems unlikely. It doesn't explain the situation in #1 (hangs loading the new tab page) or #7 (works when run from the command line).

Comment 13 by phistuck@gmail.com, Oct 22 2014

They might simply not be the same issue.
The reporter mentions WebSockets as the configured communication, which is why I am suspecting this feature.

Comment 14 by pric...@gmail.com, Oct 22 2014

Fair point. I should have said #7 repeats the problems described by the reporter (in the second paragraph) which I don't believe is covered by the explanation.

Comment 15 by renaissa...@gmail.com, Oct 22 2014

The issue reproduces also with other transports such as xhr-polling.

Comment 16 by phistuck@gmail.com, Oct 22 2014

You can try and enable logging -
http://www.chromium.org/for-testers/enable-logging

And see if there is anything different in the log when running as a service versus running as a normal application. That might get the team a lead to the issue.

Comment 17 by ricea@chromium.org, Oct 23 2014

Labels: Cr-Internals-Network
It sounds like 38.0.2125.104 can no longer initialise the network stack when run from a Windows service, and this is a recent change. I'm tentatively adding a network label.

In addition to getting log output as phistuck suggested, please also try to reproduce this on a Canary build.

Comment 18 by mmenke@chromium.org, Oct 23 2014

I think hanging when loading the NTP makes it unlikely this is a network stack issue.

Comment 19 by simonlam...@vinsight.net, Oct 23 2014

Reproducible with CruiseControl.net running as a service using ChromeDriver through selenium. Our continuous integration is not that continuous at the moment :)

Comment 20 by thomas.h...@gmail.com, Oct 27 2014

Also affected by this. Was starting chrome-driver with selenium node with nssm. Now starting chrome node manually after each reboot... Failed to locate older version of chrome :(

Comment 21 by faisal.h...@gmail.com, Oct 27 2014

Hi,

Fixed this on Teamcity Agents by:

1.Disabling Chrome updates.
2. Installing chrome's older version from this link :
http://www.neowin.net/news/google-chrome-3702062124. (Download offline
installer). Then you will need to use junction to sort out default location
of chrome because offline installer installs chrome on different location
e.g. c:\users\..... But Junction will sort this out by creating symbolic
links in usual chrome directory  "C:\Program Files (x86)\Google\Chrome"

After performing above steps. Teamcity builds started running Selenium
automated scripts like it used to do in Service Mode.

Hopefully it will help other's facing similar issue.

Comment 22 by pziemin...@gmail.com, Oct 27 2014

Thanks for the offline installer link. How do you disable chrome updates? I googled and only found directions on adding some registry entries, that didn't seem to work.

Comment 23 by ate...@gmail.com, Oct 27 2014

I stopped it updating by following *both* solutions @ http://blog.doofix.com/how-to-stop-google-chrome-from-automatic-update/

Comment 24 by renaissa...@gmail.com, Oct 28 2014

Upon updating to the latest version 38.0.2125.111 m I now have the problem that karma disconnects after about 2500 tests even when run normally, by a human, with UI and everything. Around 2000 tests the communication between karma and chrome starts to lag, noticeable in the speed of execution of the tests, then stops altogether and karma reports disconnection.

The problem doesn't reproduce in Firefox or IE, they run the full test suite successfully.

Any ideas?

Comment 25 by cbentzel@chromium.org, Oct 28 2014

Cc: -ricea@google.com tyoshino@chromium.org
Labels: -Type-Bug Type-Bug-Regression M-38
Owner: ricea@chromium.org
Status: Assigned
ricea: Temporarily assigning.

Reporters: Do you know if your setup uses a statically configured HTTP proxy at all?

Comment 26 by ate...@gmail.com, Oct 28 2014

As far as I am aware, no we don't have a proxy configured. Although it's possible that our IS guys have configured a proxy via group policy/whatever. if so, I'm not aware of it.

Comment 27 by renaissa...@gmail.com, Oct 28 2014

I have no proxies configured and stuff runs on the same machine. Same for latest problem, comment #24 above, no proxy and I run everything on my local machine.

Comment 28 by augustyn...@gmail.com, Oct 28 2014

We also have no proxy and the SUT runs on the same machine as the ChromeDriver (we are connecting to localhost).

Comment 29 by cbentzel@chromium.org, Oct 28 2014

thanks for the confirmations

Comment 30 by james.mk...@gmail.com, Oct 30 2014

Comment 31 by simonlam...@vinsight.net, Oct 30 2014

Hi James,
I think this is a symptom of the problem, not the cause as you notice the ChromeDriver works with Chrome 37 and this is the behaviour we have seen.

Comment 32 by pmilli...@gmail.com, Oct 31 2014

I've started seeing this on our Jenkins instance running as a windows service. When I monitor the processes, it looks like the child renderer process starts briefly, and then dies, leaving the browser unable to do anything.

Chrome is being launched with logging turned on. I found the following messages in the chrome_debug log:

[5972:5968:1031/152518:ERROR:gpu_process_transport_factory.cc(418)] Failed to establish GPU channel.
[5972:5968:1031/152518:ERROR:child_process_launcher.cc(344)] Failed to launch child process
[5972:5968:1031/152518:ERROR:child_process_launcher.cc(344)] Failed to launch child process

Comment 33 by Deleted ...@, Nov 4 2014

Same issue running Jenkins as a windows service here too.

Windows Server 2008
Jenkins 1.570
ChromeDriver 2.12
Chrome v38.0.2125.111
Running UI tests via Selenium/WebDriver

A little while ago the builds just started hanging as chrome wouldn't start up and we started getting these in the chrome_debug.log files...

[4112:2544:1027/145423:ERROR:gpu_process_transport_factory.cc(418)] Failed to establish GPU channel.
[4112:2544:1027/145423:ERROR:child_process_launcher.cc(344)] Failed to launch child process
[4112:2544:1027/145423:ERROR:child_process_launcher.cc(344)] Failed to launch child process

Tried running the Jenkins service under a dedicated user account as well, same error. I have not tried rolling Chrome back to v37 yet (that's next).

Comment 34 by rock.ban...@gmail.com, Nov 5 2014

I have tried rolling back to older version of chrome driver, but no luck, as the chrome driver is always keeps update to the latest version. 

Any other solution is welcome....

Comment 35 by ate...@gmail.com, Nov 5 2014

You need to switch off the Chrome auto updates.  See the link in the message trail above.

Comment 36 by ricea@chromium.org, Nov 5 2014

Labels: -Needs-Feedback Needs-Bisect

Comment 37 by anan...@chromium.org, Nov 5 2014

Cc: vkomonduri@chromium.org
Ravi, Please work on providing bisect ASAP. This bug is not allowing the users to run Chromedriver.

Comment 38 by samu...@chromium.org, Nov 5 2014

 Issue chromedriver:928  has been merged into this issue.

Comment 39 by samu...@chromium.org, Nov 5 2014

Cc: samu...@chromium.org
I'm able to reproduce this issue in M38, and I've also confirmed that M37 is not affected by this. The issue only comes up when launching Chrome from a scheduled task in Windows, and the task must be running as SYSTEM.

OS: Windows 7 Enterprise Service Pack 1
Last Known Good Chrome Version: 37.0.2062.124
First Known Bad Chrome Version: 38.0.2125.111 (current stable channel)

The steps to reproduce are below. This should be enough to bisect on.

1. Start "Task Scheduler" and click "Create Task..."
2. Give it a name, and set the user account to SYSTEM
3. Click the Actions tab, click "New..."
4. For Program/script, give it the path to chrome.exe
5. For "Add arguments" type "--enable-logging --log-level=0 --user-data-dir=c:\sams_user_data_dir"
6. Click the Triggers tab, click "New..." and set the time to something soon
7. Click OK and OK, and wait for the task to run
8. Open up c:\sams_user_data_dir\chrome_debug.log

In M38, but not in M37, the debug log contains the error message below. Full logs from my system for M37 and M38 are attached.

[4620:5648:1105/142727:ERROR:child_process_launcher.cc(344)] Failed to launch child process
m37_chrome_debug.log
2.7 KB View Download
m38_chrome_debug.log
2.8 KB View Download

Comment 40 by cbentzel@chromium.org, Nov 6 2014

#39 thanks for repro steps

Comment 41 by ranjitkan@chromium.org, Nov 6 2014

Cc: ricea@chromium.org ranjitkan@chromium.org
Labels: -Needs-Bisect
Owner: tim@chromium.org
Able to reproduce the issue on windows 7 and Windows 8 as described in comment#39. Issue is broken in M38. Please find the bisect details below:

Good build: 38.0.2067.2 (Official Build 279432)
Bad build: 38.0.2068.0 (Official Build 279517)

CL: http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog.html?url=%2Ftrunk%2Fsrc&range=279432%3A279517&mode=html

Suspecting r279503, @tim: Could you please take a look if this is caused with respect to your change. If not could you please help in reassigning it to the right owner.

Removing Needs-bisect label.

Comment 42 by ranjitkan@chromium.org, Nov 6 2014

Cc: pbomm...@chromium.org

Comment 43 by ricea@chromium.org, Nov 6 2014

Cc: jsc...@chromium.org
+jschuh, could https://chromium.googlesource.com/chromium/src/+/df1fdb6ebc126fefb9052cfbc23f4bb3a453a297 
("Add UIPI support for sandbox alternate desktop") be related?

Comment 44 by jsc...@chromium.org, Nov 6 2014

ricea@ - The UIPI change was in the last working revision from comment #41. Is that regression range wrong?

Comment 45 by anan...@chromium.org, Nov 6 2014

Labels: -Pri-2 Pri-1
Thanks Sam and Ranjith for narrowing down the testcase and providing bisect. I am following up with Tim to get the fix in.

Comment 46 by mmenke@chromium.org, Nov 6 2014

Labels: -Cr-Internals-Network
Removing network label, to reduce spam.

Comment 47 by cbentzel@google.com, Nov 6 2014

I think it's extremely unlikely that tim@'s r279503 change caused this as that was impacting mojo test shell only and should not have changed Chrome.

Thanks for the bisect though.

Comment 48 by samu...@chromium.org, Nov 6 2014

I agree it's unlikely that tim@'s change caused this. The regression range contains a blink roll, so maybe it's worth bisecting over blink builds?

Comment 49 by anan...@chromium.org, Nov 6 2014

agreed, mojo test shell changes should not have caused this. Prudhvi is doing another round of bisect to double check the regression range.

Comment 50 by wfh@chromium.org, Nov 6 2014

This is related to running as SYSTEM having no desktop, so I couldn't just bisect from an interactive SYSTEM prompt. I'll add some debugging code in ToT and find where the sandbox startup is failing.

Comment 51 by simonlam...@vinsight.net, Nov 6 2014

Hi Chromium team,
Just to clarify, this bug manifests with any user that is not logged in interactively, not just SYSTEM. So our build process is running as a service as a user with log on as service rights and we see this error.
Hope that helps. Cheers Simon

Comment 52 by cfro...@gmail.com, Nov 6 2014

#51 I can confirm that. I'm also seeing this bug with a service that is associated with a user account and not the SYSTEM account.

Comment 53 by wfh@chromium.org, Nov 6 2014

Labels: Cr-Internals-Sandbox
Owner: jsc...@chromium.org
This is happening when setting integrity level of the alternate desktop on this line:

https://code.google.com/p/chromium/codesearch#chromium/src/sandbox/win/src/sandbox_policy_base.cc&sq=package:chromium&type=cs&l=469

This code was added in df1fdb6ebc126fefb9052cfbc23f4bb3a453a297 -> jschuh

Comment 54 by bugdroid1@chromium.org, Nov 7 2014

Project Member
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2f5fb91566b8d2d9861c4b0437bcfb20cba3f1d9

commit 2f5fb91566b8d2d9861c4b0437bcfb20cba3f1d9
Author: jschuh <jschuh@chromium.org>
Date: Fri Nov 07 01:26:07 2014

Check alternate desktop before applying integrity label

No alternate desktop means there's nothing to label

BUG= 422218 
R=wfh@chromium.org

Review URL: https://codereview.chromium.org/686083007

Cr-Commit-Position: refs/heads/master@{#303151}

[modify] https://chromium.googlesource.com/chromium/src.git/+/2f5fb91566b8d2d9861c4b0437bcfb20cba3f1d9/sandbox/win/src/sandbox_policy_base.cc

Comment 55 by jsc...@chromium.org, Nov 7 2014

Should be fixed if it's what I think it was. Give today's canary a try, and if it works I'll merge the fix to m39.

Comment 56 by vkomonduri@chromium.org, Nov 7 2014

 Issue 426858  has been merged into this issue.

Comment 57 by mingz...@gmail.com, Nov 10 2014

Would love to see fix for this issue.

Comment 58 by jsc...@chromium.org, Nov 10 2014

Labels: -M-38 M-39 Merge-Requested
Status: Fixed
I haven't gotten any feedback, but canary works in my testing so I'm marking fixed and requesting to merge.

Comment 59 by amin...@google.com, Nov 10 2014

Labels: merge-questions-applied
Please note that all merge requests must have been on or rolled into trunk
for at least 24 hours to be considered for merging (to ensure full bot
coverage and give an opportunity for any necessary reverts to occur).

To help facilitate this request, if you could please answer the following:
--------------------------------------------------------------------------
1) Has this change been on trunk for at least 24 hours?

2) Has this change shipped to at least one canary release (where applicable)?

3) Has anyone verified that these changes resolve the issue and cause no new
   crashes (via chromecrash/) or regressions?

4) Why is this necessary for this milestone?

Thanks!

(this message is auto-generated each time the merge-request label is
applied; if you have previously answered these questions kindly disregard)

Comment 60 by jsc...@chromium.org, Nov 10 2014

1) Yes
2) Yes
3) Yes, via local testing
4) Chrome doesn't work via automated tasks on Windows without this change

Comment 61 by amineer@chromium.org, Nov 10 2014

Labels: -Merge-Requested Merge-Approved
merge approved for m39 branch 2171

Comment 62 by anan...@chromium.org, Nov 10 2014

Thanks to everybody involved in getting this bug fixed.

Comment 63 by simonlam...@vinsight.net, Nov 10 2014

Just to confirm, I have run our CI build using Canary 41.0.2216.0 in a non UI session and the issue appears to be fixed.
Thanks for your speed work!

Comment 64 by stephenw...@gmail.com, Nov 11 2014

please release the new version.thanks !

Comment 65 by rock.ban...@gmail.com, Nov 11 2014

Eagerly waiting for the chrome update! BIG! Thanks to chromium team.

Comment 66 by victor.p...@datahug.com, Nov 11 2014

Can't wait to re-enable all our tests in Chrome! Great work to the Chromium team!

Comment 67 by jamnagar...@gmail.com, Nov 11 2014

Thank you so much chromium team for fixing the issue :). Eagerly waiting for the release.

Comment 68 by davecb1...@gmail.com, Nov 11 2014

Ditto on the thanks to the Chromium team!

Speaking of the release, any ETA? Our automation awaits. :)

Comment 69 by matthew....@exony.com, Nov 11 2014

I would expect it to be released around 20 November as that is six weeks after the last release ;). But you can use the beta in the meantime if you want.

Comment 70 by bugdroid1@chromium.org, Nov 11 2014

Project Member
Labels: -Merge-Approved merge-merged-2171
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a1ea10e67aead8d918cc1a8b7e6064f1261f7205

commit a1ea10e67aead8d918cc1a8b7e6064f1261f7205
Author: Justin Schuh <jschuh@chromium.org>
Date: Tue Nov 11 21:31:51 2014

Check alternate desktop before applying integrity label

No alternate desktop means there's nothing to label

BUG= 422218 
R=wfh@chromium.org

Review URL: https://codereview.chromium.org/686083007

Cr-Commit-Position: refs/heads/master@{#303151}
(cherry picked from commit 2f5fb91566b8d2d9861c4b0437bcfb20cba3f1d9)

Review URL: https://codereview.chromium.org/714083004

Cr-Commit-Position: refs/branch-heads/2171@{#410}
Cr-Branched-From: 267aeeb8d85c8503a7fd12bd14654b8ea78d3974-refs/heads/master@{#297060}

[modify] https://chromium.googlesource.com/chromium/src.git/+/a1ea10e67aead8d918cc1a8b7e6064f1261f7205/sandbox/win/src/sandbox_policy_base.cc

Comment 71 by ashej...@chromium.org, Nov 12 2014

Cc: ashej...@gmail.com
Labels: TE-Verified-39.0.2171.62 TE-Verified-M39
Verified the above issue on windows 7 with chrome version "39.0.2171.62," followed the steps mentioned in comment#39 and the debug log doesn't contain below error message.

"[4620:5648:1105/142727:ERROR:child_process_launcher.cc(344)] Failed to launch child process".

Hence marking the same as TE-Verified-39.0.2171.62.

Attach are the logs for the same. 

Thank you
chrome_debug.log
2.6 KB View Download

Comment 72 by rock.ban...@gmail.com, Nov 14 2014

How to disable the auto update on the newer version of chrome browser??
I went to chrome://plugins/ path and checked there is no option to disable it.

Please suggest how to do it? or this option is removed with the newer chrome update???

Comment 73 by puniebal...@gmail.com, Nov 14 2014

Run the attached reg script to disable chrome updates
chrome-no-updates.reg
159 bytes Download

Comment 74 by Deleted ...@, Nov 19 2014

When this fix is expected to be released in stable version (available for automatic update)?

Best Regards
Marek

Comment 75 by phistuck@gmail.com, Nov 19 2014

Chrome 39 was just released, available for automatic updates (so in about two weeks, if you do not force an update by going to chrome://chrome).

Comment 76 by Deleted ...@, Nov 19 2014

Works. Thank you!

Comment 77 by james.mk...@gmail.com, Nov 19 2014

Our jenkins slave just passed with latest release build, thanks to all involved.

Comment 78 by jamnagar...@gmail.com, Nov 19 2014

Able to run tests on windows server 2008 r2WINDOWS Thanks for the fix..

Comment 79 by davecb1...@gmail.com, Nov 19 2014

I installed the update to version 39.x and everything is working again. Splendid!

Thanks again to the Chromium team for their diligence on this.

Comment 80 by alister....@gmail.com, Nov 19 2014

Thanks everyone. Now is a good time to lock down your Chrome version on your CI Machines to ensure Chrome doesn't break your tests again in future releases. See: http://watirmelon.com/2014/11/05/lock-down-your-browser-versions-if-you-run-webdriver-tests/

Alister

Comment 81 by vinay.gu...@gmail.com, Nov 20 2014

Is there anyone else who is still facing same issue even after upgrading to latest chrome?
My settings:
chrome: 37.0.2062.124/103 and 39.0.2171.65 
Driver: 2.9,10,12
Win 7 64bit
Selenium version 2.42
Got this in log:
org.openqa.selenium.WebDriverException: unknown error: cannot determine loading statusfrom timeout: Timed out receiving message from renderer: 600.000 (Session info: chrome=39.0.2171.65) (Driver info: chromedriver=2.12.301325 (962dea43ddd90e7e4224a03fa3c36a421281abb7),platform=Windows NT 6.1 SP1 x86_64) (WARNING: The server did not provide any stacktrace information)Command duration or timeout: 600.05 secondsBuild info: version: '2.42.2', revision: '6a6995d31c7c56c340d6f45a76976d43506cd6cc', time: '2014-06-03 10:52:47'System info: host: 'NCEVC-00252', ip: '10.64.158.246', os.name: 'Windows 7', os.arch: 'x86', os.version: '6.1', java.version: '1.6.0_26'Session ID: 4dfd6d34926aeb9b5218366ab7a12bcdDriver info: org.openqa.selenium.chrome.ChromeDriverCapabilities [{platform=XP, acceptSslCerts=true, javascriptEnabled=true, browserName=chrome, chrome={userDataDir=C:\Users\$NCEOC~1\AppData\Local\Temp\scoped_dir5788_20334}, rotatable=false, locationContextEnabled=true, mobileEmulationEnabled=false, version=39.0.2171.65, takesHeapSnapshot=true, cssSelectorsEnabled=true, databaseEnabled=false, handlesAlerts=true, browserConnectionEnabled=false, nativeEvents=true, webStorageEnabled=true, applicationCacheEnabled=false, takesScreenshot=true}]	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)	at java.lang.reflect.Constructor.newInstance(Constructor.java:513)	at org.openqa.selenium.remote.ErrorHandler.createThrowable(ErrorHandler.java:204)	at org.openqa.selenium.remote.ErrorHandler.throwIfResponseFailed(ErrorHandler.java:156)	at org.openqa.selenium.remote.RemoteWebDriver.execute(RemoteWebDriver.java:599)	at org.openqa.selenium.remote.RemoteWebDriver.get(RemoteWebDriver.java:304)	at org.openqa.selenium.remote.RemoteWebDriver$RemoteNavigation.to(RemoteWebDriver.java:850)

Comment 82 by samu...@chromium.org, Nov 20 2014

vinay.gupta1512, could you please file a separate bug for this at https://code.google.com/p/chromedriver/issues/entry and let us know:

- whether you're seeing this consistently or occasionally
- any special setup you might have (e.g. running as a system task as a non-logged in user)

Comment 83 by mehul.ch...@gmail.com, Feb 9 2015

I still see the same error as https://code.google.com/p/chromedriver/issues/detail?id=928 
Reporting it here since #928 got merged into this bug and got closed

Windows Server 2008 R2
Chrome 40
Webdriver 2.44
ChromDriver 2.14

Exception thrown
org.openqa.selenium.WebDriverException: unknown error: cannot get automation extension
from timeout: Timed out receiving message from renderer: 600.000

Comment 84 by mehul.ch...@gmail.com, Feb 9 2015

Exact Error :

Exception org.openqa.selenium.WebDriverException

Message: unknown error: cannot get automation extension from timeout: Timed out receiving message from renderer: -3.250 (Session info: chrome=40.0.2214.111) (Driver info: chromedriver=2.14.313457 (3d645c400edf2e2c500566c9aa096063e707c9cf),platform=Windows NT 6.1 SP1 x86_64) (WARNING: The server did not provide any stacktrace information) Command duration or timeout: 13.42 seconds Build info: version: '2.44.0', revision: '76d78cf323ce037c5f92db6c1bba601c2ac43ad8', time: '2014-10-23 13:11:40' System info: host: 'SFO0-ENG-001', ip: '192.168.85.73', os.name: 'Windows Server 2008 R2', os.arch: 'amd64', os.version: '6.1', java.version: '1.7.0_60' Session ID: 4917bdd27963ab0491345537f77146c6 Driver info: org.openqa.selenium.chrome.ChromeDriver Capabilities [{platform=XP, acceptSslCerts=true, javascriptEnabled=true, browserName=chrome, chrome={userDataDir=C:\Users\svc-qa\AppData\Local\Temp\scoped_dir2764_17371}, rotatable=false, locationContextEnabled=true, mobileEmulationEnabled=false, version=40.0.2214.111, takesHeapSnapshot=true, cssSelectorsEnabled=true, databaseEnabled=false, handlesAlerts=true, browserConnectionEnabled=false, webStorageEnabled=true, nativeEvents=true, applicationCacheEnabled=false, takesScreenshot=true}]

Comment 85 by beratheb...@gmail.com, Mar 3 2015

I am getting the same error.

Exception Details=OpenQA.Selenium.WebDriverException: The HTTP request to the remote WebDriver server for URL http://localhost:49897/session/3f1d8b75aedcce14db9427f04375548e/execute timed out after 60 seconds. ---> System.Net.WebException: The operation has timed out
at System.Net.HttpWebRequest.GetResponse()
at OpenQA.Selenium.Remote.HttpCommandExecutor.CreateResponse(WebRequest request)
--- End of inner exception stack trace ---
at OpenQA.Selenium.Remote.HttpCommandExecutor.CreateResponse(WebRequest request)
at OpenQA.Selenium.Remote.DriverServiceCommandExecutor.Execute(Command commandToExecute)
at OpenQA.Selenium.Remote.RemoteWebDriver.Execute(String driverCommandToExecute, Dictionary`2 parameters)
at OpenQA.Selenium.Remote.RemoteWebDriver.ExecuteScriptCommand(String script, String commandName, Object[] args)

Windows server 2012 - Azure VM
Chrome 40.0.2214.115
Webdriver 2.44 and 2.45
ChromeDriver 2.14

I had to go back to Chrome v36 and ChromeDriver v2.11 to get things working.

Comment 86 by jsc...@chromium.org, Mar 3 2015

Labels: Restrict-AddIssueComment-EditIssue
This bug was closed several months ago, as the underlying issue was fixed. Whatever issue you're experiencing is unrelated, so you should file a new bug with a clear description of what's going on.

Sign in to add a comment