RESOLUTION:

CHANGE THE FOLLOWING REGISTRY KEY 1 TO 0:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\codeidentifiers

Not until I know exactly what that does.  Can you provide any context?

This 1 to 0 regkey change would likely disable SRP temporarily until GPO reapplies it.

The above "fix" is just disabling SRP locally, wouldn't consider this a resolution.

According to this page:
https://support.microsoft.com/en-gb/kb/324036#bookmark-16

That reg key will disable certificate rules which is what other forums are suggesting is a "workaround" but it's not a workaround if you actively use certificate rules as part of your SRP config so I would tread carefully.

Confirmed here as well. Disabling the Cert Rule allows it to run, tried adding all 4 certificates under the Chrome.exe to SRP Rules with no luck either.

Sorry, guys, i wrote RESOLUTION, but as everyone sad, is a WORKAROUND

Same here with SRP enabled it won't run.  Had to force everyone back to 53 for now.

Thank you.  Disabling cert rule enforcement is NOT a workaround or a resolution.  It might be part of the downgrade to version 53 process though.  I can't even uninstall 54 without disabling cert rule enforcement first.  Thanks for the job security Google.

Same here, I am losing clients by the dozens and HD is ringing off the hook.  Please address ASAP Google!!!!

This is also happening in our organization with Software Restriction Policies enabled. Was working fine with previous 53.xxx versions.

Installed Chrome Canary(run as administrator) on top of my broken Chrome 54 and Canary is working.  

https://www.google.com/chrome/browser/canary.html

Canary Version showing installed: 56.0.2890.0 canary (64-bit)

PC is Windows 7 Pro SP1 x64 with SRP GPO applied.  

So something was updated/removed in their highly unstable newer test version.

Same problems on our domain. We were able to block Chrome from updating by installing the Google Update GP templates and disabling the updates for all 4 Google Chrome options (Google Chrome, Google Chrome Binaries, Google Chrome Canary Build, Google Chrome Frame).

Same issue, please fix, thanks!

Adding my voice to this - definitely a bug that required rollback to 53. Hoping for a quick resolution as disabling SRP is not an option.

Seeing this as well. Confirmed that it is caused by enforcing certificate rules in SRP. Disabling this critical security feature is not an option for us.

Applying block for 54 to make sure this is evaluated before the release. 

we have collected PROCMON logs from an affected computer.

https://drive.google.com/file/d/0ByV1QxeRxxDpZGZEcEdMVEJ6dWc/view

We were unable to collect debug logs or net-internal dumps since the browser is not responding.

Confirming this is affecting my site also. Disabling certificate enforcement is not an option so I have downgraded all users to 53 & disabled the Chrome update services using group policy. Running in debug mode does nothing as the application cannot launch. Attempting to uninstall Chrome also triggers the problem.

Same problem here. But won't start even with "Ignore certificate rules". I have no temporary workaround. Rolling back to 53

Ninite updated our machines to latest version 54 over the weekend and now we are experiencing the same problem...chrome.exe runs in background, but no window is displayed. Disabling SRP loads Chrome fine, but this is not an option in today's ransomware world :)

Please fix asap!

Folks, the setting "enforce certificate rules" disabled solves it, while it has no negative side effect - certificate rules are enforced neverthelesss. Try it.

Upgrading to P0 to get someone assigned to review the feedbacks. Also lets comment on recommendation in #47 as well. Assigning to Richard to help route this.

Tentatively assigning Robert, re-assign if there's a more accurate fit.

Bernd... "the setting "enforce certificate rules" disabled solves it"

Not correct.  This is only a workaround for specifically installing and running Chrome v54.  It has a negative impact on other rules requiring certs.  For exmple; if you block .exe's from running in %temp% and %appdata% (mine are a little more detailed than that), have a cert rule for Firefox, Firefox will not install/run unless enforce certificate rules is enabled and you have a cert configured.

Chrome needs to behave like other applications.  If enforce cert rules is enabled and you have a cert configured for chrome, it should run...just like every other application configured this way.

A first step would be to figure out when this started happening.

Per offline chat with georgesak@, blumberg@ is already looking into this.

Scot, As noted in this thread, this started happening with the update to v54.  v53 does not experience this issue.

I recommend getting a repro, and then doing a bisect. If you need help let me know.

