Crash in igd11dxva64.dll | ntdll.dll@0x65e6f or igd11dxva64.dll | kernelbase.dll@0x175fe

RESOLVED FIXED in Firefox 52

Status

()

defect
P1
critical
RESOLVED FIXED
3 years ago
2 years ago

People

(Reporter: mccr8, Assigned: gerald)

Tracking

({crash})

unspecified
mozilla53
Unspecified
Windows 10
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox52 fixed, firefox53 fixed)

Details

(crash signature)

Attachments

(1 attachment)

Reporter

Description

3 years ago
This bug was filed from the Socorro interface and is 
report bp-f304c896-109c-409b-af18-342372161103.
=============================================================

I see a lot of Youtube URLs in these crashes, so I'm going to assume it is a hardware decoding issue like bug 1271525 or bug 1283892. This is Nightly-only.

I'm guessing these two signatures are the same issue, but maybe not. There are about 45 of each in the last week.

Here's a report from the kernelbase version: bp-5fdca4fb-dca9-4b85-8440-f57c32161103
Both signatures are correlated with DXVA2D3D11+.

For igd11dxva64.dll | ntdll.dll@0x65e6f, on 52.0a2 and 53.0a1 over the past week, we have:
 - igd11dxva64.dll
   - 20.19.15.4463: 6
   - 20.19.15.4352: 2
   - 20.19.15.4444: 11
   - 20.19.15.4454: 8
   - 20.19.15.4390: 2
   - 20.19.15.4380: 3
   - 20.19.15.4364: 8
   - 20.19.15.4377: 1
   - 20.19.15.4300: 3
   - 20.19.15.4360: 1

For igd11dxva64.dll | kernelbase.dll@0x175fe, on 52.0a2 and 53.0a1 over the past week, we have:
 - igd11dxva64.dll
   - 20.19.15.4463: 2
   - 20.19.15.4326: 2
   - 20.19.15.4444: 1
   - 20.19.15.4454: 5
   - 20.19.15.4390: 2
   - 20.19.15.4331: 7
   - 20.19.15.4364: 14
   - 20.19.15.4360: 9

It looks like the 32-bit versions of some of these drivers are blocklisted: https://dxr.mozilla.org/mozilla-central/rev/0ddfec7126ec503b54df9c4b7c3b988906f6c882/modules/libpref/init/all.js#362.
I suppose we should blocklist the 64-bit version as well, right?
Should we revisit this blocklist? We have a lot of blocks for 32-bit drivers without equivalents for 64-bit ones.
Flags: needinfo?(gsquelart)
Flags: needinfo?(ajones)
Flags: needinfo?(ajones)
Priority: -- → P1
Assignee

Comment 2

3 years ago
Happy to block these driver versions (and a few more, if I extend the crash report period).

I'd prefer to feed the list based on reports, instead of just copying between 32&64 bits.
Assignee: nobody → gsquelart
Flags: needinfo?(gsquelart)
Comment hidden (mozreview-request)
(In reply to Gerald Squelart [:gerald] from comment #2)
> Happy to block these driver versions (and a few more, if I extend the crash
> report period).
> 
> I'd prefer to feed the list based on reports, instead of just copying
> between 32&64 bits.

Should we re-evaluate the blocklist actively, instead of waiting for bug reports, now that we've had D3D11 on release for a while? (I think the original blocklist was built on beta, right?). On release we have a larger and more diverse population, so we might be hitting crashes with driver versions that on beta nobody had.

E.g. for igd10iumd32.dll (and igd10iumd64.dll), we have a bunch of 9.17.* (Windows 8, Direct X 11.0, according to http://www.intel.com/content/www/us/en/support/graphics-drivers/000005654.html) that we are not blocking but that might be causing crashes: https://crash-stats.mozilla.com/search/?signature=~igd10umd32.dll&app_notes=~DXVA2D3D11%2B&product=Firefox&date=%3E%3D2016-11-17T11%3A03%3A00.000Z&date=%3C2016-11-24T11%3A03%3A00.000Z&_sort=-date&_facets=signature&_facets=adapter_driver_version&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-adapter_driver_version.
For nvwgf2um.dll, the same (bug 1292273).
The same applies to other drivers.
See Also: → 1320054
I've filed bug 1320054 to re-evaluate the blocklist.
Firefox 53 supports out of process decoding which means we can take more risks with drivers. The penalty is a couple of seconds of recovery rather than a browser crash. Hopefully one day we'll be able to automate driver crash management.
See Also: → 1320386
(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #6)
> Firefox 53 supports out of process decoding which means we can take more
> risks with drivers. The penalty is a couple of seconds of recovery rather
> than a browser crash. Hopefully one day we'll be able to automate driver
> crash management.

Right now, the penalty is dropping out of acceleration (not just video decoding, but all of graphics.)  We do not have the "restart the GPU process" working.
Comment on attachment 8813950 [details]
Bug 1315089 - Block D3D11 for igd11dxva64.dll 20.19.15.X -

https://reviewboard.mozilla.org/r/95252/#review98168
Attachment #8813950 - Flags: review?(ajones) → review+
Comment hidden (mozreview-request)

Comment 10

3 years ago
Pushed by gsquelart@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c7ce65265593
Block D3D11 for igd11dxva64.dll 20.19.15.X - r=kentuckyfriedtakahe

Comment 11

3 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/c7ce65265593
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla53

Updated

2 years ago
Blocks: 1331086
Assignee

Comment 12

2 years ago
Comment on attachment 8813950 [details]
Bug 1315089 - Block D3D11 for igd11dxva64.dll 20.19.15.X -

Approval Request Comment
[Feature/Bug causing the regression]: Video decoding on some buggy Intel drivers
[User impact if declined]: Crashes when playing videos
[Is this code covered by automated tests?]: Yes, media tests
[Has the fix been verified in Nightly?]: According to bug 1331086 comment 0, crashes stopped after 53.0a1 build 20170103030204 when this patch landed
[Needs manual test from QE? If yes, steps to reproduce]: No (I think)
[List of other uplifts needed for the feature/fix]: None
[Is the change risky?]: No
[Why is the change risky/not risky?]: Only adding more driver versions to blocking list
[String changes made/needed]: None
Attachment #8813950 - Flags: approval-mozilla-aurora?
Comment on attachment 8813950 [details]
Bug 1315089 - Block D3D11 for igd11dxva64.dll 20.19.15.X -

d3d11 block list addition, aurora52+
Attachment #8813950 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+

Comment 15

2 years ago
Can we investigate and find a workaround or a fix to the crash, rather than just block it?

I am having version 20.19.15.4454, yet to have any kind of crashes. With this bug is being closed, I will have to update driver. However, it depends on customized hardware drivers that the OEM provides.

Suddenly, me and many users does not have D3D11 hardware acceleration. This will make battery life worse.

Reconsider.

Comment 16

2 years ago
*do
You need to log in before you can comment on or make changes to this bug.