This has been happening intermittently for me for the past five or so months now and not just in a VM. Related:

https://productforums.google.com/forum/?utm_medium=email&utm_source=footer#!msg/chrome/Tf4BehUkWL8/ZmBOy05IAwAJ

He filed a bug report here:

https://bugs.chromium.org/p/chromium/issues/detail?id=665203

I've tried disable Remote Desktop Services as well and it made no difference for me.

I use Chrome all day for work. Several times a day Chrome becomes corrupted. I'll open a new tab and it'll either be unresponsive - that is, if I type a URL in or search query, it does nothing. Or I'll get the gray tab with frowny face in the tab.

Nothing fixes this except closing all my Chrome windows and starting it back up fresh. Sometimes I have to manually kill some Chrome processes before I can start Chrome up again.

I've tried:

- Installing / re-installing Chrome
- Running Chrome cleanup tool
- Deleting and re-syncing my user profile
- Disabling hardware acceleration (which was a recommendation from a previous similar issue from years ago)
- Disabling Remote Desktop Services

I'm on the latest Chrome stable channel, Windows 10, not on a domain, syncing with my Google for Work account. Not running anything other than the stock Windows 10 AV.

This issue is extremely jarring so please let me know if there is anything else I can do to help get this resolved. I'll upload a debug log a bit later.

Sounds like we have some issue spawning child processes in some cases.

Adding a few people that might have some ideas.

Some info from a chrome_debug.log attached to the original report: 
[2816:1964:0303/123217.819:ERROR:configuration_policy_handler_list.cc(92)] Unknown policy: DnsPrefetchingEnabled
[2816:1964:0303/123217.913:ERROR:configuration_policy_handler_list.cc(92)] Unknown policy: DnsPrefetchingEnabled
[2816:1964:0303/123218.194:ERROR:child_process_launcher.cc(522)] Failed to launch child process
[2816:5172:0303/123219.256:ERROR:child_process_launcher.cc(522)] Failed to launch child process
[2816:5172:0303/123219.360:ERROR:child_process_launcher.cc(522)] Failed to launch child process
[2816:1964:0303/123229.234:ERROR:child_process_launcher.cc(522)] Failed to launch child process
[2816:1964:0303/123229.756:ERROR:child_process_launcher.cc(522)] Failed to launch child process
[2816:1964:0303/123231.319:ERROR:child_process_launcher.cc(522)] Failed to launch child process

https://productforums.google.com/forum/#!topic/chrome-admins/nnJzdCQ7N_U

Same here in a non-virtual situation:
We are setting up a new Windows 10 environment in our company network. It is a not a virtual environment, but we encounter the same problem. Chrome (56.0.2924.87 (64-bit)) just giving the "Frowny Face" tab after one to two weeks. Re-install a fresh copy of chrome solves the issue temporarily. Starting chrome with the '--no-sandbox' option is a work-arround. Windows 10 version 1607 build 14393.693

Greetings,
Gert

Knowing the crash IDs might be able to help if you are able to retrieve them.

Sending to the Stability-Sheriff-Desktop queue. This certainly doesn't seem like a Blink issue.

So I did look under Chrome://crashes and there are no crash IDs listed.

I found no crash IDs either. I enabled debug logging but of course I have not had the problem since then (yesterday, I believe), which is odd. 

This issue has been escalated in our organization. We now have reports that this is happening on physical devices as well. So far all machines are Windows 10 Pro Build 1607. This happened on one of our engineer's machine, he reported that installing Canary fixed the issue. The other strange thing, in some cases if you reboot, Chrome will work until your reboot again. The issue seems to be very intermittent.

+robliao, +wfh, +forshaw, this sounds vaguely similar to  bug 645319 ?

vagely similar, but I think different because  issue 645319  only happened during a session and only for the lifetime of that session, a restart would always fix it, and it was not reliably reproducable.

I'd certainly be interested in looking further into this specific case, is is possible to start Chrome from a command prompt with switches:

--enable-logging=stderr --v=1 --vmodule=metrics=2 > log.txt 2>&1

then search the log.txt for the histogram Process.Sandbox.Launch.Error and reply with that here.

My logfile (options --enable-logging=stderr --v=1 --vmodule=metrics=2 > log.txt 2>&1)

Deleted: log.zip 29.0 KB

log.zip 29.0 KB Download

Histogram: Process.Sandbox.Launch.Error recorded 5 samples (flags = 0x1)
87  ------------------------------------------------------------------------O (5 = 100.0%)

87 is ERROR_INVALID_PARAMETER

The log file I gathered is much smaller and doesn't contain the text you are looking for.

Deleted: log.txt 1.4 KB

log.txt 1.4 KB View Download

Thanks for the log.

This does look like  issue 645319  except this is reproducible so it's quite a lot more interesting and potentially actionable...

