Thank you for logging this, Paul.  This is COMPLETELY blocking our Bamboo automation and threatening releases.  
-Todd Cantalupo
Director of Engineering

Mano, could you please take a look? 

Thanks.

I am able to reproduce this issue on Win7 64-bit OS and has broken in M51.

51.0.2695.0 - Good
51.0.2699.0 - Bad

Change Log:
===========
https://chromium.googlesource.com/chromium/src/+log/51.0.2695.0..51.0.2699.0?pretty=fuller&n=10000

I am suspecting the below changes might have caused this issue.
https://chromium.googlesource.com/chromium/src/+/c8c6edda3d499f5271bb7857a075fb48d3fdd8dc
https://chromium.googlesource.com/chromium/src/+/ff8289e0123c7829ae54581e96e70bfdfe9882ab

joedow@/pfeldman@, could someone please take a look and see if this is releated?

Thank you!

My change (c8c6edda3d499f5271bb7857a075fb48d3fdd8dc) isn't built into the Chrome binary and as of that CL, only had unit tests executing it.

Where does this stand? 

I performed bisect and found a smaller change log:

https://chromium.googlesource.com/chromium/src/+log/4e4da03f08faa602998125895ac4b884c60be001..7567d28cf42fbb7ffa1e709a7b7f788d15127077

384623 - good
384638 - bad

From the change log (ignoring the tests related CLs), it seems below CLs might have caused this issue :-
https://chromium.googlesource.com/chromium/src/+/69dd6440536e1f81e3475e83897383d3b66a8a3b
https://chromium.googlesource.com/chromium/src/+/329ab2d697eb8b8968a5451728a75a8e1d85532a
https://chromium.googlesource.com/chromium/src/+/13c050628a5c88ffde430f633ff7e2ac37f52175
https://chromium.googlesource.com/chromium/src/+/81e7a09b8d7c05ebce8aedc378099ad67d446866
https://chromium.googlesource.com/chromium/src/+/45e63d4ce6f4eb4c05fa27e1ece44ace00941924
https://chromium.googlesource.com/chromium/src/+/151deeb377f9456660e9ab835d1c7fa46edc7499
https://chromium.googlesource.com/chromium/src/+/32347aea90191f4558531d5dccb05bd9946cddce

CCing the owners of the above CLs. Could you please take a look?

My CL is so trivial that I don't think it's the cause.

forshaw and oshima's CL seems more relevant (by looking at the CL title)...

I don't think this is Pavel or Joe's change, so -pfeldman@ and -joedow@

I am very certain that it is not caused by my change.

Removing me again.

My CL is chromeos only.

My CL only converts assertions from blink's ASSERTS to chromium DCHECKS.

I don't think my CL caused this.

I further bisected and found the culprit CL - https://chromium.googlesource.com/chromium/src/+/329ab2d697eb8b8968a5451728a75a8e1d85532a

+ forshaw@, could you please take a look?

Chrome doesn't support running in session 0. I think this is a WontFix, but I can let forshaw decide.

What do you mean by 'Chrome doesn't support running in session 0'? It used to work till  version 51.

Please re-read the original description.  The steps describe the behavior.  Does that answer your question?

Desktop apps should not be run in Session 0. Since Windows Vista, session 0 has only been for services and user mode drivers [1]. We periodically rework and remove code related to Vista/XP as part of the deprecation, and continue to strengthen the sandbox for later OS.

My understanding is that your testing framework(s) are running as a service in session 0 and spawning Chrome as a child process? You should change this to run in an interactive session using e.g. runas /user: for the Chrome sandbox to function correctly. Perhaps a bug needs to be filed with the testing framework to change this?

[1] - https://blogs.technet.microsoft.com/askperf/2007/04/27/application-compatibility-session-0-isolation/

Our TeamCity chrome webdriver tests broke because of this change as well. Expect Jenkins also broken.
The workaround was to push Chrome tests remote like the rest of the browsers. The performance hit for Chrome from that is substantial (it used to be our early health indicator... not so much anymore).

For #22, why does chrome need to run remotely? Or why isn't it possible to run this in an interactive session on the same host as the chromedriver process?

