crash in igd10umd32.dll coming from mozilla::layers::DataTextureSourceD3D11::Update, at playing video on YouTube

NEW
Assigned to

Status

()

Core
Graphics
--
critical
Rank:
7
2 years ago
4 months ago

People

(Reporter: masayuki, Assigned: mattwoodrow, NeedInfo)

Tracking

(Depends on: 1 bug, {crash})

41 Branch
x86
Windows 7
crash
Points:
---

Firefox Tracking Flags

(platform-rel -, firefox41- wontfix, firefox42+ wontfix, firefox43+ wontfix, firefox44+ wontfix, firefox45 wontfix, firefox46 wontfix, firefox47 affected, firefox48 affected, firefox49 affected, firefox50 affected, firefox-esr45 affected)

Details

(Whiteboard: [gfx-noted] [platform-rel-Youtube], crash signature)

This bug was filed from the Socorro interface and is 
report bp-7343227b-f49a-49b9-80f0-c760a2150923.
=============================================================
> Ø 0 	igd10umd32.dll	igd10umd32.dll@0x18f35
> Ø 1 	igd10umd32.dll	igd10umd32.dll@0x7a07
> Ø 2 	igd10umd32.dll	igd10umd32.dll@0x7024
> Ø 3 	igd10umd32.dll	igd10umd32.dll@0x335f
> 4 	xul.dll	mozilla::layers::DataTextureSourceD3D11::Update(mozilla::gfx::DataSourceSurface*, nsIntRegion*, mozilla::gfx::IntPointTyped<mozilla::gfx::UnknownUnits>*)
> 5 	xul.dll	mozilla::layers::DIBTextureHost::UpdatedInternal(nsIntRegion const*)
> 6 	xul.dll	mozilla::layers::TextureHost::Updated(nsIntRegion const*)
> 7 	xul.dll	mozilla::layers::ContentHostSingleBuffered::UpdateThebes(mozilla::layers::ThebesBufferData const&, nsIntRegion const&, nsIntRegion const&, nsIntRegion*)
> 8 	xul.dll	mozilla::layers::CompositableParentManager::ReceiveCompositableUpdate(mozilla::layers::CompositableOperation const&, std::vector<mozilla::layers::EditReply, std::allocator<mozilla::layers::EditReply> >&)
> 9 	xul.dll	mozilla::layers::LayerTransactionParent::RecvUpdate(nsTArray<mozilla::layers::Edit>&&, unsigned __int64 const&, mozilla::layers::TargetConfig const&, nsTArray<mozilla::layers::PluginWindowData>&&, bool const&, bool const&, unsigned int const&, bool const&, mozilla::TimeStamp const&, nsTArray<mozilla::layers::EditReply>*)

This is really similar to bug 1202700, but bug 1202700 was marked as unaffected 41.

Comment 1

2 years ago
It was marked unaffected for 41 and 42 due to backout of bug 1193547, the actual patch is only in 43.

Updated

2 years ago
Summary: crash in igd10umd32.dll@0x18f35 at playing video on YouTube → crash in igd10umd32.dll@0x18f35 coming from mozilla::layers::DataTextureSourceD3D11::Update, at playing video on YouTube
Do we need additional blacklisting?
Flags: needinfo?(matt.woodrow)
Whiteboard: [gfx-noted]
[Tracking Requested - why for this release]:
The signature igd10umd32.dll@0x18f35 itself is a topcrash right now. 

#5 in Firefox 41 with 1.40% of the volume.
#18 in Firefox 42 with 0.62% of the volume.
Firefox 43 has zero reports with this signature.
Firefox 44 has zero reports with this signature.

I'm not sure what percentage of these are in mozilla::layers::DataTextureSourceD3D11::Update though.
status-firefox41: --- → affected
status-firefox42: --- → affected
status-firefox43: --- → unaffected
status-firefox44: --- → unaffected
tracking-firefox41: --- → ?
tracking-firefox42: --- → ?
Keywords: topcrash-win
(Assignee)

Comment 4

2 years ago
Do we have any idea what changed to make this drop off?