I don't suppose it would be possible to package up your VM for us to look at here? Obviously if it contains any sensitive data then we'd rather not have that but if you are seeing this for a clean VM...?

Alternatively can you answer questions:

 - Is this machine connected to a domain?
 - Is this using RDS drives or any sort of folder redirection?
 - Can you confirm exact Chrome version and channel and exactly where Chrome is installed and running from? Also, whether you are running 32-bit or 64-bit
 - Can you confirm that the location Chrome is running from is not on a redirected drive, but a local disk?
 - Can you check the Chrome application folder (C:\Program Files (x86)\Google\Chrome\Application) for other executables e.g. old_chrome.exe and new_chrome.exe?
 - Do you have automatic updates enabled?
 - If you look at the properties for chrome.exe in C:\Program Files (x86)\Google\Chrome\Application and "details" tab, does the "Product Version" match the subdirectory name e.g. 56.0.2924.87 would be the same directory all the Chrome modules are contained in.
 - Are you using any sort of Antivirus or other third party programs such as firewall, antimalware, that might be interfering with Chrome?

Thanks for your continued help with this investigation.

Thank you for providing more feedback. Adding requester "wfh@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Re: #13 are you sure you specified --v=1 and --vmodule=metrics=2 on the command line?

Yes. Here is the exact command from the cmd window:
C:\Program Files (x86)\Google\Chrome\Application>chrome.exe --enable-logging=stderr --v=l --vmodule=metrics=2 > log.txt 2>&1
I ran it again, with the same results.

Thank you for providing more feedback. Adding requester "wfh@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I can't package the VM, however I would be willing to setup an external Webex meeting where someone can control the machine, troubleshoot, and gather any information needed.

re: #17 make sure you don't have any other copies of Chrome running before you use those switches, and make sure you totally exit Chrome (use hotdog menu then click "Exit") before gathering the log. Also make sure you have write access to the location you are logging to.

I confirmed that no other copies of Chrome were running. I am logged in as administrative account, and I executed CMD as an administrator. I've also generated this log file under different directories, it looks the same. 

Deleted: log3.txt 1.4 KB

log3.txt 1.4 KB View Download

#21, that's very strange. Perhaps try adding --user-data-dir as in:

chrome.exe --user-data-dir=c:\tmp\something --enable-logging=stderr --v=l --vmodule=metrics=2 > log.txt 2>&1

I opened up a cmd window as my regular admin user account and ran Chrome with the requested flags. Everything ran fine for a couple of hours, then as I went to reply to this ticket I started getting "Aww Snap" on every new tab and the frowny face as well. What's different now is I get the Aww Snap page where as before it was all black. Same end result though - I had to close all Chrome processes and restart Chrome to get it to work again.

There are many histograms in the log file but no Process.Sandbox.Launch.Error. Here are the exact log entries that were created every time I opened a new tab and got the Aww Snap page:

[17056:31840:0309/142816.553:VERBOSE1:cross_device_promo.cc(180)] CrossDevicePromo::MaybeBrowsingSessionStarted; Ineligible for promo.
[17056:31840:0309/142816.553:VERBOSE1:cross_device_promo.cc(180)] CrossDevicePromo::MaybeBrowsingSessionStarted; Ineligible for promo.
[0309/142817.420:ERROR:process_info.cc(608)] range at 0xd64c6a3a00000000, size 0x242 fully unreadable
[0309/142817.420:ERROR:process_info.cc(608)] range at 0xd64c6a9c00000000, size 0x242 fully unreadable
[0309/142817.420:ERROR:process_info.cc(608)] range at 0x0, size 0x242 fully unreadable

Let me know if I can provide any other info out of the log file.

#23, can you see if you have any crashes in chrome://crashes if you have crash reporting enabled (and post the crash IDs here)? The end of that log indicates a crash was being captured.

Yep - now I see several crash IDs (there were none the other day). I sent them and they finally uploaded. Here are the IDs:

682f7acb-77e6-41ff-a28d-b1521e4f7eba

61d06e58-a447-4909-adc9-3693d38a5d20

7310f7fb-3e3a-43d5-845b-05cf881e46b6

#25, those are the local (on your machine) IDs. Is there a "Server ID" listed for the crashes you could post?

Oops yep:

c8ef263920000000

8fe7a63920000000

c590b96480000000

#22, I ran the following command:
C:\Program Files (x86)\Google\Chrome\Application>chrome.exe --user-data-dir=c:\temp\googleuser --enable-logging=stderr --v=l --vmodule=metrics=2 > C:\Temp\log4.txt 2>&1
With what appears to be the same results, it did create a 'C:\Temp\googleuser' and looks a bit like a user profile.

Deleted: log4.txt 2.0 KB

log4.txt 2.0 KB View Download