I can also attest that disabling the certificate enforcement does nideed launch chrome without issue, but alos does disable the cerificate rules which in my case doent allow programs that have been specified by a certificate to run. The other notable thing I have noticed is that after disabling the cerificate enforcement and launching chrome, re-enablingh the certificate enforcement and verifying that the certificate enforcement is in effect by launching an application that is only specified by a certificate (sorrr for the long setup so far)...I can create a tab on the already open chrome window, go to file>new window and get another chrome window, but if I try and launch the executable for chrome directly it doesnt launch successfully (visibly).

Repro steps on Windows 7 machine (from forshaw@):

Open gpedit.msc, navigate to Computer Configuration -> Windows Settings -> Security Settings -> Software Restriction Policies

On the Software Restriction Policies node right click and select to "New Software Restriction Policies". 

Under Software Restriction Policies open the Enforcement entry, and enable "Enforce certificate rules". 

Running latest Chrome M54 will now fail.

#50 - allow me to explain. I should not have called it a solution but a workaround. Calling it incorrect, you overlook one thing: Let's assume your SRP settings are set to disallow anything, that is not whitelisted and you have used certificate rules to whitelist some apps including chrome, then taking away the cert enforcement will still allow the same apps as before but chrome 54 will be startable in addition, since this setting is only partly activated, until we restart. Have a go and try. Only after a restart will windows disregard the other cert rules.
So this is a workaround - until the system restarts. But it can be re-applied.

I don't really know much about this, but I don't think blumberg@ is going to debug it :)

I will take for now. pbommana is going to try to bisect more closely.

Here's the stack trace for the hanging thread. As it never returns from CreateProcess the crashpad process never unsuspends. Looks like it's waiting on an a threadpool to finish doing something (but neither threadpool threads in the process are doing any work). Also due to the terrible state of Microsoft's symbol server atm some of these symbols might be wrong.

00 0028e14c 777c1923 ntdll!NtWaitForKeyedEvent+0x15
01 0028e1c0 777c1ad9 ntdll!RtlFreeUserStack+0x2bb
02 0028e240 76f9cb84 ntdll!RtlRegisterWait+0x183
03 0028e264 767fc8e5 kernel32!RegisterWaitForSingleObject+0x4f
04 0028e298 767fc821 CRYPT32!CertDiagPrvInitProcessInfo+0xd7
05 0028e2a8 767fa321 CRYPT32!CertDiagPrvAttachTls+0x16
06 0028e2c0 767fcf8a CRYPT32!CertDiagPushEvent+0x1e
07 0028e2d0 767fcf75 CRYPT32!I_WinVerifyTrustDiagStart+0xb
08 0028e2dc 765240e2 CRYPT32!I_CertDiagControl+0x15e
09 0028e2f4 76523aa5 WINTRUST!WinVerifyTrustDiagStart+0x17
0a 0028e41c 76522768 WINTRUST!I_IsUnsignedPEFile+0x8f8
0b 0028e43c 76ebe17c WINTRUST!WinVerifyTrust+0x52
0c 0028e4c0 76ed1f71 ADVAPI32!__CodeAuthzpCheckIdentityCertificateRules+0x10a
0d 0028e5dc 76ed2226 ADVAPI32!__CodeAuthzpIdentifyOneCodeAuthzLevel+0x262
0e 0028e660 76f8547c ADVAPI32!SaferIdentifyLevel+0x1b5
0f 0028e908 76f8446b kernel32!BasepCheckWinSaferRestrictions+0x173
10 0028ef90 76f71069 kernel32!CreateProcessInternalW+0x888
11 0028efc8 718d52b3 kernel32!CreateProcessW+0x2c
12 0028f1e8 718d41cc chrome_elf!crashpad::CrashpadClient::StartHandler+0x74c [c:\b\build\slave\win-pgo\build\src\third_party\crashpad\crashpad\client\crashpad_client_win.cc @ 334]
13 0028f590 718d2ca7 chrome_elf!crash_reporter::internal::PlatformCrashpadInitialization+0x27c [c:\b\build\slave\win-pgo\build\src\components\crash\content\app\crashpad_win.cc @ 111]
14 0028f5f4 718c1bd9 chrome_elf!crash_reporter::`anonymous namespace'::InitializeCrashpadImpl+0x40 [c:\b\build\slave\win-pgo\build\src\components\crash\content\app\crashpad.cc @ 151]
15 (Inline) -------- chrome_elf!crash_reporter::InitializeCrashpadWithEmbeddedHandler+0x16 [c:\b\build\slave\win-pgo\build\src\components\crash\content\app\crashpad.cc @ 203]
16 0028f650 718c3406 chrome_elf!ChromeCrashReporterClient::InitializeCrashReportingForProcess+0xa0 [c:\b\build\slave\win-pgo\build\src\chrome\app\chrome_crash_reporter_client_win.cc @ 229]
17 0028f678 718c34e2 chrome_elf!`anonymous namespace'::InitializeCrashReportingForProcess+0x45 [c:\b\build\slave\win-pgo\build\src\chrome_elf\chrome_elf_main.cc @ 50]
18 0028f6ac 718de2b6 chrome_elf!DllMain+0x17 [c:\b\build\slave\win-pgo\build\src\chrome_elf\chrome_elf_main.cc @ 119]
19 0028f6ec 718de39c chrome_elf!dllmain_dispatch+0x7c [f:\dd\vctools\crt\vcstartup\src\startup\dll_dllmain.cpp @ 200]
1a 0028f700 77789364 chrome_elf!_DllMainCRTStartup+0x1c [f:\dd\vctools\crt\vcstartup\src\startup\dll_dllmain.cpp @ 258]