We could try blacklisting for beta, but it looks like it's already down considerably there.
Flags: needinfo?(matt.woodrow)
Tracking as it is a top crash.
tracking-firefox42: ? → +
(In reply to Matt Woodrow (:mattwoodrow) from comment #4)
> Do we have any idea what changed to make this drop off?

I'm not so certain this "dropped off". I don't have data to say whether this has changed significantly in Firefox 41 and 42. As for the "zero reports" in Aurora and Nightly, that may just be a symptom of the users and hardware on those branches. We have no way of knowing for sure until Firefox 43/44 get into Beta/Release.
Even if 42 is still crash, it seems unlikely that it is going to be fixed in 42. Updating the flags accordingly.
status-firefox41: affected → wontfix
status-firefox42: affected → wontfix
tracking-firefox41: ? → -
anthony can you run a driver version correlation? I wonder if this is a 'sister' bug to bug 1221348.

I can't find how to run them myself. Is there information on this?
Flags: needinfo?(anthony.s.hughes)
Driver Correlations:
====================
1 	8.15.10.1892 	2891 	39.32 %
2 	8.15.10.1883 	1592 	21.65 %
3 	8.15.10.1855 	1246 	16.95 %
4 	8.15.10.1872 	749 	10.19 %
5 	8.15.10.1851 	440 	5.98 %
6 	8.15.10.1994 	428 	5.82 %
7 	8.15.10.2020 	4 	0.05 %
8 	8.640.4.1000 	1 	0.01 %
9 	8.652.1.0 	1 	0.01 %
Flags: needinfo?(anthony.s.hughes)
This correlated with the same driver range as bug 1221348.
Some URLs from the comments:
https://www.youtube.com/watch?v=yBJEP4lsRFY
https://www.youtube.com/watch?v=qKoLcyDGalw

A lot of users also report crashes while viewing Facebook clips.

A lot of comments mention that the crash happens halfway through a video.
Filter:
https://crash-stats.mozilla.com/signature/?date=%3E%3D2015-10-30T23%3A14%3A19.720668&date=%3C2015-11-06T23%3A14%3A19.720668&product=Firefox&uptime=%3E1000&version=45.0a1&version=44.0a2&version=44.0a1&version=43.0a2&version=43.0a1&signature=igd10umd32.dll%400x18f35&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&page=1#reports

I only see a single report in 43 nightly and nothing in 44, 45.

I can't reproduce this locally. I'll leave the laptop running over the weekend.
I haven't been able to reproduce this crash.
I see a few on 45 (e.g., https://crash-stats.mozilla.com/report/index/a34e0fff-e22c-44d1-930e-be6a82151125).  I'm not sure the numbers are lower because things are better, they may very well be because of the distribution of graphics cards.

Comment 15

2 years ago
[Tracking Requested - why for this release]:
So this is 1.3% of all 43.0 crashes, a lot of comments are really angry, URLs are mostly Facebook and YouTube, which are our most-heavy MSE video users. This is the worst gfx issue we have on release right now.
status-firefox43: unaffected → affected
status-firefox44: unaffected → affected
tracking-firefox43: --- → ?
tracking-firefox44: --- → ?

Comment 16

2 years ago
Milan, is there something we can do somewhat easily like some blocklisting? In any case, can we have someone to find out how we can mitigate this?
Flags: needinfo?(milan)
Will do.
Matt, can you tell from the crash report or the stack (e.g., https://crash-stats.mozilla.com/report/index/92909008-8951-4503-8546-1df9e2151216) when the video is DXVA or not?
Flags: needinfo?(milan) → needinfo?(matt.woodrow)
Tracked for 44 since it's a top crash.
tracking-firefox44: ? → +
Tracking for 43.   We are planning to go to build for 43.0.2 on MOnday. I hope we can use the blocklist here though.
tracking-firefox43: ? → +
Was bug 1193547 the cause of this regression?
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #21)
> Was bug 1193547 the cause of this regression?

I have to admit, it is a bit confusing.  Bug 1193547 landed on 43, got uplifted to 41 and 42, then got backed out of 41 and 42.  Did we keep getting the crashes in 41 and 42 after the backout?  If not, that but could be the cause.

Also if we're already blocking these from DXVA, blocklisting won't help.  There are at least some that are suggesting we're attempting to block (https://crash-stats.mozilla.com/report/index/6e950b4e-9707-4311-bcd8-2fc4e2151216) because of crashes during the sanity start up test), but I'm not sure if all of them are in the software fallback mode - and bug 1193547 is about that.  So, I do want to understand if we can tell if we're accelerating or not based on the crash reports.

Time zones may help us here - Matt will be at work around Sunday noon PST time.
Matt may be on PTO Monday.  Hold on.
Assignee: nobody → matt.woodrow
Flags: needinfo?(milan)
A quick sanity test - is it OK that we have D3D9 DXVA manager, but are otherwise using D3D11?
(In reply to Milan Sreckovic [:milan] from comment #24)
> A quick sanity test - is it OK that we have D3D9 DXVA manager, but are
> otherwise using D3D11?

Never mind, looks like we do want to do this by default.
Chris and Jean-Yves reviewed bug 1193547, maybe one of them is not on PTO.
Flags: needinfo?(jyavenard)
Flags: needinfo?(cpearce)
Bas, you're also in earlier on Monday than the NA folks - can you look at this, video or not...
Flags: needinfo?(bas)
(In reply to Milan Sreckovic [:milan] from comment #27)
> Bas, you're also in earlier on Monday than the NA folks - can you look at
> this, video or not...

'Cause, partial surface upload and all.  Maybe bad parameters.  Jeff, you can I can check on Monday, using the actual crash dump?

Sorry for all the NI's on this bug, but we need to get to the bottom of this - see comment 15 and comment 20.
Flags: needinfo?(jmuizelaar)
From a media standpoint, all bug 1193547 was doing was detect if using the hardware decoder failed, and if so fall back to the software decoder.
So in the case of hardware decoding, the picture frame returned would be GPU backed.

Now that may expose a bug in the compositor. You can see from the backtrace that nowhere is the media stack involved. So really that is unrelated to the media stack and the fix would be beyond my area of expertise so I'm not sure I may be able to help.

You may want to revert that patch, but if so it will introduce other regressions. But seeing it wasn't in 42 either it probably doesn't matter that much.

Reverting bug 1193547 wouldn't fix the problem, it just work around calling a buggy code path. But if the fix is urgent, there may not be any other way.
Flags: needinfo?(jyavenard)
(In reply to Jean-Yves Avenard [:jya] from comment #29)
> From a media standpoint, all bug 1193547 was doing was detect if using the
> hardware decoder failed, and if so fall back to the software decoder.
> So in the case of hardware decoding, the picture frame returned would be GPU
> backed.
> 
> Now that may expose a bug in the compositor. You can see from the backtrace
> that nowhere is the media stack involved. So really that is unrelated to the
> media stack and the fix would be beyond my area of expertise so I'm not sure
> I may be able to help.
> 
> You may want to revert that patch, but if so it will introduce other
> regressions. But seeing it wasn't in 42 either it probably doesn't matter
> that much.
> 
> Reverting bug 1193547 wouldn't fix the problem, it just work around calling
> a buggy code path. But if the fix is urgent, there may not be any other way.

The crash itself happens pretty deep inside the intel drivers, it could be media is at least somehow involved. We need to get a minidump for one of these and check if I may be wrong and we're passing a null ptr to UpdateSubresource somehow. That in itself would most certainly explain the crash without the drivers being at fault.
Flags: needinfo?(bas)
I've examined the minidump for this crash and concluded all the parameters we're passing to UpdateSubResource are valid. mTexture could not be verified as it doesn't live on the stack and therefor isn't in the minidump, however the context in this function guarantees mTexture cannot be null. So this crash is basically guaranteed to be an actual bug in the intel drivers. It could be related to something media is doing, but it's impossible to say that for sure without having an environment where we can reproduce this.
We're going to try and reproduce in Toronto, we do have a 0x2a42 device.  At least some of the crashes are on the systems where hardware video decoding should be disabled.
It is also quite possible that the spike is because Facebook bumped up the use of HTML5 videos.
Flags: needinfo?(milan)
I'll produce a downloadable blocklist entry for the majority of these devices; we haven't been able to reproduce this yet, so I don't see us being able to produce the "in code" fix soon enough for 42.0.*
This blocklist entry should disable all acceleration features on Windows 7, Intel device 0x2a42 (most common in these crashes) devices for all drivers between 8.15.10.1800 and 8.15.10.1999 (inclusive.)  That's a big hammer we're using, but it isn't clear where the issue lies, so we may not want to discover new code paths by only disabling some of the functionality.

If we do find a workaround, we can modify this blocklist entry to only apply to versions of Firefox without that workaround. If we do not, we can disable all of these devices and drivers - for right now, some of the incoming reports may help us figure out what's going on.

I'll get this reviewed before requesting update to the downloadable blocklist.  

<gfxBlacklistEntry>
  <os>WINNT 6.1</os>
  <vendor>0x8086</vendor>
  <devices>
    <device>0x2a42</device>
  </devices>
<featureStatus>BLOCKED_DRIVER_VERSION</featureStatus>
  <driverVersion>8.15.10.1800</driverVersion>
  <driverVersionMax>8.15.10.1999</driverVersionMax>
  <driverVersionComparator>BETWEEN_INCLUSIVE</driverVersionComparator>
</gfxBlacklistEntry>
This is another option - all features, all OS versions on these offending devices.

<gfxBlacklistEntry>
  <vendor>0x8086</vendor>
  <devices>
    <device>0x2a42</device>
    <device>0x2e22</device>
    <device>0x2e12</device>
    <device>0x2e32</device>
  </devices>
  <featureStatus>BLOCKED_DRIVER_VERSION</featureStatus>
  <driverVersion>8.15.10.1800</driverVersion>
  <driverVersionMax>8.15.10.1999</driverVersionMax>
  <driverVersionComparator>BETWEEN_INCLUSIVE</driverVersionComparator>
</gfxBlacklistEntry>
(In reply to Jean-Yves Avenard [:jya] from comment #29)
> From a media standpoint, all bug 1193547 was doing was detect if using the
> hardware decoder failed, and if so fall back to the software decoder.
> ...

Right; it caused bug 1202700 which had the same signature, which is why it got flagged.  But, yes, it's likely just exposing a bug elsewhere or in the driver.
Somewhat randomly, 0x60 appears to be the config location for the Intel PCI config.  This is likely completely coincidental, but it does feature prominently in the code for the Linux drivers (e.g., intel_i915_setup_chipset_flush()), so I thought I'd mention it.
The function that's crashing is doing a bunch of floating point arithmetic which seems a bit unusual.
Flags: needinfo?(jmuizelaar)
We also don't seem to hit that particular instruction when playing youtube
We had a decoding failure with ffmpeg with a format I had never heard of before, bug 1233340. Very long shot, but could it be 12bpp YUV420 causing the problem?
<gfxBlacklistEntry>
  <vendor>0x8086</vendor>
  <devices>
    <device>0x2a42</device>
    <device>0x2e22</device>
    <device>0x2e12</device>
    <device>0x2e32</device>
    <device>0x0046</device>
  </devices>
  <featureStatus>BLOCKED_DRIVER_VERSION</featureStatus>
  <driverVersion>8.15.10.1800</driverVersion>
  <driverVersionMax>8.15.10.1999</driverVersionMax>
  <driverVersionComparator>BETWEEN_INCLUSIVE</driverVersionComparator>
</gfxBlacklistEntry>
The crash seems to happen when a driver call in the igd10umd32.dll@0x7800 function to d3d11!NDXGI::DeviceLockCB fails.
I believe this corresponds to this function pfnLockCb:
https://msdn.microsoft.com/en-us/library/windows/hardware/ff568914%28v=vs.85%29.aspx
If we could know why this function was failing in these crashes that would help a lot in figuring out the problem.
(In reply to Milan Sreckovic [:milan] from comment #41)
> <gfxBlacklistEntry>
>   <vendor>0x8086</vendor>
>   <devices>
>     <device>0x2a42</device>
>     <device>0x2e22</device>
>     <device>0x2e12</device>
>     <device>0x2e32</device>
>     <device>0x0046</device>
>   </devices>
>   <featureStatus>BLOCKED_DRIVER_VERSION</featureStatus>
>   <driverVersion>8.15.10.1800</driverVersion>
>   <driverVersionMax>8.15.10.1999</driverVersionMax>
>   <driverVersionComparator>BETWEEN_INCLUSIVE</driverVersionComparator>
> </gfxBlacklistEntry>

This seems sane. Let's stop the bleeding for now and continue to try figure out what's going on.
Jorge, can you add the item from comment 41 to the downloadable blocklist?
Flags: needinfo?(jorge)
Depends on: 1234354
Going to try and find out if we have any of these matching crashes during the startup sanity test once bug 1234362 enables us to search for those.
See Also: → bug 1234362
Some of the crashes have "Too many dropped/corrupted frames, disabling DXVA"
Looks like driverVersionMax is new and isn't supported on the blocklisting forms on AMO. I filed an issue for this (https://github.com/mozilla/olympia/issues/1123), but I don't know how long it will take to be fixed.
Flags: needinfo?(jorge)
Ouch - thanks for filing that bug.  In the meantime, we'll go with the explicit versions that were showing up the most:

<gfxBlacklistEntry>
  <vendor>0x8086</vendor>
  <devices>
    <device>0x2a42</device>
    <device>0x2e22</device>
    <device>0x2e12</device>
    <device>0x2e32</device>
    <device>0x0046</device>
  </devices>
  <featureStatus>BLOCKED_DRIVER_VERSION</featureStatus>
  <driverVersion>8.15.10.1851</driverVersion>
  <driverVersionComparator>EQUAL</driverVersionComparator>
</gfxBlacklistEntry>

<gfxBlacklistEntry>
  <vendor>0x8086</vendor>
  <devices>
    <device>0x2a42</device>
    <device>0x2e22</device>
    <device>0x2e12</device>
    <device>0x2e32</device>
    <device>0x0046</device>
  </devices>
  <featureStatus>BLOCKED_DRIVER_VERSION</featureStatus>
  <driverVersion>8.15.10.1855</driverVersion>
  <driverVersionComparator>EQUAL</driverVersionComparator>
</gfxBlacklistEntry>

<gfxBlacklistEntry>
  <vendor>0x8086</vendor>
  <devices>
    <device>0x2a42</device>
    <device>0x2e22</device>
    <device>0x2e12</device>
    <device>0x2e32</device>
    <device>0x0046</device>
  </devices>
  <featureStatus>BLOCKED_DRIVER_VERSION</featureStatus>
  <driverVersion>8.15.10.1872</driverVersion>
  <driverVersionComparator>EQUAL</driverVersionComparator>
</gfxBlacklistEntry>

<gfxBlacklistEntry>
  <vendor>0x8086</vendor>
  <devices>
    <device>0x2a42</device>
    <device>0x2e22</device>
    <device>0x2e12</device>
    <device>0x2e32</device>
    <device>0x0046</device>
  </devices>
  <featureStatus>BLOCKED_DRIVER_VERSION</featureStatus>
  <driverVersion>8.15.10.1883</driverVersion>
  <driverVersionComparator>EQUAL</driverVersionComparator>
</gfxBlacklistEntry>

<gfxBlacklistEntry>
  <vendor>0x8086</vendor>
  <devices>
    <device>0x2a42</device>
    <device>0x2e22</device>
    <device>0x2e12</device>
    <device>0x2e32</device>
    <device>0x0046</device>
  </devices>
  <featureStatus>BLOCKED_DRIVER_VERSION</featureStatus>
  <driverVersion>8.15.10.1892</driverVersion>
  <driverVersionComparator>EQUAL</driverVersionComparator>
</gfxBlacklistEntry>

<gfxBlacklistEntry>
  <vendor>0x8086</vendor>
  <devices>
    <device>0x2a42</device>
    <device>0x2e22</device>
    <device>0x2e12</device>
    <device>0x2e32</device>
    <device>0x0046</device>
  </devices>
  <featureStatus>BLOCKED_DRIVER_VERSION</featureStatus>
  <driverVersion>8.15.10.1994</driverVersion>
  <driverVersionComparator>EQUAL</driverVersionComparator>
</gfxBlacklistEntry>
Flags: needinfo?(jorge)
(In reply to Jorge Villalobos [:jorgev] from comment #49)
> Looks like driverVersionMax is new and isn't supported on the blocklisting
> forms on AMO. I filed an issue for this
> (https://github.com/mozilla/olympia/issues/1123), but I don't know how long
> it will take to be fixed.

And I just realized that driverVersionMax field isn't supported in the code either.  So, I'd appreciate it if we can fix this issue in "olympia", but the urgency is not as critical, given that we need to also add this support into the code.  I'll open a separate bug for that.  In the meantime, comment 50 is the way to go.
Okay, it's done.
Flags: needinfo?(jorge)
(In reply to Jeff Muizelaar [:jrmuizel] from comment #44)
> If we could know why this function was failing in these crashes that would
> help a lot in figuring out the problem.

From reading the code it looks like it's not WASSTILLDRAWING or DEVICEREMOVED
(In reply to Jeff Muizelaar [:jrmuizel] from comment #53)
> (In reply to Jeff Muizelaar [:jrmuizel] from comment #44)
> > If we could know why this function was failing in these crashes that would
> > help a lot in figuring out the problem.
> 
> From reading the code it looks like it's not WASSTILLDRAWING or DEVICEREMOVED

Simulating the function returning E_OUTOFMEMORY is not sufficient to reproduce the crash.
(In reply to Jeff Muizelaar [:jrmuizel] from comment #54)
> (In reply to Jeff Muizelaar [:jrmuizel] from comment #53)
> > (In reply to Jeff Muizelaar [:jrmuizel] from comment #44)
> > > If we could know why this function was failing in these crashes that would
> > > help a lot in figuring out the problem.
> > 
> > From reading the code it looks like it's not WASSTILLDRAWING or DEVICEREMOVED
> 
> Simulating the function returning E_OUTOFMEMORY is not sufficient to
> reproduce the crash.

We end up calling the crashing function but it looks like something else needs to go wrong for us to actually crash.
Too late to fix on 43.
status-firefox43: affected → wontfix
status-firefox45: --- → ?
status-firefox46: --- → ?
Still looking like a topcrash on 43 though.
RE: 45/46 status - as of yet there are no reports for this signature in Firefox 45.0a2, 45.0a1, and 46.0a1
https://crash-stats.mozilla.com/search/?product=Firefox&signature=%3Digd10umd32.dll%400x18f35&version=45.0a2&version=46.0a1&version=45.0a1&_facets=signature&_facets=version&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#crash-reports
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #57)
> Still looking like a topcrash on 43 though.

Hopefully this slows down as the blocklist gets updated for these users.
Should we be locking (keyed mutex) mTexture before calling UpdateSubresource?  Would that help, hurt, do nothing?
Flags: needinfo?(jmuizelaar)
Flags: needinfo?(bas)
It appears the blocklist is holding these crashes back.
(In reply to Milan Sreckovic [:milan] from comment #60)
> Should we be locking (keyed mutex) mTexture before calling
> UpdateSubresource?  Would that help, hurt, do nothing?

If we were using them we should, but that's not the case in this stack.
Flags: needinfo?(bas)
I'm not sure how much I can help here... One idea; the DXVA documentation mentions locking the D3D devices:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms697056%28v=vs.85%29.aspx

We seem to be not doing that.

I tried that when I did the initial DXVA support, but it made playback performance slow to a crawl on my machine. So maybe I wasn't doing it right. It's a bit hard to know for sure whether enabling that again would help without a repro.
Flags: needinfo?(cpearce)
I'm not sure this is DXVA related as we currently hit it on devices that have DXVA disabled.
I don't think this blocking is working.
Flags: needinfo?(milan)
For example: https://crash-stats.mozilla.com/report/index/91d5502c-6240-4271-8cb6-5a8dc2160129, despite:

<gfxBlacklistEntry>
  <vendor>0x8086</vendor>
  <devices>
    <device>0x2a42</device>
    <device>0x2e22</device>
    <device>0x2e12</device>
    <device>0x2e32</device>
    <device>0x0046</device>
  </devices>
  <featureStatus>BLOCKED_DRIVER_VERSION</featureStatus>
  <driverVersion>8.15.10.1872</driverVersion>
  <driverVersionComparator>EQUAL</driverVersionComparator>
</gfxBlacklistEntry>
Flags: needinfo?(milan)
It looks like if you don't have a suggested version for blocking driver versions we don't block:
https://dxr.mozilla.org/mozilla-central/source/widget/GfxInfoBase.cpp#1020
Flags: needinfo?(jmuizelaar)
The situation is even worse. There does not appear to be a way to specify a suggested version. This implies that the only driver block list entries that work are those that use LESS_THAN which have an implicit suggested version.
Not quite that bad.  This code https://dxr.mozilla.org/mozilla-central/source/widget/GfxInfoBase.cpp#1020 just means we don't save the blocking status in a pref, but we're still blocking.

The actual problem here is that the specification from comment 50 does not have the <os></os> values set.  While the absence of <feature> means "all features", the absence of <os> means "undefined OS".  We need to add <os>All</os> to all the entries above.

We'll test this on one of the affected systems first and confirm.
Flags: needinfo?(jmuizelaar)
I tried testing it and it didn't work. Then I realized I had typo'd All as ALL :( It worked when I fixed that.

Jorge can you <os>All</os> to the entries above?
Flags: needinfo?(jmuizelaar) → needinfo?(jorge)
Done.
Flags: needinfo?(jorge)
Too late for Fx44, wontfix.
status-firefox44: affected → wontfix
(Assignee)

Updated

a year ago
Flags: needinfo?(matt.woodrow)
We had 34,655 crashes in the month before we pushed the block live on February 9th. 

Since then we've seen 5,173 crashes, mostly on older Firefox versions:
> Firefox 46:   17 crashes since 2016-02-10 [ 0.32%]
> Firefox 45:  272 crashes since 2016-02-10 [ 5.26%] 
> Firefox 43:  797 crashes since 2016-02-10 [15.40%]
> Firefox 35: 2197 crashes since 2016-02-10 [42.47%]

In the last week we've seen 213 crashes, again mostly on older Firefox versions:
> Firefox 46:    8 crashes since 2016-04-30 [ 3.76%]
> Firefox 45:   24 crashes since 2016-04-30 [11.27%] 
> Firefox 43:   12 crashes since 2016-04-30 [ 5.63%]
> Firefox 35:  114 crashes since 2016-04-30 [53.52%]

The blocked driver version has declined to 4th overall:
> 8.15.10.1892: 42 crashes since 2016-04-30 [54.55%]
> 8.15.10.1855:  9 crashes since 2016-04-30 [11.69%]
> 8.15.10.1883:  9 crashes since 2016-04-30 [11.69%]
> 8.15.10.1872:  5 crashes since 2016-04-30 [ 6.49%]
> 8.15.10.1994:  4 crashes since 2016-04-30 [ 5.19%]

Based on this information I would say the block is not 100% effective although it has improved the situation. It doesn't even break in to the top-300 crashes for Firefox 46.0.1.
status-firefox45: ? → wontfix
status-firefox46: ? → wontfix
status-firefox47: --- → ?
status-firefox48: --- → ?
status-firefox49: --- → ?
Keywords: topcrash-win
platform-rel: --- → ?
Whiteboard: [gfx-noted] → [gfx-noted] [platform-rel-Youtube]
platform-rel: ? → +
Crash volume for signature 'igd10umd32.dll@0x18f35':
 - nightly (version 50): 0 crashes from 2016-06-06.
 - aurora  (version 49): 0 crashes from 2016-06-07.
 - beta    (version 48): 2 crashes from 2016-06-06.
 - release (version 47): 31 crashes from 2016-05-31.
 - esr     (version 45): 48 crashes from 2016-04-07.

Crash volume on the last weeks:
            W. N-1  W. N-2  W. N-3  W. N-4  W. N-5  W. N-6  W. N-7
 - nightly       0       0       0       0       0       0       0
 - aurora        0       0       0       0       0       0       0
 - beta          0       0       0       0       0       0       1
 - release       0       0       0       0       0      10      16
 - esr           0       0       0       0       0       2      13

Affected platform: Windows
status-firefox-esr45: --- → affected

Updated

10 months ago
Rank: 7
Crash Signature: [@ igd10umd32.dll@0x18f35] → [@ igd10umd32.dll@0x18f35] [@ igd10umd32.dll | mozilla::layers::DataTextureSourceD3D11::Update]
Note that this doesn't appear to be vendor specific, and while this bug is tracking it for Intel devices, there are equivalent crashes on other vendors (e.g., https://crash-stats.mozilla.com/report/index/87236fa8-a3ab-4edc-a4d6-5cf842161026)
Summary: crash in igd10umd32.dll@0x18f35 coming from mozilla::layers::DataTextureSourceD3D11::Update, at playing video on YouTube → crash in igd10umd32.dll coming from mozilla::layers::DataTextureSourceD3D11::Update, at playing video on YouTube
No new crashes in 51 and 52, could be fixed by the recent video changes we made.  These seem to be driver reset related, quite likely from OOM like situation.
(In reply to Milan Sreckovic [:milan] from comment #76)
> No new crashes in 51 and 52, could be fixed by the recent video changes we
> made.  These seem to be driver reset related, quite likely from OOM like
> situation.

With no new crashes in 51 + 52, should this be closed :milan?
Flags: needinfo?(milan)
(In reply to Desigan Chinniah [:cyberdees] [:dees] [London - GMT] from comment #77)
> (In reply to Milan Sreckovic [:milan] from comment #76)
> > No new crashes in 51 and 52, could be fixed by the recent video changes we
> > made.  These seem to be driver reset related, quite likely from OOM like
> > situation.
> 
> With no new crashes in 51 + 52, should this be closed :milan?

Sounds about right.  Anthony, I'll let you double check my queries and close it if appropriate.
Flags: needinfo?(milan) → needinfo?(anthony.s.hughes)
We have a couple of crashes in 51/52 recently:
https://crash-stats.mozilla.com/signature/?version=52.0a2&version=51.0b&signature=igd10umd32.dll%20%7C%20mozilla%3A%3Alayers%3A%3ADataTextureSourceD3D11%3A%3AUpdate&date=%3E%3D2016-12-07T18%3A27%3A00.000Z&date=%3C2016-12-14T18%3A27%3A00.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_sort=-date&page=1#reports
Flags: needinfo?(anthony.s.hughes)
We've had very few crashes with 51 beta so far, but let's wait next week (when we release 51 to the release channel) before calling it fixed (the crash volume on the beta channel has always been small).
status-firefox47: ? → affected
status-firefox48: ? → affected
status-firefox49: ? → affected
status-firefox50: --- → affected
There are still crashes in 51, but with a very small volume (20 crashes over the past week).
platform-rel: + → -
I don't think this is vendor specific bug - see bug 1310600 for Nvidia, for example.  There are a few variations, but all in the partial upload.  ~60% in bad WRITE, the rest in bad READ.
Flags: needinfo?(milan)
See Also: → bug 1310600
It's also probably not partial update related - here's one example of the full update: https://crash-stats.mozilla.com/report/index/c84ca10c-5ce9-46fc-8948-ce64b2170301 (read failure)
You need to log in before you can comment on or make changes to this bug.