For us, its regarding the way Bamboo connects to an AWS VM for OnDemand (pw / ips cycle), IMO. I would imagine other CI's which make calls to spin up Remote VMs, etc could experience this as well due to essentially running as a service (session 0) and all sub-processes it calls. Tried running on an interactive session within session 0 using something like NSSM, but issue still persists. This has worked for us for over the past 5 years without issue running chrome and chromedriver in session 0. We have implemented a workaround by rolling back to using chromium over chrome, but I would like to think that there is a use case for running in session 0 on Windows. If you have any suggestions, please let us know, but would be nice to have this fixed or maybe the option via chrome flag to go around this change for chromedriver purposes

TeamCity build agents run as services so that our CI works no matter if someone is logged-in to the system or not (most the time no one is logged-in). This means chrome will be launched in the same session. All other browsers are launched by the TC agents in Sauce Labs VMs. Chrome now joins them.

It is interesting to note that running in session 0 has been blocked before, but the change has been rolled back.

We run our UI tests with Selenium/Chromedriver on Jenkins slaves. These tests are all busted due to this issue.

I am uneasy about giving guarantees of maintaining support for running Chrome sandboxed under Session 0. MS could very well break things in the future and since Vista it's become less and less supported (e.g. on Win8+ you need to do various changes just to see windows on the Session 0 desktop). 

