1347987 - Crash in mfplat.dll@0xe293b

Status: RESOLVED WORKSFORME

(Core :: Audio/Video: Playback, defect, P2)

Description

[Andrew McCreight [:mccr8]]

This bug was filed from the Socorro interface and is 
report bp-62e73537-458c-47f5-be0b-7e4c12170316.
=============================================================

I looked at a few of these, and it looks like we're calling wmf::MFShutdown() and then it ends up in this .dll and crashes. It looks like EME is in the stack, too.

I only see crashes with this signature in the 3-14 and 3-15 Nightly builds. Possible regression range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f9362554866b327700c7f9b18050d7b7eb3d2b23&tochange=6d38ad302429c98115c354d643e81987ecec5d3c

Though I did notice my Windows machine just wanted to update, so maybe a Windows-side change caused this.

Comment 1

[Andrew McCreight [:mccr8]]

Chris, any ideas? Thanks.

Comment 2

[Chris Pearce [:cpearce (Not reading bugmail)]]

I've seen reports like these before, but never got anywhere with them. My current theory is that this is caused by threading issues in Windows Media Foundation. My thoughts were to try initializing Windows Media Foundation on the main thread at startup, and not shut it down until program shutdown, but we'd need some kind of crash guard to ensure that we didn't end up adding a perma-startup crash in case I am wrong and it's actually caused by something else.

Comment 3

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

This is a P1 bug without an assignee. 

P1 are bugs which are being worked on for the current release cycle/iteration/sprint. 

If the bug is not assigned by Monday, 28 August, the bug's priority will be reset to '--'.

Comment 4

[Bulk Bug Changes for mreavy's org]

Mass change P1->P2 to align with new Mozilla triage process

Comment 5

[Blake Wu [:bwu][:blakewu]]

I don't see any new crashes reported for over one month, so close this bug.