Anything I can do to speed up this bug hunt?
I figured out a new Info:
it works like charm if i start Chrome as Administrator. This explains why chrome works directly after the Chrome Setup (started as Administrator.

if i start it with user rights -> the black screen appears

Dear Google Engineers, after a very long Trial and Error process with some other guys from our IT we could "solve" the problem.

It is caused by a GPO: 
„Computer->Administrative Templates->Windows Components->Remote Desktop Services->Remote Desktop Session Host->Remote Session Environment->Start a program on connection“. Until today we had the Option enabled with the following option:
cmd.exe /c "set CLIENTNAME="

After removing this everything works like a charm. But now please answer why google chrome calls a RDP connection on Startup even if chrome is started manually on the host-system??

Kind regards from Germany,
Patrick

Deleted: chrome-GPO.png 48.7 KB

	chrome-GPO.png 48.7 KB View Download

+ wfh@, jschuh@

Does setting the CLIENTNAME env var as described in #4 interfere with the Windows sandbox? #0 seems to suggest that Chrome can't launch any child processes including possibly the GPU process.

Also, is it true that Chrome is starting as Administrator after setup (see #2)? That sounds wrong.

The allow-no-sandbox-job switch should be the correct solution. Citrix puts processes for client sessions in a job, and Windows didn't support nested jobs until Win8. So, we added the allow-no-sandbox-job switch to let the sandbox ignore a job object failure when running in a remote session (i.e. we added it explicitly for Citrix).

You don't need the switch when running as admin, because the admin has the right to break out of any job. And my guess is that mucking with the CLIENTNAME environment variable works because it ends up toggling whether Citrix puts the processes in a job or not.

Once pastarmovj@ gets around to it he was going to make the code just autodetect whether you're running in a remote session on Win7 or earlier, and if so just silently continue after we fail on the job object. That way no one needs to mess with the switch anymore.

Nice... after one year anyone reads this and then read the wrong and close the bug. 
The bug is still there and you are not doing anything. Nice work google!


To clarify it again: in this case, ignore the --allow-sandbox parameter! This was just the workaround! yes, it works if you run the setup as administrator and have the variable CLIENTNAME set. If you try to run it as user, it won't work.

And this problem exists on regular PC clients! Not with Citrix!!! Regular installed Windows 7 PCs.

Please overthink your opinion of "WontFix" because it is really a bug! Why does a RDP GPO affect the default launch of Chrome outside of any RDP or CITRIX Session? 

Just to clarfy - you run Chrome on a desktop accessed directly through a local terminal and yet you observe the issues described? Can you please check if running with --disable-gpu in this case lets the browser work again?

Yes, running on a local terminal the issue described above appears if the described GPO is set. The only working workaround was using the --allow-no-sandbox switch.
But disabling the security features was no allowed workaround in our company - so I hat to figure it out with the GPO.

Just try it yourself by using gpedit.msc and setting the GPO as described in #4.

First, please take a look at the documentation for the "Start a program on connection" GPO:
https://technet.microsoft.com/en-us/library/cc770821(v=ws.11).aspx

What should have happened with the GPO value you had set was that the user connects, cmd.exe launches, sets the environment variable for the current process, and then terminates. The user connection should then also immediately terminate. (I should also note that setting the CLIENTNAME environment variable there does nothing, because affects only the process that's about to terminate.)

So, I honestly have no idea how you were able to get to the Windows shell at all, because that GPO setting should have explicitly prevented you, and basically just immediately logged you off. Regardless, the key detail is that the GPO you were using is similar to Citrix's Application Publishing. As such, it was forcing all processes into a job, which is the problem that Citrix is documenting here: https://support.citrix.com/article/CTX132057

This comes full circle to my original reply: If you're not running at least Win8 and Chrome is running inside a job object in a remote session (whether using Citrix Application Publishing or the Windows GPO) you currently need to pass the --allow-no-sandbox command line switch. It's literally the sole purpose for that switch, and the security impact is minimal, as the job object and restrictions set by the Citrix/Windows application hosting mode end up serving most of the same purpose. That's why we're planning on making the behavior automatic, and not requiring the switch in the future.

Fortunately, it looks like you didn't actually want to publish a single application, so removing the misconfigured GPO setting appears to have solved your problem.

I think you still didn't get what I'm trying to tell you. It was no thin-client, it was no Citrix session, it was no RDP session -> it was me sitting in front of a regular fat-client with this special GPO set inside our domain.

If you want to automate the process for Citrix users, it's good but that's another point. My point is that this GPO takes effect!? It is a GPO that should only apply if a RDP session is called. So i habe the following questions: 
- why is chrome calling a RDP session 
- why is this little variable killing chromes sandbox process? 

Both is no wanted behavior!

This seems to be an isolated issue, I just reproduced the environment described in comment 4 on a Win 2k8 R2 and Chrome runs just fine regardless of the value of the aforementioned policy (see screenshot).

Deleted: chromewithrdppolicyon.png 201 KB

	chromewithrdppolicyon.png 201 KB View Download