Crash in [@ nvd3dumx.dll | IsSupportedWMVDecodeGUID] on Windows 10 with media.ffvpx-hw.enabled
Categories
(Core :: Audio/Video: Playback, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr115 | --- | unaffected |
firefox-esr128 | --- | unaffected |
firefox133 | --- | unaffected |
firefox134 | --- | unaffected |
firefox135 | --- | disabled |
People
(Reporter: mccr8, Assigned: alwu)
References
(Blocks 2 open bugs, Regression)
Details
(Keywords: crash, regression)
Crash Data
Crash report: https://crash-stats.mozilla.org/report/index/532dd8f8-7d8d-476d-90f6-a44120241210
Reason:
EXCEPTION_ACCESS_VIOLATION_READ
Top 9 frames:
0 nvd3dumx.dll nvd3dumx.dll@0x18aa78
1 nvd3dumx.dll nvd3dumx.dll@0x2307ff
2 d3d9.dll IsSupportedWMVDecodeGUID
3 nvd3dumx.dll nvd3dumx.dll@0x21a258
4 nvd3dumx.dll nvd3dumx.dll@0x2e27a8
5 nvd3dumx.dll nvd3dumx.dll@0x23196b
6 nvd3dumx.dll nvd3dumx.dll@0x2ecc47
7 nvd3dumx.dll nvd3dumx.dll@0x2ed3fe
8 nvd3dumx.dll nvd3dumx.dll@0x230c40
The crash spike detector reported this as a Nightly crash spike, and in fact it does seem to have suddenly started happening there.
This is happening inside a Windows graphics driver without any real information about what is happening, but "IsSupportedWMVDecodeGUID" sounds like something related to media playback, and I know we have some new stuff there that might be going through Windows graphics drivers, so I'm filing this here. Looks like it is all Windows 10, from a variety of install times.
Reporter | ||
Comment 1•2 months ago
|
||
[Tracking Requested - why for this release]: Windows 10 crash regression.
Also of note, all of these are crashing on the CanvasRenderer thread. I'm not sure if that's consistent with my theory about this being a media playback problem.
Comment 2•2 months ago
|
||
We're getting to IsSupportedWMVDecodeGUID()
only via stack-scanning. Let me see if I can find some better symbols for this so that we can get a properly unwinded stack.
Reporter | ||
Comment 3•2 months ago
|
||
This first appears in the 20241209143224 build. Nothing in the regression range looks too obviously related.
However, looking at the changes in the build one before that does include some changes that look related to hardware video decoding, in particular bug 1932772.
Reporter | ||
Comment 4•2 months ago
|
||
Ryan noted that it looked like the crashes went away, and bug 1936047 was filed as a regression from bug 1932772, so maybe this is a dupe of that?
Reporter | ||
Comment 5•2 months ago
|
||
Looks like this is set to be Nightly-only, and probably already fixed so clearing the tracking flag.
Comment 6•2 months ago
|
||
I managed to track down the driver and reprocessed the crashes with the unwinding information I could dig out of it. This is the new signature.
Reporter | ||
Comment 7•2 months ago
|
||
Thanks, that's a much better crash stack!
Comment 8•2 months ago
|
||
The fix for bug 1936047 disabled most of the changes for bug 1932772.
This will need be addressed for bug 1936128, so perhaps worth keeping open.
Reporter | ||
Updated•2 months ago
|
Comment 9•2 months ago
|
||
This reminded me that I should really overhaul the Windows graphics drivers' symbol scrapers.
Comment 10•2 months ago
|
||
:alwu, since you are the author of the regressor, bug 1932772, could you take a look?
For more information, please visit BugBot documentation.
Assignee | ||
Updated•2 months ago
|
Description
•