wfh points out that CreateProcess in DllMain is probably sadness.

Please find the bisect range below :

https://chromium.googlesource.com/chromium/src/+log/54.0.2800.0..54.0.2802.0?pretty=fuller&n=10000

Suspecting CL :
https://chromium.googlesource.com/chromium/src/+/52c55bd8b84076cccdc877538787da279a8a1bf4

I ... think ... CreateThread()ing the initialize that does CreateProcess() is probably the most straightforward fix. I'm testing whether that fixes the repro or not now.

Scott, could you please confirm whether issue:  656201  is the same as this bug?

Not certain, but probably the same issue, yes.

Although the other issue mentions https://productforums.google.com/forum/#!topic/chrome/yYLxdVi_BC4 where the users reports problems with other applications too, so perhaps unrelated.

The simple fix I had in mind of calling from a background thread will not work. The browser does need to block until the initial connection is made.

I am concerned there is not going to be a quick fix for this problem.

Oh, one thing we could do is defer until slightly later (i.e. in WinMain()) instead of trying to background it from chrome_elf DllMain. This defeats the purpose of it being in chrome_elf, of course, but I believe it would be safe, and is non-intrusive.

We updated Chrome over the weekend and now are forcing all of our users in our worldwide company to use IE for the time being pending resolution.  This means we're adding well over 100 users to the complaint list.  We're using SRP with certificates just because other programs are using non-compliant folders, even temp folders, for which certificate-based SRP is mandatory.  There's no way we can disable the SRP functionality without compromising our system.  Please get this fixed as soon as possible.  Thank you.

John Babbitt
Systems Administrator
Ashland Partners & Company LLP

Penny, Ananta, Will: could you please take a look at https://codereview.chromium.org/2428703002 ?

Thanks for investigation.

We're going to have M54 Stable Release on Wednesday (OCT 19).Please ensure to land the fix today before 8.00 PM to have enough baking time in trunk. If all looks good CL can be merged in time for tomorrow's stable cut at 4 PM (OCT 18).

Ligi, Scott has just now triggered the commit queue.  Hopefully the CL will land before 8pm... and be part of the CLs chosen for the canary.  If not, we might want to delay the canary build by a couple of hours to ensure it includes this fix.  Or we can merge/respin in the morning... up to you and TE!  :)

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

commit f3a5670dd8d42b045d31625dde4a2561b471138f
Author: scottmg <scottmg@chromium.org>
Date: Tue Oct 18 01:01:21 2016

Signal chrome_elf to initialize crash reporting, rather than doing it in DllMain

Currently, initialization crash reporting indirectly calls
CreateProcess() from chrome_elf's DllMain(), which causes deadlock in
some configurations (showing up in M54).

Instead, signal to chrome_elf that it should initialize crash reporting
later in WinMain(). This means we lose a little coverage that we were
hoping to gain from the move to chrome_elf, but a localized fix is
required for merge to stable.

Follow up bug is  https://crbug.com/656800 .

BUG= 655788 ,  656800 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win10_chromium_x64_rel_ng
TEST=enforce certificate rules per https://bugs.chromium.org/p/chromium/issues/detail?id=655788#c57 and then try to launch chrome.

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