I managed to get this now:

[27324:3880:0309/172018.743:ERROR:child_process_launcher.cc(522)] Failed to launch child process

Histogram: Process.Sandbox.Launch.Error recorded 1 samples (flags = 0x1)
87  ------------------------------------------------------------------------O (1 = 100.0%)

What I did was this: once I started getting "Aww Snap" on each new tab, I cloned an already open tab to see if it would work, and it did. After this I opened a new tab and got the normal new tab page. I typed in a search term into the URL bar (using Google) and nothing happened (this generated a Failed to launch child process" error).

As far as I can tell, this did NOT generate a crash report. The only thing generating crash reports are the aww snap pages.

To clarify, once I start getting Aw, Snap! I can duplicate a tab and the page will load and reload, but if I try to enter in a new URL nothing happens in the UI itself. Logs show "Failed to launch child process" among other things.

I've been messing around with this - sometimes I get the aw, snap page, sometimes I get a blank gray page, and sometimes the URL will load. But once I get aw, snap or a gray page, Chrome is effectively so corrupted that I have to restart it.

Also, I don't know if it's these logging flags I'm using, but this has been happening a LOT more today than usual.

I also have this error on a couple of virtual machines running Windows Server 2008 R2:

Immediately after updating Chrome 55 to Chrome 56, Chrome is unable to display *any* page. No websites, no settings page, no about page, nothing. The main window stays blank and "He’s Dead, Jim!" is shown.

This is true for 3 different Windows Server 2008 R2 installations (virtual servers).

No complete removal and reinstallation helps (no incognito and also none of the other tricks mentioned).

Canary also shows this behaviour, so I suspect it is something that was introduced with v56.

Adding the -no-sandbox switch is a workaround.

Let me know if I can provide more information.

Unless something has changed,  http://crbug.com/645319  wouldn't even get to the "Aww Snap" page. The navigation just wouldn't proceed as a result of the child process not launching. 

One thing that we did notice in 645319 is that CreateProcessAsUser was failing during handle duplication. Closing the bad handle allowed everything to work again, indicating that we might have some handle issues running around.

In the crashes from #27, we seem to be crashing in WebRTC init:

0:000> kn20
 # Child-SP          RetAddr           Call Site
00 000000a3`247de8b0 00007fff`ea26ccad chrome_child!`anonymous namespace'::InvalidParameter+0x18 [c:\b\build\slave\win64-pgo\build\src\base\win\process_startup_helper.cc @ 21]
01 000000a3`247de8e0 00007fff`ea28e578 chrome_child!_invalid_parameter_noinfo+0x19 [d:\th\minkernel\crts\ucrt\src\appcrt\misc\invalid_parameter.cpp @ 98]
02 000000a3`247de920 00007fff`ea2962f9 chrome_child!_isatty+0x58 [d:\th\minkernel\crts\ucrt\src\appcrt\lowio\isatty.cpp @ 17]
03 000000a3`247de950 00007fff`ea27195c chrome_child!__acrt_stdio_begin_temporary_buffering_nolock+0x19 [d:\th\minkernel\crts\ucrt\src\appcrt\stdio\_sftbuf.cpp @ 43]
04 (Inline Function) --------`-------- chrome_child!__acrt_stdio_temporary_buffering_guard::{ctor}+0x8 [d:\th\minkernel\crts\ucrt\inc\corecrt_internal_stdio.h @ 399]
05 000000a3`247de980 00007fff`ea271922 chrome_child!<lambda_532e024f4337e6fc7ad266c2bef9f4ed>::operator()+0x20 [d:\th\minkernel\crts\ucrt\src\appcrt\stdio\fwrite.cpp @ 39]
06 000000a3`247de9b0 00007fff`ea271bb7 chrome_child!__crt_seh_guarded_call<unsigned __int64>::operator()<<lambda_5d4c3fee44080f75d5d9762853974fe0>,<lambda_532e024f4337e6fc7ad266c2bef9f4ed> & __ptr64,<lambda_c87bdc10097eb2402edb8ba9bdf0697b> >+0x26 [d:\th\minkernel\crts\ucrt\devdiv\vcruntime\inc\internal_shared.h @ 199]
07 (Inline Function) --------`-------- chrome_child!__acrt_lock_stream_and_call+0x39 [d:\th\minkernel\crts\ucrt\inc\corecrt_internal_stdio.h @ 255]
08 000000a3`247de9e0 00007fff`e9b8099a chrome_child!fwrite+0x7f [d:\th\minkernel\crts\ucrt\src\appcrt\stdio\fwrite.cpp @ 40]
09 000000a3`247dea50 00007fff`ea6e1417 chrome_child!logging::LogMessage::~LogMessage+0xc6 [c:\b\build\slave\win64-pgo\build\src\base\logging.cc @ 692]
0a 000000a3`247def00 00007fff`ea0b9561 chrome_child!rtc::DiagnosticLogMessage::~DiagnosticLogMessage+0x627eab [c:\b\build\slave\win64-pgo\build\src\third_party\webrtc_overrides\webrtc\base\logging.cc @ 206]
0b 000000a3`247df070 00007fff`e9fc0c26 chrome_child!rtc::DetectNumberOfCores+0x61 [c:\b\build\slave\win64-pgo\build\src\third_party\webrtc\base\systeminfo.cc @ 84]
0c (Inline Function) --------`-------- chrome_child!rtc::SystemInfo::GetMaxCpus+0xe [c:\b\build\slave\win64-pgo\build\src\third_party\webrtc\base\systeminfo.cc @ 100]
0d (Inline Function) --------`-------- chrome_child!webrtc::CpuInfo::DetectNumberOfCores+0xe [c:\b\build\slave\win64-pgo\build\src\third_party\webrtc\system_wrappers\source\cpu_info.cc @ 18]
0e 000000a3`247df1f0 00007fff`e9fc0e9e chrome_child!InitializeWebRtcModule+0x12 [c:\b\build\slave\win64-pgo\build\src\third_party\webrtc_overrides\init_webrtc.cc @ 79]
0f 000000a3`247df220 00007fff`e9d59f6c chrome_child!content::RendererMain+0x14e [c:\b\build\slave\win64-pgo\build\src\content\renderer\renderer_main.cc @ 177]
10 000000a3`247df3f0 00007fff`e9d5a63a chrome_child!content::RunNamedProcessTypeMain+0xb4 [c:\b\build\slave\win64-pgo\build\src\content\app\content_main_runner.cc @ 425]
11 000000a3`247df550 00007fff`e9d5a569 chrome_child!content::ContentMainRunnerImpl::Run+0xae [c:\b\build\slave\win64-pgo\build\src\content\app\content_main_runner.cc @ 774]
12 000000a3`247df5d0 00007fff`e9d59bcd chrome_child!content::ContentMain+0x85 [c:\b\build\slave\win64-pgo\build\src\content\app\content_main.cc @ 20]

This should be non-fatal. Maybe these are the wrong crashes?

(stability sheriff here)

I see the right folks are cc'd and looking so I'll remove the stability sheriff label for now.

We got an independent report of the same issue on the admin forum https://productforums.google.com/forum/#!topic/chrome-admins/FytURd6-vlg;context-place=forum/chrome-admins

I am raising the priority of this bug as it seems to hit multiple users in Enterprise now.

Re Comment #32: What I can see in the stack trace: the child process is trying to log something from DetectNumberOfCores, the involved fwrite call wants to check if the passed FILE* is a terminal (calls isatty) which thinks the passed file handle is invalid. That's why it goes to the chromium-set invalid param handler which does a debugbreak and exit(1).

A few questions:
(1) Why should this be non-fatal?
(2) The path to isatty.cpp in the stack trace is: d:\th\minkernel\crts\ucrt\src\appcrt\lowio\isatty.cpp - does that look right?
(3) According to a discussion in [1], isatty line 17 (which is in the stack trace) checks for: (fh >= 0 && (unsigned)fh < (unsigned)_nhandle)
(4) logging.cc seems to write to stderr.

-> Maybe stderr is invalid for some reason?

[1] https://social.msdn.microsoft.com/Forums/vstudio/en-US/0c75a94c-ec48-4749-9be2-2b482cf94d2b/fclose-causing-debug-assertion-failed-crash?forum=vcgeneral 

@wfh: Would you mind driving this issue as owner? Thanks. (This ended up on our enterprise triage list. Feel free to reassign.)

Any updates on this? Still seeing this issue with version 57.0.2987.98.

this is likely  issue 645319  - if you are able to reproduce consistently, can you try canary as we've landed a fix recently that might address this issue.

This issue has gotten worse for me too. After 4+ months of this I switched to Opera and haven't had a problem since.

I'm on Canary right now. I'll report back after a week or two if I don't see the issue again.

I've been running a couple of days on Canary now (8+ hours a day constant use and several updates to Canary). I haven't experienced this issue yet when before this it had been happening 2-3+ times a day. I'll keep using Canary for a while longer to make sure, but as of right now it looks like this has been fixed.

I've already asked on  issue 645319  above, but didn't receive a response. We just upgraded everyone to version 61.0.3163.79 of Google Chrome and this issue is being reported on a wider scale. This is now happening on physical machines. We have several users that are unable to work in certain web apps that we have configured for Chrome use only. Any updates on this?

Hi All, is this still happening for you on Chrome 62?

Based on lack of response I'm assuming this was fixed or went away.

 Issue 709554  has been merged into this issue.