Could you please provide the crash id?

Hello!
id - 2694efe6-42e0-4edb-a711-aea86cc1804d
Thank you very much. 

Thanks for the response.

@sa.yunchic-- Please provide us the serverID ..which is next to the crash id.

Thanks!

Crash ID 61837770-c62b-4539-96e2-77f816fa0f1d (Server ID: e4d9e13690000000)
That my crash id for that issue.
Thank you very much!

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

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

Considering this is a regression in M58. There are several reports in older chrome versions, but same reports for M58+ versions.

Crash rate is within the threshold but can spike in Stable Channel. Please try to have a fix before M59 hits stable.

Link to the builds which introduced the crash.
==============================================
https://crash.corp.google.com/browse?q=custom_data.ChromeCrashProto.ptype%3D%27browser%27%20AND%20custom_data.ChromeCrashProto.magic_signature_1.name%3D%27content%3A%3ADesktopCaptureDevice%3A%3ACore%3A%3AOnCaptureResult%27&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=%3D#samplereports:5,productversion:1000

Possible suspect
================
https://chromium.googlesource.com/external/webrtc/trunk/webrtc.git/+/2765497efbc05098dd0278b48000beed4c0159b2

Assigning to the CL owner for updates.

Thank you for reporting the bug.
This was a code defect in the capturer. It has been fixed by change https://chromium.googlesource.com/external/webrtc/trunk/webrtc.git/+/1093cc8bc07afe0c6881bb762e0b30fcc729edea, and merged to Chromium by change https://chromium.googlesource.com/chromium/src/+/282d60fedefa2a065674798acbf1af61c127c8b6%5E%21/#F0.
So the fix took effect in 58.0.3029.81, but not 68.
https://chromium.googlesource.com/chromium/src/+log/58.0.3029.68..58.0.3029.81?pretty=fuller&n=10000

Please kindly update your browser to the latest beta channel to see if this issue still happens.

The issue doesn't reproduce in 58.0.3029.81 
Thank you very much! 

Sorry but we still have crash in case of we set first monitor as primary and try to share window application. 
http://take.ms/vUjaZ 

Crash ID 7cfa854e-ae41-44a2-b80a-0e7cdf80972b (Server ID: 857b49d640000000)

Crash report captured on Thursday, April 20, 2017 at 7:18:32 PM, uploaded on Thursday, April 20, 2017 at 7:18:37 PM

Beta version 58.0.3029.81

Thank you for sharing the detail information with us. I am looking at it now.