[modify] https://crrev.com/f3a5670dd8d42b045d31625dde4a2561b471138f/chrome/app/chrome_exe_main_win.cc
[modify] https://crrev.com/f3a5670dd8d42b045d31625dde4a2561b471138f/chrome_elf/chrome_elf.def
[modify] https://crrev.com/f3a5670dd8d42b045d31625dde4a2561b471138f/chrome_elf/chrome_elf_main.cc
[modify] https://crrev.com/f3a5670dd8d42b045d31625dde4a2561b471138f/chrome_elf/chrome_elf_main.h

Merge Approved for 54

As per Comment#65 bisect provided by TE.Hence removing the Needs-Bisect label.

Thank You!

Apparently we missed Canary by two CLs. (CL landed as 425840, current canaries are 425838)

Is there another Canary before Stable cutoff?

Next canary is scheduled at 8.00 pm PST today, still waiting for one more bug fix &  planning to manually trigger as soon as its in.

OK, so that's a "no" then, right based on https://bugs.chromium.org/p/chromium/issues/detail?id=655788#c75 ?

Are we willing to delay stable for this to bake in Canary, or should I merge to 54 now?

I would like Richard to take the final call for merge. Just curious, will the revert be easy and str incase of any breakage?

Yes we are willing to delay Stable a day to get this fix in and let it bake in Canary.  Please merge when your ready, the earlier we can test it, the better.

Yes, the change is small and localized, so it should be straightforward to merge and/or revert.

OK, I guess please update us here when Canary is kicked and when we can expect to see that roll out so we can confirm we're seeing crash reports in Canary (that's really all we need to confirm on Canary).

Thanks

Not to take away from your efforts to get this fix in place, but could a chrome dev please explain why this was a problem in the first place? I dont quite understand how or why something that was related to SRP and certificate enforcement prevented chrome from launching when SRP itself never reported it was blocking anything nor how a certificate enforcement was blocking something that was otherwise already allowed to run.

Thanks,

Brian

Discussed with Richard, as per #86 can we get the patch merged to M54.

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

commit 0aa889d7b478450c71133081216ccefbd645ba30
Author: Scott Graham <scottmg@chromium.org>
Date: Tue Oct 18 23:13:23 2016

Signal chrome_elf to initialize crash reporting, rather than doing it in DllMain

Currently, initialization crash reporting indirectly calls
CreateProcess() from chrome_elf's DllMain(), which causes deadlock in
some configurations (showing up in M54).

Instead, signal to chrome_elf that it should initialize crash reporting
later in WinMain(). This means we lose a little coverage that we were
hoping to gain from the move to chrome_elf, but a localized fix is
required for merge to stable.

Follow up bug is  https://crbug.com/656800 .

BUG= 655788 ,  656800 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win10_chromium_x64_rel_ng
TEST=enforce certificate rules per https://bugs.chromium.org/p/chromium/issues/detail?id=655788#c57 and then try to launch chrome.