However in this case I've found the cause and it's possible to fix. It's more that you're running Chrome under the local system account than Session 0 itself (it doesn't work running as system on the interactive session either). Of course we probably shouldn't actively support running as a service account either. I'll submit the changes necessary.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6ac615dfd11e86b1ce7766e1de263ce3d2e3b727

commit 6ac615dfd11e86b1ce7766e1de263ce3d2e3b727
Author: forshaw <forshaw@chromium.org>
Date: Mon Jun 13 20:39:13 2016

Fix for running Chrome under a service token.
This patch fixes an issue with the handling of the default DACL when running
Chrome under a service token, such as Local System. These tokens don't always
have an assigned logon session SID, which would cause the DACL lockdown process
to fail.

BUG= 615396 
CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win10_chromium_x64_rel_ng
TEST=1. Download PSTools from https://technet.microsoft.com/en-us/sysinternals/pstools.aspx
2. Run cmd.exe as an administrator
3. Run the command 'psexec -s -i c:\path\to\chrome.exe'
4. Verify that the browser is useable

Review-Url: https://codereview.chromium.org/2061703002
Cr-Commit-Position: refs/heads/master@{#399529}

[modify] https://crrev.com/6ac615dfd11e86b1ce7766e1de263ce3d2e3b727/sandbox/win/src/acl.cc
[modify] https://crrev.com/6ac615dfd11e86b1ce7766e1de263ce3d2e3b727/sandbox/win/src/restricted_token_unittest.cc

Thank you for the fix!

I verified it by executing the below steps on the available revision 399532 that contains the fix:
1. Run cmd.exe as an administrator
2. Run the command 'psexec -s -i c:\path\to\chrome.exe'
3. Verify that browser is launched and can be navigated to valid URL successfully.

If anyone would like to test the build (before it is released in stable version) , you can download it from https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Win/399532/

Many thanks for the fix!

Will try out using the snapshot today. 

Kind-of off topic, but when would the relative change set get copied into the continuous build (https://commondatastorage.googleapis.com/chromium-browser-continuous/index.html?prefix=Win/)?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6ac615dfd11e86b1ce7766e1de263ce3d2e3b727

commit 6ac615dfd11e86b1ce7766e1de263ce3d2e3b727
Author: forshaw <forshaw@chromium.org>
Date: Mon Jun 13 20:39:13 2016

Fix for running Chrome under a service token.
This patch fixes an issue with the handling of the default DACL when running
Chrome under a service token, such as Local System. These tokens don't always
have an assigned logon session SID, which would cause the DACL lockdown process
to fail.

BUG= 615396 
CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win10_chromium_x64_rel_ng
TEST=1. Download PSTools from https://technet.microsoft.com/en-us/sysinternals/pstools.aspx
2. Run cmd.exe as an administrator
3. Run the command 'psexec -s -i c:\path\to\chrome.exe'
4. Verify that the browser is useable

Review-Url: https://codereview.chromium.org/2061703002
Cr-Commit-Position: refs/heads/master@{#399529}

[modify] https://crrev.com/6ac615dfd11e86b1ce7766e1de263ce3d2e3b727/sandbox/win/src/acl.cc
[modify] https://crrev.com/6ac615dfd11e86b1ce7766e1de263ce3d2e3b727/sandbox/win/src/restricted_token_unittest.cc

A friendly reminder that M52 Stable is launching soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch by July 12. All changes MUST be merged into the release branch by 5pm on July 15 to make into the desktop Stable final build cut. Thank you!

Your change meets the bar and is auto-approved for M52 (branch: 2743)

Tested the same on win8.1 chrome version 53.0.2774.2 following the steps in TEST in comment #32 - observed the browser is usable

Please find the screenshot

Deleted: 615396.png 179 KB

	615396.png 179 KB View Download

forshaw@, can you please merge the CL in to M52 branch by noon today so that it gets picked up for beta promotion scheduled tomorrow.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f6ba15785561d8ee4146c589fbb4b77b6c20e02b

commit f6ba15785561d8ee4146c589fbb4b77b6c20e02b
Author: James Forshaw <forshaw@chromium.org>
Date: Tue Jun 21 16:49:20 2016

Fix for running Chrome under a service token. This patch fixes an issue with the handling of the default DACL when running Chrome under a service token, such as Local System. These tokens don't always have an assigned logon session SID, which would cause the DACL lockdown process to fail.

BUG= 615396 
CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win10_chromium_x64_rel_ng
TEST=1. Download PSTools from https://technet.microsoft.com/en-us/sysinternals/pstools.aspx
2. Run cmd.exe as an administrator
3. Run the command 'psexec -s -i c:\path\to\chrome.exe'
4. Verify that the browser is useable

Review-Url: https://codereview.chromium.org/2061703002
Cr-Commit-Position: refs/heads/master@{#399529}
(cherry picked from commit 6ac615dfd11e86b1ce7766e1de263ce3d2e3b727)

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

Cr-Commit-Position: refs/branch-heads/2743@{#431}
Cr-Branched-From: 2b3ae3b8090361f8af5a611712fc1a5ab2de53cb-refs/heads/master@{#394939}

[modify] https://crrev.com/f6ba15785561d8ee4146c589fbb4b77b6c20e02b/sandbox/win/src/acl.cc
[modify] https://crrev.com/f6ba15785561d8ee4146c589fbb4b77b6c20e02b/sandbox/win/src/restricted_token_unittest.cc

Tested the same on win8.1 chrome version 52.0.2743.49 following the steps repro steps - observed the browser is usable

I've tested it using 52.0.2743.29 beta-m and:
"psexec.exe -s -i 0 C:\...\chrome.exe" - it's not working
"psexec.exe -s -i C:\...\chrome.exe" - is working

Could someone recheck it also?

Can anyone recheck it also on Session 0?

Tried both 

psexec.exe -s -i 0 "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe"

and 

psexec.exe -s -i "C:\Program Files (x86)\Google\Chrome\Application\chrome.exe"

For the latter, Chrome opens but throws an error saying it can't locate manifest file. For the Former, I see the Chrome processes started, but Chrome does not open. We are still having RANDOM WebDriver timeouts when performing actions such as clicking, clearing cookies, and taking screenshots. It is not reproducible.

Chrome 51.0.2704
Chromedriver 2.22
TeamCity 9.1.4

Deleted: Chromedriver.PNG 27.0 KB

	Chromedriver.PNG 27.0 KB View Download

jakub.jeszke@, zt10191991@,

Fix is already been made and is available in Chrome version 52.0.2743.49+
Please try using this version of Chrome keeping the same Chromedriver v2.22.

If you see any issue on version 52.0.2743.49+ , Please feel free to file a new issue.

Does anyone know when v52.0.2743 will be made the stable channel release?

https://www.chromium.org/developers/calendar

 Issue 618395  has been merged into this issue.

I've tested it using 52.0.2743.74 beta-m and:
"psexec.exe -s -i 0 C:\...\chrome.exe" - it's not working, dark background
"psexec.exe -s -i C:\...\chrome.exe" - is working

Updated build servers to Chrome v 52.0.2743.82

TC webdriver tests are still failing.

TC 9.1.1
ChromeDriver 2.22.397933

The same for us, reproducible.
Chrome v52, TeamCity Enterprise 9.1.3, ChromeDriver 2.22, NSSM as a service manager.

I've identified what's causing the issue and it's an unrelated sandbox change to the original bug. I've reopened to commit a new patch to make this work as it might have an impact on non-session 0 sandbox code. I still believe we should move away from supporting Session 0 if at all possible.

M52 is already in Stable for Desktop and bar is VERY high and we can take this change in ONLY if it is critical, well baked/verified in Canary and very safe to merge. Please confirm this. Thank you.

Any updates on this issue?

We are planning a Stable RC today ( 08/01), if the issue is fixed and verified in canary, we can take it for upcoming stable refresh(if any).

Fix is still in commit stage, so won't be close to merging into canary today I'm afraid let alone verified. Hopefully committed later this evening to get tested.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/37dd5680ab4edbbf730e8540825b9caa8db0d911

commit 37dd5680ab4edbbf730e8540825b9caa8db0d911
Author: forshaw <forshaw@chromium.org>
Date: Tue Aug 02 17:47:50 2016

Ignore desktop creation errors in the sandbox.
This patch reverts the original behaviour that we ignore errors when creating
the alternative desktop. Also this includes a change to try and open the window
station with lower privileges if the first request fails, which works fine for
operation but not for testing. Finally it logs any failure to create the desktop
as a warning in the existing histogram.

CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win10_chromium_x64_rel_ng
TEST=1. Test on Windows 7
2. Download PSTools from https://technet.microsoft.com/en-us/sysinternals/pstools.aspx
3. Run cmd.exe as an administrator
4. Run the command 'psexec -s -i 0 c:\path\to\chrome.exe'
5. Click on the icon which indicates there a message on the service desktop. This will switch to the service desktop where chrome is running.
6. Verify that the browser is useable

BUG= 615396 

Review-Url: https://codereview.chromium.org/2193603004
Cr-Commit-Position: refs/heads/master@{#409229}

[modify] https://crrev.com/37dd5680ab4edbbf730e8540825b9caa8db0d911/content/common/sandbox_win.cc
[modify] https://crrev.com/37dd5680ab4edbbf730e8540825b9caa8db0d911/sandbox/win/src/window.cc

Thanks for the Fix!

Tested on Windows 7 rev#409244 & Canary build v54.0.2817.0.
'psexec -s -i 0 c:\path\to\chrome.exe'
verified that browser is usable.

Where can i get the build for this fix please?

You can download a canary channel build from https://www.google.com/chrome/browser/canary.html

Not got a windows 7 environment to test on till morning.

Windows server 2012 standard 6.2.9200
Canary build v54.0.2817.0

'psexec -s -i 0 c:\path\to\chrome.exe'
Browser doesn't start

I do not have Windows server 2012 machine but I tested on Windows 10 and it looks good. Browser starts and navigates to the given URL.

In order to see browser running, you would need to switch to interactive service desktop. After you execute psexec command, a popup 'Interactive Services Detection' will appear. Click on "View the message" on the popup. It will switch to service desktop where chrome browser is running.

If you haven't tested it this way, can you please try and let us know?

Also, there is another way for verifying this fix.
1) Run the command with remote-debugging-port.
psexec -s -i 0 "c:\path\to\chrome.exe" --remote-debugging-port=1234 "http://www.gmail.com"
2) Now open a regular chrome instance and navigate to 'http://localhost:1234'
=> Here, you should see "gmail" page link.

I've tried it on Windows Server 2012 R2 and it works fine for me. Worth pointing out the interactive desktop switch which works on Windows 7 does not work by default on 8 and above (so including 2012). The ui0detect service is off by default, and you also need to set the HKLM\SYSTEM\CurrentControlSet\Control\Windows\NoInteractiveServices value to 0 otherwise it will refuse to start. So it's possible that chrome had successfully started on Session 0 but you wouldn't be able to see it running.

Is this require a merge to M53? 

Also bitten by this. Remembered resolution from last time this was broken, so not much time wasted. Chrome selenium node started by interactive shell instead of service is our workaroundn until this is fixed in stable channel. (latest chromedriver doesnt seem to work with canary...)

forshaw@,  Does CL listed at #56 require a merge to M53? If yes, please request a merge to M53 ASAP. Thank you.

request to merge 37dd5680ab4edbbf730e8540825b9caa8db0d911 to branch 2785

Your change meets the bar and is auto-approved for M53 (branch: 2785)

Approving merge to M53 branch 2785 based on chat with samuong@. This change is well baked in canary and verified. Please merge latest by 5:00 PM PT tomorrow, Friday so we can pick it up for next week Beta. Thank you.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6e54a7bc46d5451ef1019fa243ec964aa9fb4179

commit 6e54a7bc46d5451ef1019fa243ec964aa9fb4179
Author: Will Harris <wfh@chromium.org>
Date: Thu Aug 11 18:13:46 2016

Merge M53: Ignore desktop creation errors in the sandbox.

This patch reverts the original behaviour that we ignore errors when creating the alternative desktop. Also this includes a change to try and open the window station with lower privileges if the first request fails, which works fine for operation but not for testing. Finally it logs any failure to create the desktop as a warning in the existing histogram.

CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win10_chromium_x64_rel_ng
TEST=1. Test on Windows 7
2. Download PSTools from https://technet.microsoft.com/en-us/sysinternals/pstools.aspx
3. Run cmd.exe as an administrator
4. Run the command 'psexec -s -i 0 c:\path\to\chrome.exe'
5. Click on the icon which indicates there a message on the service desktop. This will switch to the service desktop where chrome is running.
6. Verify that the browser is useable

BUG= 615396 

Review-Url: https://codereview.chromium.org/2193603004
Cr-Commit-Position: refs/heads/master@{#409229}
(cherry picked from commit 37dd5680ab4edbbf730e8540825b9caa8db0d911)

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

Cr-Commit-Position: refs/branch-heads/2785@{#565}
Cr-Branched-From: 68623971be0cfc492a2cb0427d7f478e7b214c24-refs/heads/master@{#403382}

[modify] https://crrev.com/6e54a7bc46d5451ef1019fa243ec964aa9fb4179/content/common/sandbox_win.cc
[modify] https://crrev.com/6e54a7bc46d5451ef1019fa243ec964aa9fb4179/sandbox/win/src/window.cc

I was getting an issue where all my chrome tests would pass both locally and if I ran them myself on the build server. However, they would fail every time if the tests were run as a windows service in my VSTS Build. My chrome tests started passing again once I disabled the developer extensions that were added on the new chrome version. I basically added the code below to all of my chrome test and now they are passing in all environments and as a windows service.  As stated multiple times about I think this is a compatibility issue with the driver and browser.  I tried all the above "fixes" and this seems to be the only one that works for me.

Heres what I was using to remote build and testing:
Chrome: 52.0.2743.116 m (64-bit)
Chrome Driver: 2.23.409699
Windows: 2012 R2
Visual Studio Team Services

Code:
 ChromeOptions chromeOptions = new ChromeOptions();
            chromeOptions.AddArguments("test-type");
            chromeOptions.AddArguments("start-maximized");
            chromeOptions.AddArguments("--disable-extensions");
            chromeOptions.AddArguments("no-sandbox");
            PropertiesCollection.driver = new ChromeDriver(chromeOptions);

I can confirm that adding the "no-sandbox" argument when running Chrome is a workaround for this problem. I'm on Windows 2008 R2 running 52.0.2743.116.

Same here.
no-sandbox Option fixed for me:
System.Exception : OpenQA.Selenium.WebDriverException: The HTTP request to the remote WebDriver server for URL session timed out after 60 seconds. ---> System.Net.WebException: The request was aborted: The operation has timed out.

Chrome:
Wersja 53.0.2785.57 beta-m (64-bit)
ChromeDriver:
2.23.409699
Windows Server 2012
And Windows 10
(NUnit Remote Runner - C#)

Thanks :)

Tested the issue on Windows 7 using 53.0.2785.70 as per steps in comment #69.The chrome browser is usable on service desktop.

Marking it as TE-Verified-53.0.2785.70.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/72d84be035096e74aab4ebb168d2aa221e6bf726

commit 72d84be035096e74aab4ebb168d2aa221e6bf726
Author: Will Harris <wfh@chromium.org>
Date: Wed Aug 17 17:24:52 2016

Merge M52: Ignore desktop creation errors in the sandbox.

This patch reverts the original behaviour that we ignore errors when creating the alternative desktop. Also this includes a change to try and open the window station with lower privileges if the first request fails, which works fine for operation but not for testing. Finally it logs any failure to create the desktop as a warning in the existing histogram.

CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win10_chromium_x64_rel_ng
TEST=1. Test on Windows 7
2. Download PSTools from https://technet.microsoft.com/en-us/sysinternals/pstools.aspx
3. Run cmd.exe as an administrator
4. Run the command 'psexec -s -i 0 c:\path\to\chrome.exe'
5. Click on the icon which indicates there a message on the service desktop. This will switch to the service desktop where chrome is running.
6. Verify that the browser is useable

BUG= 615396 ,638516

Review-Url: https://codereview.chromium.org/2193603004
Cr-Commit-Position: refs/heads/master@{#409229}
(cherry picked from commit 37dd5680ab4edbbf730e8540825b9caa8db0d911)

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

Cr-Commit-Position: refs/branch-heads/2785@{#565}
Cr-Branched-From: 68623971be0cfc492a2cb0427d7f478e7b214c24-refs/heads/master@{#403382}
(cherry picked from commit 6e54a7bc46d5451ef1019fa243ec964aa9fb4179)

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

Cr-Commit-Position: refs/branch-heads/2743@{#730}
Cr-Branched-From: 2b3ae3b8090361f8af5a611712fc1a5ab2de53cb-refs/heads/master@{#394939}

[modify] https://crrev.com/72d84be035096e74aab4ebb168d2aa221e6bf726/content/common/sandbox_win.cc
[modify] https://crrev.com/72d84be035096e74aab4ebb168d2aa221e6bf726/sandbox/win/src/window.cc

Tested the issue on 52.0.2743.118 as per steps in comment #74 and verified that Chrome browser is usable on service desktop.

Tested the same on win7 chrome version 52.0.2743.119 following the steps in TEST in comment #74 - Chrome browser is usable on service desktop

Hence adding TE Verified labels

forshaw@, Could you please change the status to Fixed if no more work is pending.

hi, have to bring this issue up again.

I am using vs .net 2015 with update 3 version # 14.0.25425.01 with .net 4.6.01055

and my chrome version is:


Google Chrome	55.0.2883.75 (Official Build) m (32-bit)
Revision	451c239c3b0722dc867b0f75839b959f729b756a-refs/branch-heads/2883@{#698}
OS	Windows 
JavaScript	V8 5.5.372.29
Flash	24.0.0.194
User Agent	Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.75 Safari/537.36
Command Line	"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --flag-switches-begin --flag-switches-end
Executable Path	C:\Program Files (x86)\Google\Chrome\Application\chrome.exe

somehow just since yesterday, I am seeing this issue:

2017-01-13 11:01:18.006  9228  1 INFO  Paragon.Runtime.AutoStopwatch Creating browser took 893ms
2017-01-13 11:01:18.006  9228  1 INFO  Paragon.Runtime.AutoStopwatch Creating browser control took 918ms
[0113/110118:ERROR:child_process_launcher.cc(505)] Failed to launch child process

expected browser instance failed to launched up.

can someone throw some light here ?

thanks