Issue metadata
Sign in to add a comment
|
54.0.2840.59 causes invisible window when used with SRP |
|
|||||||||||||||||||||||||
| Reported by brian.c....@gmail.com, Oct 13 2016 | Back to list | ||||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36 Edge/12.10240 Steps to reproduce the problem: 1. need to have group policy with software restrictions in place applied to a non-administrator account. 2. With that user logged in launch chrome.exe 3. No visible window ever appears What is the expected behavior? expect to have chrome window visible after launching the executable What went wrong? 1. non admin account with software restriction policy implemented in Group Policy (that allows all c:\Program Files (x86)\ file path) launch chrome 2. no chrome window is visible although chrome *32.exe visible under the user id in windows task manager 3. able to launch chrome with "run as another user" and specify another non-admin account that is governed by SRP and it lunches successful. If you log out of windows and login again as the 2nd user and launch chrome they now get the invisible window problem from that point forward. Crashed report ID: no crash - it runs in the background without a visible window How much crashed? Whole browser Is it a problem with a plugin? No Did this work before? Yes last version I was able to check 53.0.2785.143 Chrome version: 54.0.2840.59 Channel: n/a OS Version: 10.0 Flash Version: Shockwave Flash 20.0 r0 this was working as expected until the release of 54.0.2840.59 started applying when chrome updated itself today. As every one of the pcs in my organization updates to this version, they are all exhibiting the same invisible browser window problem. This has been posted in the chrome forums here https://productforums.google.com/forum/#!topic/chrome/lJ307khRyc4;context-place=forum/chrome
,
Oct 13 2016
Same issue here. SRP in place. Removing SRP is not an option as it opens up machines to malware. Investigating still...
,
Oct 13 2016
Same issue here, we are using SRP.
,
Oct 13 2016
Us too. We downgraded to 53 for the time being.
,
Oct 14 2016
I've narrowed it down to the "Enforce certificate rules". If it's enabled, chrome won't run. Disabling it allows chrome to run with srp/basic user. This really isn't an option while using srp. I've tried to add the cert rule, and trusted publishers, but still isn't working.
,
Oct 14 2016
Same here. I've added both certs (2015 & 2018 exp) attached to the chrome executable to no avail. Not sure what else to try, but taking a break till the morning.
,
Oct 14 2016
Confirmed here.
,
Oct 14 2016
Confirmed the same error yesterday. Disabling SRP is out of the question. Hoping for a quick resolution.
,
Oct 14 2016
Same error here. SRP and certs. My solution until fix: FireFox . . .
,
Oct 14 2016
same problem here. Hope to see a fix soon
,
Oct 14 2016
Same issue here. Breaks when enforce certificate rules is enabled in policy, even when no rules are in place to block anything. Adding certificate rules has no effect. Please help!
,
Oct 14 2016
Same issue with SRP and latest chrome version
,
Oct 14 2016
Same issue. Only way currently around this is to install an old version of Google Chrome.
,
Oct 14 2016
We are facing the same issue. Seems everyone is migrating to IE or Firefox so that we can continue working.
,
Oct 14 2016
Would love if someone could post a link to the old 53 version so I can downgrade.
,
Oct 14 2016
Not endorsing or in any way encouraging you to use this site. But I did. http://www.slimjet.com/chrome/google-chrome-old-version.php
,
Oct 14 2016
Same issue here. Update to version 54. There is no indication in Event Viewer that SRP is blocking anything.
,
Oct 14 2016
For anyone looking for the previous version... http://www.chrome-portable.com/index.php/google-chrome-offline-installer
,
Oct 14 2016
Same issue with standard SRP and version 54. Nothing in verbose logging of SRP showing blocked.
,
Oct 14 2016
RESOLUTION: CHANGE THE FOLLOWING REGISTRY KEY 1 TO 0: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\codeidentifiers
,
Oct 14 2016
Not until I know exactly what that does. Can you provide any context?
,
Oct 14 2016
This 1 to 0 regkey change would likely disable SRP temporarily until GPO reapplies it.
,
Oct 14 2016
The above "fix" is just disabling SRP locally, wouldn't consider this a resolution.
,
Oct 14 2016
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.
,
Oct 14 2016
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.
,
Oct 14 2016
Sorry, guys, i wrote RESOLUTION, but as everyone sad, is a WORKAROUND
,
Oct 14 2016
Same here with SRP enabled it won't run. Had to force everyone back to 53 for now.
,
Oct 14 2016
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.
,
Oct 14 2016
Same here, I am losing clients by the dozens and HD is ringing off the hook. Please address ASAP Google!!!!
,
Oct 14 2016
This is also happening in our organization with Software Restriction Policies enabled. Was working fine with previous 53.xxx versions.
,
Oct 14 2016
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.
,
Oct 14 2016
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).
,
Oct 14 2016
Same issue, please fix, thanks!
,
Oct 14 2016
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.
,
Oct 14 2016
,
Oct 14 2016
,
Oct 14 2016
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.
,
Oct 14 2016
Applying block for 54 to make sure this is evaluated before the release.
,
Oct 14 2016
,
Oct 14 2016
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.
,
Oct 17 2016
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.
,
Oct 17 2016
Same problem here. But won't start even with "Ignore certificate rules". I have no temporary workaround. Rolling back to 53
,
Oct 17 2016
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!
,
Oct 17 2016
Folks, the setting "enforce certificate rules" disabled solves it, while it has no negative side effect - certificate rules are enforced neverthelesss. Try it.
,
Oct 17 2016
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.
,
Oct 17 2016
Tentatively assigning Robert, re-assign if there's a more accurate fit.
,
Oct 17 2016
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.
,
Oct 17 2016
,
Oct 17 2016
A first step would be to figure out when this started happening.
,
Oct 17 2016
Per offline chat with georgesak@, blumberg@ is already looking into this.
,
Oct 17 2016
Scot, As noted in this thread, this started happening with the update to v54. v53 does not experience this issue.
,
Oct 17 2016
I recommend getting a repro, and then doing a bisect. If you need help let me know.
,
Oct 17 2016
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).
,
Oct 17 2016
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.
,
Oct 17 2016
#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.
,
Oct 17 2016
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.
,
Oct 17 2016
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]
,
Oct 17 2016
,
Oct 17 2016
,
Oct 17 2016
,
Oct 17 2016
wfh points out that CreateProcess in DllMain is probably sadness.
,
Oct 17 2016
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
,
Oct 17 2016
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.
,
Oct 17 2016
,
Oct 17 2016
Scott, could you please confirm whether issue: 656201 is the same as this bug?
,
Oct 17 2016
Not certain, but probably the same issue, yes.
,
Oct 17 2016
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.
,
Oct 17 2016
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.
,
Oct 17 2016
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.
,
Oct 17 2016
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
,
Oct 17 2016
Penny, Ananta, Will: could you please take a look at https://codereview.chromium.org/2428703002 ?
,
Oct 17 2016
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).
,
Oct 17 2016
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! :)
,
Oct 18 2016
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
,
Oct 18 2016
,
Oct 18 2016
Merge Approved for 54
,
Oct 18 2016
As per Comment#65 bisect provided by TE.Hence removing the Needs-Bisect label. Thank You!
,
Oct 18 2016
Apparently we missed Canary by two CLs. (CL landed as 425840, current canaries are 425838) Is there another Canary before Stable cutoff?
,
Oct 18 2016
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.
,
Oct 18 2016
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?
,
Oct 18 2016
I would like Richard to take the final call for merge. Just curious, will the revert be easy and str incase of any breakage?
,
Oct 18 2016
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.
,
Oct 18 2016
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
,
Oct 18 2016
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
,
Oct 18 2016
Discussed with Richard, as per #86 can we get the patch merged to M54.
,
Oct 18 2016
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
,
Oct 19 2016
Issue 656979 has been merged into this issue.
,
Oct 19 2016
,
Oct 19 2016
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!
,
Oct 19 2016
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?
,
Oct 19 2016
I just checked. The public chrome isn't updated yet. But canary is working perfectly now. :-)
,
Oct 19 2016
Anyone know when this will land on the public version? -Charles
,
Oct 19 2016
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.
,
Oct 19 2016
Thanks for confirming brajkumar, will mark fixed. (Thanks to forshaw, pbommana, pennymac, ananta, and wfh for helping out.)
,
Oct 19 2016
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!
,
Oct 19 2016
We should also merge to 55 pending figuring out something better.
,
Oct 19 2016
Confirmed that Canary 56 works with SRP and enforce certs.
,
Oct 19 2016
Is there any update on this. I have 500 users breathing down our IT's neck.
,
Oct 19 2016
The fix will be available in upcoming stable release, tentatively tomorrow Thursday(10/20).
,
Oct 19 2016
Your change meets the bar and is auto-approved for M55 (branch: 2883)
,
Oct 19 2016
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
,
Oct 20 2016
Is the 'Stable Release' now available via the Public Installer? I attempted an update and am still experiencing the issue on multiple systems.
,
Oct 20 2016
I've been constantly checking https://googlechromereleases.blogspot.com/, but it hasn't been updated yet.
,
Oct 20 2016
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.
,
Oct 20 2016
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
,
Oct 20 2016
Thanks Chrome Devs!
,
Oct 21 2016
Yes it is working again. Thanks guys. But still crashes a lot. It crashed three times in five minutes.
,
Oct 21 2016
It is working! No crashes until now.
,
Oct 21 2016
54.0.2840.71 corrected the issue for me. ▀█▀─█─█─▄▀▄─█▄─█─█─▄▀───█─█─▄▀▀▄─█──█── ─█──█▀█─█▀█─█─▀█─█▀▄─────█──█──█─█──█── ─▀──▀─▀─▀─▀─▀──▀─▀──▀────▀───▀▀───▀▀───
,
Oct 27 2016
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
,
Oct 27 2016
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
,
Nov 4 2016
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
,
Dec 7 2016
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
,
Dec 7 2016
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
,
Dec 16 2016
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 |
|||||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||||
Comment 1 by vallam...@gmail.com
, Oct 13 2016