Review-Url: https://codereview.chromium.org/2428703002
Cr-Commit-Position: refs/heads/master@{#425840}
(cherry picked from commit f3a5670dd8d42b045d31625dde4a2561b471138f)

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

Cr-Commit-Position: refs/branch-heads/2840@{#754}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/0aa889d7b478450c71133081216ccefbd645ba30/chrome/app/chrome_exe_main_win.cc
[modify] https://crrev.com/0aa889d7b478450c71133081216ccefbd645ba30/chrome_elf/chrome_elf.def
[modify] https://crrev.com/0aa889d7b478450c71133081216ccefbd645ba30/chrome_elf/chrome_elf_main.cc
[modify] https://crrev.com/0aa889d7b478450c71133081216ccefbd645ba30/chrome_elf/chrome_elf_main.h

 Issue 656979  has been merged into this issue.

 Issue 656556  has been merged into this issue.

Verified this issue on Windows-10 by following steps mentioned in the comment #57. By enabling "Enforce certificate rules" from enforcement properties the chrome #54.0.2840.59 got failed, But after installation of chrome latest M54 #54.0.2840.68 the browser launched as expected. Considering the issue got fixed and marking it as verified from Chrome-TE end.

Thanks!

Deleted: 655788.mp4 787 KB

	655788.mp4 787 KB View Download

Awesome news! Thank you so much everyone for working so quickly to get a resolution pushed out.
Is this new version available on the public google chrome installs or is this a chrome canary version?

I just checked. The public chrome isn't updated yet. But canary is working perfectly now. :-)

Anyone know when this will land on the public version?

-Charles

Tried to Enforce the Certificate and that did not fix the issue for us. We currently do not have any SRP's set up but still encounter the issue. I am able to launch Canary 56.0.2894.0 without any issues.

Thanks for confirming brajkumar, will mark fixed.

(Thanks to forshaw, pbommana, pennymac, ananta, and wfh for helping out.)

When will the public Chrome fix be released?  Our users are eagerly waiting to get back to Chrome after switching back to IE.  Thanks, and good work!

We should also merge to 55 pending figuring out something better.

Confirmed that Canary 56 works with SRP and enforce certs.

Is there any update on this. I have 500 users breathing down our IT's neck.

The fix will be available in upcoming stable release, tentatively tomorrow Thursday(10/20).

Your change meets the bar and is auto-approved for M55 (branch: 2883)

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

commit ee677d8266a689f574f3d59ce10077c84dedb6a5
Author: Scott Graham <scottmg@chromium.org>
Date: Wed Oct 19 22:26:09 2016

Signal chrome_elf to initialize crash reporting, rather than doing it in DllMain

Currently, initialization crash reporting indirectly calls
CreateProcess() from chrome_elf's DllMain(), which causes deadlock in
some configurations (showing up in M54).

Instead, signal to chrome_elf that it should initialize crash reporting
later in WinMain(). This means we lose a little coverage that we were
hoping to gain from the move to chrome_elf, but a localized fix is
required for merge to stable.

Follow up bug is  https://crbug.com/656800 .

BUG= 655788 ,  656800 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win10_chromium_x64_rel_ng
TEST=enforce certificate rules per https://bugs.chromium.org/p/chromium/issues/detail?id=655788#c57 and then try to launch chrome.

Review-Url: https://codereview.chromium.org/2428703002
Cr-Commit-Position: refs/heads/master@{#425840}
(cherry picked from commit f3a5670dd8d42b045d31625dde4a2561b471138f)

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

Cr-Commit-Position: refs/branch-heads/2883@{#198}
Cr-Branched-From: 614d31daee2f61b0180df403a8ad43f20b9f6dd7-refs/heads/master@{#423768}

[modify] https://crrev.com/ee677d8266a689f574f3d59ce10077c84dedb6a5/chrome/app/chrome_exe_main_win.cc
[modify] https://crrev.com/ee677d8266a689f574f3d59ce10077c84dedb6a5/chrome_elf/chrome_elf.def
[modify] https://crrev.com/ee677d8266a689f574f3d59ce10077c84dedb6a5/chrome_elf/chrome_elf_main.cc
[modify] https://crrev.com/ee677d8266a689f574f3d59ce10077c84dedb6a5/chrome_elf/chrome_elf_main.h

Is the 'Stable Release' now available via the Public Installer? I attempted an update and am still experiencing the issue on multiple systems.

I've been constantly checking https://googlechromereleases.blogspot.com/, but it hasn't been updated yet.

Issue is Fixed. 54.0.2840.71 - Was pushed out today. 

Google has updated to the latest version and I can confirm the issue has been fixed. 

New Version has been released v 54.0.2840.71 https://enterprise.google.com/chrome/chrome-browser/

Updated affected system and verified working with SRP

Thanks Chrome Devs!

Yes it is working again. Thanks guys. But still crashes a lot. It crashed three times in five minutes.

It is working! No crashes until now.

54.0.2840.71 corrected the issue for me.

▀█▀─█─█─▄▀▄─█▄─█─█─▄▀───█─█─▄▀▀▄─█──█──
─█──█▀█─█▀█─█─▀█─█▀▄─────█──█──█─█──█──
─▀──▀─▀─▀─▀─▀──▀─▀──▀────▀───▀▀───▀▀───

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

commit ee677d8266a689f574f3d59ce10077c84dedb6a5
Author: Scott Graham <scottmg@chromium.org>
Date: Wed Oct 19 22:26:09 2016

Signal chrome_elf to initialize crash reporting, rather than doing it in DllMain

Currently, initialization crash reporting indirectly calls
CreateProcess() from chrome_elf's DllMain(), which causes deadlock in
some configurations (showing up in M54).

Instead, signal to chrome_elf that it should initialize crash reporting
later in WinMain(). This means we lose a little coverage that we were
hoping to gain from the move to chrome_elf, but a localized fix is
required for merge to stable.

Follow up bug is  https://crbug.com/656800 .

BUG= 655788 ,  656800 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win10_chromium_x64_rel_ng
TEST=enforce certificate rules per https://bugs.chromium.org/p/chromium/issues/detail?id=655788#c57 and then try to launch chrome.

Review-Url: https://codereview.chromium.org/2428703002
Cr-Commit-Position: refs/heads/master@{#425840}
(cherry picked from commit f3a5670dd8d42b045d31625dde4a2561b471138f)

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

Cr-Commit-Position: refs/branch-heads/2883@{#198}
Cr-Branched-From: 614d31daee2f61b0180df403a8ad43f20b9f6dd7-refs/heads/master@{#423768}

[modify] https://crrev.com/ee677d8266a689f574f3d59ce10077c84dedb6a5/chrome/app/chrome_exe_main_win.cc
[modify] https://crrev.com/ee677d8266a689f574f3d59ce10077c84dedb6a5/chrome_elf/chrome_elf.def
[modify] https://crrev.com/ee677d8266a689f574f3d59ce10077c84dedb6a5/chrome_elf/chrome_elf_main.cc
[modify] https://crrev.com/ee677d8266a689f574f3d59ce10077c84dedb6a5/chrome_elf/chrome_elf_main.h

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

commit 0aa889d7b478450c71133081216ccefbd645ba30
Author: Scott Graham <scottmg@chromium.org>
Date: Tue Oct 18 23:13:23 2016

Signal chrome_elf to initialize crash reporting, rather than doing it in DllMain

Currently, initialization crash reporting indirectly calls
CreateProcess() from chrome_elf's DllMain(), which causes deadlock in
some configurations (showing up in M54).

Instead, signal to chrome_elf that it should initialize crash reporting
later in WinMain(). This means we lose a little coverage that we were
hoping to gain from the move to chrome_elf, but a localized fix is
required for merge to stable.

Follow up bug is  https://crbug.com/656800 .

BUG= 655788 ,  656800 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win10_chromium_x64_rel_ng
TEST=enforce certificate rules per https://bugs.chromium.org/p/chromium/issues/detail?id=655788#c57 and then try to launch chrome.

Review-Url: https://codereview.chromium.org/2428703002
Cr-Commit-Position: refs/heads/master@{#425840}
(cherry picked from commit f3a5670dd8d42b045d31625dde4a2561b471138f)

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

Cr-Commit-Position: refs/branch-heads/2840@{#754}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/0aa889d7b478450c71133081216ccefbd645ba30/chrome/app/chrome_exe_main_win.cc
[modify] https://crrev.com/0aa889d7b478450c71133081216ccefbd645ba30/chrome_elf/chrome_elf.def
[modify] https://crrev.com/0aa889d7b478450c71133081216ccefbd645ba30/chrome_elf/chrome_elf_main.cc
[modify] https://crrev.com/0aa889d7b478450c71133081216ccefbd645ba30/chrome_elf/chrome_elf_main.h

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

commit 7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a
Author: scottmg <scottmg@chromium.org>
Date: Fri Nov 04 19:51:28 2016

Update Crashpad to b47bf6c250c6b825dee1c5fbad9152c2c962e828

2d87606bb56b win: Start crashpad_handler by inheriting connection data
             to it
cc0b7deef27d Get VS2013 compilation working again for Crashpad
f735d050c487 Port the util library to Linux
e956a8252fc1 Port the util library to Android
d5a759c900ae Update mini_chromium to 8e8d3cc9a245
d1aafe78ea46 Port the test library and crashpad_test_test to
             Linux/Android
b978b03fa188 Port most of crashpad_util_test to Linux/Android
c2814e251912 Don't throttle explicitly requested uploads
fd751f4708cc Correct StringToUnsignedInt[64]()
e7bd798af438 Update build/test and status documentation to reflect
             Android
e616638c9d87 Replace Rietveld with Gerrit in the developer documentation
47a830465f78 Port the minidump library to Android and ARM
88e3b6b02271 Omit platform-specific assembler source from builds as
             needed
96b9857aceb4 Fix the crashpad_minidump library for 32-bit ARM
c55e49c13d5c doc: Remove errant parenthesis
76ef9b5c2b00 win: Address failure-to-start-handler case for async
             startup
55ba6b67801b break; after handling --initial-client-data on command line
bb7d249d65a1 Partially port the crashpad_client library to Linux/Android
375082098deb mac: Fix tests on 10.12.1
c4cdec3d72a2 Handle non-crashing cases for server failure to start
b47bf6c250c6 Fix tests when running on Win10

Also update .GN files, and adapt Chrome side code for changes in API.
Only the first three files are modified here, the rest are unmodified
from upstream Crashpad repo.

This does not yet make handler startup asynchronous, or move it back to
chrome_elf. Those will be done in smaller followup CLs.

R=mark@chromium.org
TBR=rsesek
BUG= 660955 ,565063, 656800 , 655788 

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

[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/build/secondary/third_party/crashpad/crashpad/util/BUILD.gn
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/components/crash/content/app/crashpad_mac.mm
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/components/crash/content/app/crashpad_win.cc
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/README.chromium
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/DEPS
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/client/client.gyp
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/client/crashpad_client.h
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/client/crashpad_client_mac.cc
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/client/crashpad_client_win.cc
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/client/crashpad_client_win_test.cc
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/client/crashpad_info.cc
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/doc/developing.ad
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/doc/status.ad
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/handler/crash_report_upload_thread.cc
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/handler/crashpad_handler.ad
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/handler/handler.gyp
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/handler/handler_main.cc
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/handler/win/crash_other_program.cc
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/handler/win/crashy_test_program.cc
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/handler/win/crashy_test_z7_loader.cc
[add] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/handler/win/fake_handler_that_crashes_at_startup.cc
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/handler/win/hanging_program.cc
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/handler/win/self_destroying_test_program.cc
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/minidump/minidump_misc_info_writer.cc
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/snapshot/mac/mach_o_image_annotations_reader_test.cc
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/snapshot/mac/mach_o_image_reader.cc
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/snapshot/mac/mach_o_image_reader.h
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/snapshot/mac/process_types/crashpad_info.proctype
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/snapshot/module_snapshot.h
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/snapshot/win/crashpad_snapshot_test_crashing_child.cc
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/snapshot/win/crashpad_snapshot_test_dump_without_crashing.cc
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/snapshot/win/end_to_end_test.py
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/snapshot/win/exception_snapshot_win_test.cc
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/test/multiprocess_exec_posix.cc
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/test/multiprocess_exec_test_child.cc
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/test/multiprocess_posix_test.cc
[add] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/test/paths_linux.cc
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/test/paths_mac.cc
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/test/paths_win.cc
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/test/scoped_temp_dir_posix.cc
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/test/test.gyp
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/test/win/win_child_process.cc
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/tools/mac/run_with_crashpad.cc
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/util/file/file_writer.cc
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/util/misc/clock_test.cc
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/util/misc/metrics.cc
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/util/misc/uuid.cc
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/util/numeric/checked_address_range_test.cc
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/util/posix/close_multiple.cc
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/util/posix/drop_privileges.cc
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/util/posix/process_info.h
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/util/posix/process_info_test.cc
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/util/posix/symbolic_constants_posix.cc
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/util/posix/symbolic_constants_posix_test.cc
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/util/stdlib/string_number_conversion.cc
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/util/stdlib/string_number_conversion.h
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/util/string/split_string.cc
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/util/string/split_string.h
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/util/string/split_string_test.cc
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/util/thread/thread_log_messages.cc
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/util/util.gyp
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/util/util_test.gyp
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/util/win/exception_handler_server.cc
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/util/win/exception_handler_server.h
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/util/win/exception_handler_server_test.cc
[add] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/util/win/initial_client_data.cc
[add] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/util/win/initial_client_data.h
[add] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/util/win/initial_client_data_test.cc
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/util/win/registration_protocol_win.cc
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/util/win/registration_protocol_win.h
[modify] https://crrev.com/7b9234c4b2a7f4f4fa84c80ecb22d41c54899f6a/third_party/crashpad/crashpad/util/win/termination_codes.h

The following revision refers to this bug:
  https://chromium.googlesource.com/crashpad/crashpad.git/+/5b83e58771e25f7e7c8c84e854defa8f464457a2

commit 5b83e58771e25f7e7c8c84e854defa8f464457a2
Author: Scott Graham <scottmg@chromium.org>
Date: Wed Dec 07 19:35:07 2016

win: Remove use of rpcrt4 and advapi32 from some util code

ConvertStringSecurityDescriptorToSecurityDescriptor() is used when
creating the initial connection pipe. Because this is done from inside
DllMain(), we cannot use advapi32 (where this function is). Instead,
save the binary representation of the self-relative SECURITY_DESCRIPTOR.
It is conceivable that this could change, but unlikely as this is the
same blob that would be stored on a file in NTFS.

Another potential approach would be to not make the pipe available to
all integrity levels here, and instead modify the Chromium sandbox code
to allow a specific pipe name prefix that would have to correspond with
the pipe name that Crashpad creates.

Similarly, UuidCreate() (used when initializing the database) is in a
DLL that can't be loaded early, so use the Linux/Android implementation
on Windows too.

R=mark@chromium.org
BUG= chromium:655788 , chromium:656800 

Change-Id: I434f8e96fc275fc30d0a31208b025bfc08595ff9
Reviewed-on: https://chromium-review.googlesource.com/417223
Reviewed-by: Mark Mentovai <mark@chromium.org>

[modify] https://crrev.com/5b83e58771e25f7e7c8c84e854defa8f464457a2/util/misc/uuid.cc
[modify] https://crrev.com/5b83e58771e25f7e7c8c84e854defa8f464457a2/util/util.gyp
[modify] https://crrev.com/5b83e58771e25f7e7c8c84e854defa8f464457a2/util/util_test.gyp
[modify] https://crrev.com/5b83e58771e25f7e7c8c84e854defa8f464457a2/util/win/registration_protocol_win.cc
[modify] https://crrev.com/5b83e58771e25f7e7c8c84e854defa8f464457a2/util/win/registration_protocol_win.h
[add] https://crrev.com/5b83e58771e25f7e7c8c84e854defa8f464457a2/util/win/registration_protocol_win_test.cc

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

commit f94dd14c45ead99d84ec84bc4460ff470d83fc38
Author: Scott Graham <scottmg@chromium.org>
Date: Wed Dec 07 21:25:02 2016

win: fix SECURITY_DESCRIPTOR builder on vs2013

After https://chromium.googlesource.com/crashpad/crashpad/+/5b83e587.

R=mark@chromium.org
BUG= chromium:655788 , chromium:656800 

Change-Id: Ic33b9daedc340bfce3cc4ddde4eb4c93f68e7ad0
Reviewed-on: https://chromium-review.googlesource.com/417412
Reviewed-by: Mark Mentovai <mark@chromium.org>

[modify] https://crrev.com/f94dd14c45ead99d84ec84bc4460ff470d83fc38/util/win/registration_protocol_win.cc

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

commit be0cfa14d77c72864a74d2bcc7910b0b31b7eecb
Author: scottmg <scottmg@chromium.org>
Date: Fri Dec 16 21:00:59 2016

Make Crashpad start asynchronous, and move back to chrome_elf

Crashpad initialization has been reworked to support an asynchronous
mode where StartHandler() only calls CreateThread() and does not
synchronize with that thread, making it safe to use in DllMain().

So, we can now move it back into chrome_elf to catch earlier crashes.

We block much later now in browser startup, before a renderer (i.e.
another client that would connect to the handler) will be started. This
should not be strictly necessary, but is slightly more conservative as a
first pass. This allows for error reporting, and prevents log spew from
each renderer that starts up and tries to connect to a nonexistent
handler. Also added is a UMA timer to see how long we're blocking
startup for by joining with the background thread.

This includes an effective revert of
https://chromium.googlesource.com/chromium/src/+/f3a5670dd8d42b045d31625dde4a2561b471138f
.

BUG= 655788 , 656800 ,565063
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win10_chromium_x64_rel_ng

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

[modify] https://crrev.com/be0cfa14d77c72864a74d2bcc7910b0b31b7eecb/chrome/app/chrome_exe_main_win.cc
[modify] https://crrev.com/be0cfa14d77c72864a74d2bcc7910b0b31b7eecb/chrome/browser/chrome_browser_main.cc
[modify] https://crrev.com/be0cfa14d77c72864a74d2bcc7910b0b31b7eecb/chrome_elf/chrome_elf.def
[modify] https://crrev.com/be0cfa14d77c72864a74d2bcc7910b0b31b7eecb/chrome_elf/chrome_elf_main.cc
[modify] https://crrev.com/be0cfa14d77c72864a74d2bcc7910b0b31b7eecb/chrome_elf/chrome_elf_main.h
[modify] https://crrev.com/be0cfa14d77c72864a74d2bcc7910b0b31b7eecb/components/crash/content/app/crashpad.cc
[modify] https://crrev.com/be0cfa14d77c72864a74d2bcc7910b0b31b7eecb/components/crash/content/app/crashpad.h
[modify] https://crrev.com/be0cfa14d77c72864a74d2bcc7910b0b31b7eecb/components/crash/content/app/crashpad_win.cc
[modify] https://crrev.com/be0cfa14d77c72864a74d2bcc7910b0b31b7eecb/tools/metrics/histograms/histograms.xml