Yes, I confirmed this is a code defect in WebRTC (though does not really relate to the DirectX capturer), which has been introduced about 11 months ago :(
I am preparing a fix, this change is expected to be merged to M58.

Sorry, I have not made it very clear. The reason of two crashes are different:
The original one is triggered by a code defect in DirectX capturer (ScreenCapturerWinDirectx and its related components), which has been fixed by the changes I have mentioned above.

The crash mentioned in #c11 is triggered by window capturer on windows (WindowCapturerWin).

Change https://codereview.chromium.org/2835553002/ needs to be merged to both M58 and M59 of WebRTC.

This bug requires manual review: Only 4 days from stable, we might already have a stable candidate build
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

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

sa.yunchic@, could you please test/verify this bug on latest canary (https://www.google.com/chrome/browser/canary.html) and see fix is working?

zijiehe@, will change listed at #15 be a safe merge to M58? Please note that M58 is already in stable so we can take this fix in only if change is well baked/verified in Canary absolutely safe to merge.

Your change meets the bar and is auto-approved for M59. Please go ahead and merge the CL to branch 3071 manually. Please contact milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), gkihumba@(ChromeOS), Abdul Syed@(Desktop)

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

Please merge your change to M59 branch #3071 latest before 4:00 PM PT, Monday (04/24) so we can take it for next week last M59 dev release. Thank you.

Merging to WebRTC/M59 has been done by change https://codereview.webrtc.org/2834923002. Merge-Approved-59 has been removed.

This change is a very safe change, and should address the issue mentioned in #c11. But since this code defect exists for almost one year, and it should only happen with a very limited possibility. If we cannot catch M58, I think it's still OK to ignore it. -- This change merges to WebRTC/M58, so we need an extra change in Chromium to update the DEPS.

Thank you  zijiehe@.
Rejecting merge to M58 based on comment #20 and applying "merge-merged-59" label based on comment #20. 

Thank you Krishna. Mark this issue as fixed.

I had the same issue in Windows 8.1. Is there a chance to get this fixed in Chrome 58. Since it's quite annoying and 59 is more than a month away to be in stable channel.

I concur. Rejecting this for consideration for a patch to 58 is a very bad idea. 

Breaking screen sharing for a large number of users for 5 weeks is not going to go over very well at all. We have just sent out a bulletin to users about the other screen sharing bug with incorrect screen selection. Now we have to do a new one about this. 

It also is not just a functional bug, but a very disruptive full browser crash.  

 Issue 716013  has been merged into this issue.

Krishna, can we take this fix for next M58 stable roll out? Requesting 	zijiehe@ to request a merge if Krishna approves.

alperteke@ and warren.mcdonald@, could you please test the fix on M59 Dev version 59.0.3071.25 or higher please? 

Download location:
https://www.chromium.org/getting-involved/dev-channel

alperteke@ and warren.mcdonald@, could you please test the fix on M59 Beta version 59.0.3071.29 please? 

Download location:
https://www.chromium.org/getting-involved/dev-channel

Yes, I'll test it as soon as I can but I'm away from my 2 monitor setup. Will test early Tuesday morning. 

Thank you  alperteke@.

warren.mcdonald@, Would it be possible for you to test sooner?

Approving merge to M58 branch 3029 (CL: https://codereview.chromium.org/2835553002/ ). Based on internal group chat with zijiehe@, this change is very safe and it won't be worse than current status. Please merge ASAP. Thank you.

Change has been merged to WebRTC/58 with CL https://codereview.webrtc.org/2852793002.

Removing Merge-Approved-58.

Applying "merge-merged-58" label per comment #33 and #34.

I have tested again on 2 machines with dual monitor configurations
 on 59 beta:
1. Recent Win 10 Creators update 1703 Build 15063  
on generic desktop with 19" monitors - I can not reproduce crash over many different scenarios of screen or application window sharing on either monitor.
 
2.Samsung laptop with external 22" monitor Win 10 1607 Build 14393.1066 -
 I can still cause the crash but only with specific scenario of application window on external secondary monitor.
The other common crash scenario, sharing the second screen, is no longer crashing but ineffective. The request to share looks like it tries but fails with no error or crash. 

So this issue is still ongoing, but much better than before and worth pushing to release.   

Thank you for sharing the detail information with us.
- The change to fix a crash when sharing a window has been merged to 58.
- The change to fix a white screen when the secondary monitor is on the left of the primary one is tracked by  http://crbug.com/715689 . The fix has been submitted to M60, and will be merged to M59, while in M58, the new feature to trigger the issue will be disabled.

So you may try canary or wait for M59 beta to see if the issue still happens.

Issue 716894 has been merged into this issue.

Tested the issue on Windows-10 using chrome latest Stable M58-58.0.3029.96 by following steps mentioned in the original comment. 
Observed that: Unable to share the screen-2 screen sharing from hangouts. 

Steps Followed:
1. Open https://hangouts.google.com/ on chrome #58.0.3029.96 and make second monitor as primary. 
2. Start screen-sharing of additional monitor.
Please view the screen cast for reference.

@zijiehe : Could you please let me know if i have missed anything and if possible,Please provide the executable steps of the issue which would help us to verify the issue.

Thanks in Advance.

Deleted: 712615.mp4 10.3 MB

	712615.mp4 10.3 MB View Download

We were no able to reproduce this bug internally, so not blocking Stable release for this issue. Will keep an eye on incoming reports once the build is deployed.

Thank you for fixing. Requesting a postmortem this. Please see go/chrome-postmortems for the process to follow.

Thank you Rajasekhar. The fix has been pushed to WebRTC/M59. Would you mind to try the beta channel with version 59.0.3071.48 or upper (not updated yet) or dev channel to see if this issue still happens?

I have tested the dev and canary channels on my machine, and it worked well. But just in case there are some more edge cases on Rajasekhar's setup.