Closed Bug 1189940 Opened 9 years ago Closed 9 years ago

Win10 crashes in nvwgf2um.dll@0x47c5d via CompositorD3D11::EndFrame

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Version:
42 Branch
Platform:
x86
Windows NT
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox40 + wontfix
firefox41 + wontfix
firefox42 + disabled
firefox43 + disabled

People

(Reporter: away, Assigned: bas.schouten)

References

Details

(Keywords: crash, topcrash-win)

Crash Data

Attachments

(1 file)

Crash Trend
17.07 KB, image/png
Details 
This bug was filed from the Socorro interface and is 
report bp-e3420c8c-17cc-4738-a249-3d2842150729.
=============================================================

Currently the third-highest crash on Windows 10.

Ø 0 	nvwgf2um.dll 	nvwgf2um.dll@0x47c5d 	
Ø 1 	d3d11.dll 	d3d11.dll@0x29b09 	
Ø 2 	dxgi.dll 	dxgi.dll@0x4ad0a 	
Ø 3 	dxgi.dll 	dxgi.dll@0x2f25b 	
Ø 4 	dxgi.dll 	dxgi.dll@0x21d94 	
Ø 5 	dxgi.dll 	dxgi.dll@0x4cf80 	
6 	xul.dll 	mozilla::layers::CompositorD3D11::EndFrame() 	gfx/layers/d3d11/CompositorD3D11.cpp
7 	xul.dll 	mozilla::layers::LayerManagerComposite::Render() 	gfx/layers/composite/LayerManagerComposite.cpp
8 	xul.dll 	mozilla::layers::LayerManagerComposite::EndTransaction(void (*)(mozilla::layers::PaintedLayer*, gfxContext*, nsIntRegion const&, mozilla::layers::DrawRegionClip, nsIntRegion const&, void*), void*, mozilla::layers::LayerManager::EndTransactionFlags)
Adapter driver version facet Rank 	Adapter driver version 	Count 	%
1 	10.18.13.5362 	261 	100.00 %

Long tail of device ID's.
Milan, here's an nvidia crash to go with the ATI one, to keep your day balanced.
Flags: needinfo?(milan)
Getting the dxgi.dll/d3d11.dll symbols on crash stats would help us make a little more sense of where this is going wrong.
Flags: needinfo?(ted)
Blocks: 1148406
Flags: needinfo?(milan)
While we're figure things out, we should probably just blocklist (downloadable) driver 10.18.13.5362 for Windows 10 with something like this:

<gfxBlacklistEntry>
  <os>WINNT 10.0</os>
  <vendor>0x10de</vendor>
  <feature>DIRECT3D_11_LAYERS</feature>
  <featureStatus>BLOCKED_DRIVER_VERSION</featureStatus>
  <driverVersion>10.18.13.5362</driverVersion>
  <driverVersionComparator>EQUAL</driverVersionComparator>
</gfxBlacklistEntry>

which we can then change once we fix or blocklist in code by adding something like this:

  <versionRange minVersion="39.0" maxVersion="43.0"></versionRange>

if we were to fix it in 43, for example.

Jeff, does this make sense?  David, it is all Nvidia (obviously :) and that one driver, right?
Flags: needinfo?(jmuizelaar)
Flags: needinfo?(dmajor)
Based on other crashes that do have d3d11/dxgi symbols, I'm going to assume that this stack is:

1 	d3d11.dll 	NDXGI::CDevice::Blt(IDXGIResource*, tagRECT const*, tagRECT const*, unsigned int, IDXGIResource*, tagRECT const*, SUBRESOURCE_BLT_MAP const*, unsigned __int64, unsigned int, unsigned int) 	
2 	dxgi.dll 	CDXGISwapChain::EmulateDirtyRectPresentVistaBlt(tagRECT const*, unsigned int, tagRECT*, SUBRESOURCE_BLT_MAP const*, unsigned __int64) 	
3 	dxgi.dll 	CDXGISwapChain::PresentImplCore(SPresentArgs const*, unsigned int, unsigned int, unsigned int, tagRECT const*, unsigned int, DXGI_SCROLL_RECT const*, IDXGIResource*, bool&, bool&, bool&) 	
4 	dxgi.dll 	CDXGISwapChain::PresentImpl(SPresentArgs const*, unsigned int, unsigned int, unsigned int, tagRECT const*, unsigned int, DXGI_SCROLL_RECT const*, IDXGIResource*) 	
5 	dxgi.dll 	?Present1@?QIDXGISwapChain3@@CDXGISwapChain@@UAGJIIPBUDXGI_PRESENT_PARAMETERS@@@Z 	
6 	xul.dll 	mozilla::layers::CompositorD3D11::EndFrame() 	gfx/layers/d3d11/CompositorD3D11.cpp
7 	xul.dll 	mozilla::layers::LayerManagerComposite::Render() 	gfx/layers/composite/LayerManagerComposite.cpp
8 	xul.dll 	mozilla::layers::LayerManagerComposite::EndTransaction(void (*)(mozilla::layers::PaintedLayer*, gfxContext*, nsIntRegion const&, mozilla::layers::DrawRegionClip, nsIntRegion const&, void*), void*, mozilla::layers::LayerManager::EndTransactionFlags) 	gfx/layers/composite/LayerManagerComposite.cpp
> David, it is all Nvidia (obviously :) and that one driver, right?

There are quite a few signatures: https://crash-stats.mozilla.com/search/?signature=~nvwgf2um&platform_version=%3D10.0.10240&version=39.0&version=40.0&_facets=signature&_facets=build_id&_facets=version&_facets=release_channel&_facets=platform_version&_facets=adapter_driver_version&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature

I haven't checked all of them, 10.18.13.5330, 9.18.13.4174, and 10.18.13.5362 all hit the same stack as comment 5 (with different nvwgf2um offsets in frame 0, of course).
Flags: needinfo?(dmajor)
With an extremely small sample of comments I looked at "youtube video going full screen" showed up a couple of times.  What happens when we do that operation that could trigger this?
Flags: needinfo?(ted)
Here's another signature seen with 9.17.10.4229 on Windows 10 in early 40.0 data: bp-3e7b3b91-11f8-4b2a-b73c-a688c2150811
Crash Signature: [@ nvwgf2um.dll@0x47c5d] → [@ nvwgf2um.dll@0x47c5d] [@ nvwgf2um.dll@0x69b75d ]
For now, let's block 353.62 and see what that does to the crashes.


This needs to be added to the downloadable blocklist; Jorge, is that you?  I'll also ask on IRC.

<gfxBlacklistEntry>
  <os>WINNT 10.0</os>
  <vendor>0x10de</vendor>
  <feature>DIRECT3D_11_LAYERS</feature>
  <featureStatus>BLOCKED_DRIVER_VERSION</featureStatus>
  <driverVersion>10.18.13.5362</driverVersion>
  <driverVersionComparator>EQUAL</driverVersionComparator>
</gfxBlacklistEntry>

<gfxBlacklistEntry>
  <os>WINNT 10.0</os>
  <vendor>0x10de</vendor>
  <feature>DIRECT2D</feature>
  <featureStatus>BLOCKED_DRIVER_VERSION</featureStatus>
  <driverVersion>10.18.13.5362</driverVersion>
  <driverVersionComparator>EQUAL</driverVersionComparator>
</gfxBlacklistEntry>
Flags: needinfo?(jorge)
Milan mentioned in the channel meeting today that this also affects FF41.
status-firefox41: --- → affected
Yes, all releases.  Note that 39 does not know about Windows 10, the downloadable blocklist will only work for 40 and later (bug 1183725), so I wouldn't expect 39 crashes to change, other than as people update.
The blocks have been added per comment #9.
Flags: needinfo?(jorge)
(In reply to Jorge Villalobos [:jorgev] from comment #12)
> The blocks have been added per comment #9.

Flagging myself to check crash-stats in a few days to see what difference this has made.
Flags: needinfo?(anthony.s.hughes)
Nvidia driver 353.62 is the latest version (WHQL, "Game Ready" offered by GeForce Experience, and offered by geforce.com site).  Blocking this seems like a terrible idea.  What's the correlation between nvidia 353.62 and this crash?  Most people installing Windows 10 will get the latest drivers as well, so this is effectively disabling hw accel for people who install windows 10.
Here are the driver version correlations in combined signatures:
10.18.13.5362 	1531 	94.04 %
9.17.10.4229 	72 	 4.42 %
10.18.10.4252 	19 	 1.17 %
10.18.15.4256 	3 	 0.18 %
10.18.10.3304 	1 	 0.06 %
10.18.10.4242 	1 	 0.06 %
9.17.10.3517 	1 	 0.06 %

It's unfortunate that we need to disable HWA for latest hardware/drivers but the alternative is letting these people crash. I think crashing is far more likely to drive people away than not giving them HWA. Also note that this is a temporary work around - HWA will be reinstated for these users once this issue is resolved.
Flags: needinfo?(anthony.s.hughes)
as a windows 10 user that was having no stability issues at all with hardware accel, is there anyway I can override this blocklist? gfx.direct2d.force-enabled;true and layers.acceleration.force-enabled;true don't seem to be working..
Good call, the official nvidia feedback thread for this cursed 353.62 driver [1] has had 1500 answers (!) in two weeks (!!), most complaining about these crashes... Yeah indeed, there are -quite- a few people annoyed.

A nvidia QA rep announced today August 12 that they "will be releasing a new driver soon that will address some of the issues" [2].

[1] https://forums.geforce.com/default/topic/860152/geforce-drivers/official-windows-10-353-62-game-ready-display-driver-feedback-thread-7-29-15-/
[2] https://forums.geforce.com/default/topic/860152/geforce-drivers/official-windows-10-353-62-game-ready-display-driver-feedback-thread-7-29-15-/post/4634674/#4634674
I have put many, many hours of browsing and watching videos in HTML5 and flash, I have had no issues whatsoever with the 353.62 driver and Windows 10, neither has my grandfather on his laptop.

Took me ages to figure out why I was getting major screen tearing. Mozilla should not be forcefully disabling drivers considering Windows 10 forces driver updates and this will be the latest only really usable version for everyone.

If you are going to forcefully disable something major like this, you could at least show a popup or something to inform people of the change.
FWIW, Manuel Guzman from NVIDIA has said that this will be fixed in the next driver update.
Flags: needinfo?(jmuizelaar)
(In reply to Jeff Muizelaar [:jrmuizel] from comment #21)
> FWIW, Manuel Guzman from NVIDIA has said that this will be fixed in the next
> driver update.

Does he know what's the underlying cause?  e.g. is it caused by partial presents or something that we can disable instead of nuking hw accel entirely?
(In reply to Vladimir Vukicevic [:vlad] [:vladv] from comment #22)
> (In reply to Jeff Muizelaar [:jrmuizel] from comment #21)
> > FWIW, Manuel Guzman from NVIDIA has said that this will be fixed in the next
> > driver update.
> 
> Does he know what's the underlying cause?  e.g. is it caused by partial
> presents or something that we can disable instead of nuking hw accel
> entirely?

I contacted Manuel and Josh from NVIDIA support and pointed them to this thread and question. Hope they'll be able to provide an answer.
It turns out that Manuel was mistaken and it is not known whether the next update will fix this or not.
Depends on: 1194230
Crashes for a bunch of people, tracking.
status-firefox40: --- → affected
tracking-firefox40: --- → +
Given the large fallout from this blocklist entry, general lack of understanding of this crash and lack of user reports of the crash, I think we should reenable HW accel on these cards.

I feel as though we may also have made an error about the significance of the paticular driver version because it's the default driver on Windows 10
Dave, Justin, this feels like a product call.  We have a few obvious choices:
1. Leave it blocklisted, safe, but sorry for people that weren't crashing
2. Take it all back, leave those crashes in place
3. Do a tighter blocklist - same driver version, but only some cards (e.g., top 5 cards, accounting for > 50% of the crashes.)

Thoughts?
Flags: needinfo?(dolske)
Flags: needinfo?(dcamp)
Flags: needinfo?(bas)
(In reply to Milan Sreckovic [:milan] from comment #27)
> Dave, Justin, this feels like a product call.  We have a few obvious choices:
> 1. Leave it blocklisted, safe, but sorry for people that weren't crashing

Just because some people hadn't crashed does not mean they wouldn't soon crash and I suspect they'd be just as upset (if not more) when they crashed. Is there some way we can do a "soft block" so that people have a way to re-enable HWA if they so please at their own risk?
Crash Signature: [@ nvwgf2um.dll@0x47c5d] [@ nvwgf2um.dll@0x69b75d ] → [@ nvwgf2um.dll@0x47c5d] [@ nvwgf2um.dll@0x69b75d] [@ nvwgf2um.dll@0x3c7ad]
(In reply to Milan Sreckovic [:milan] from comment #27)
> 3. Do a tighter blocklist - same driver version, but only some cards (e.g.,
> top 5 cards, accounting for > 50% of the crashes.)

"Top 5 cards" won't work, there seems to be no correlation between card model and crashiness. For example, I have a GTX660 and suffer from crashes, but several users of the same card reported no problem whatsoever on the NVIDIA feedback thread.
(In reply to Ronan Jouchet from comment #29)
> (In reply to Milan Sreckovic [:milan] from comment #27)
> > 3. Do a tighter blocklist - same driver version, but only some cards (e.g.,
> > top 5 cards, accounting for > 50% of the crashes.)
> 
> "Top 5 cards" won't work, there seems to be no correlation between card
> model and crashiness. For example, I have a GTX660 and suffer from crashes,
> but several users of the same card reported no problem whatsoever on the
> NVIDIA feedback thread.

Just to confirm, you see this crash on your hardware?
Flags: needinfo?(ronan)
(In reply to Jeff Muizelaar [:jrmuizel] from comment #30)
> (In reply to Ronan Jouchet from comment #29)
> > (In reply to Milan Sreckovic [:milan] from comment #27)
> > > 3. Do a tighter blocklist - same driver version, but only some cards (e.g.,
> > > top 5 cards, accounting for > 50% of the crashes.)
> > 
> > "Top 5 cards" won't work, there seems to be no correlation between card
> > model and crashiness. For example, I have a GTX660 and suffer from crashes,
> > but several users of the same card reported no problem whatsoever on the
> > NVIDIA feedback thread.
> 
> Just to confirm, you see this crash on your hardware?

I use Windows (10) only my gaming box, where I don't use Firefox (one less software to bother with; in-Steam browser and Edge are good enough for the occasional Google search).

- What I *do* have are ingame crashes in recent DirectX games.
- To try to answer your question regarding Firefox: I installed the latest 40.0 stable and let it watch HD YouTube videos with HW accel on for 15 minutes, but didn't experience any crash. I'm pretty sure HW accel was on (blacklist not downloaded yet?): the box was checked, there was no lag, and CPU usage stayed at 1%.
Flags: needinfo?(ronan)
Attached image Crash Trend — 
Attached is a chart visualizing the 10 days of crashes in nvwgf2um before and after Windows 10's release. It shows that these crashes are not really any worse because of Windows 10 or the latest nVidia driver. Based on this new data I am reversing my opinion and suggest we pull back the block.
NVIDIA just published a new Windows 10 driver (355.60) containing "bug fixes and increased stability in some games reported by customers ". Those concerned by the crashes should give it a try; download it via GeForce Experience, or at http://www.geforce.com/drivers
I updated to the new drivers,but sadly Firefox still blocks them.I had no crash issues at all with the previous drivers too.
nasko_naskov can you post the graphics sections of your about:support?
Flags: needinfo?(nasko_naskov)
Depends on: 1194335
Jorge, we've decided against the blocklist entry. Can you remove it?
Flags: needinfo?(jorge)
Flags: needinfo?(dolske)
Flags: needinfo?(dcamp)
Done.
Flags: needinfo?(jorge)
@Jeff Sure.

Graphics
Adapter Description	NVIDIA GeForce GTX 970
Adapter Drivers	nvd3dumx,nvwgf2umx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um,nvwgf2um
Adapter RAM	4095
Asynchronous Pan/Zoom	none
Device ID	0x13c2
Direct2D Enabled	Blocked for your graphics driver version.
DirectWrite Enabled	false (10.0.10240.16430)
Driver Date	8-6-2015
Driver Version	10.18.13.5560
GPU #2 Active	false
GPU Accelerated Windows	1/1 Direct3D 11 WARP (OMTC)
Subsys ID	00000000
Supports Hardware H264 Decoding	false
Vendor ID	0x10de
WebGL Renderer	Google Inc. -- ANGLE (NVIDIA GeForce GTX 970 Direct3D11 vs_5_0 ps_5_0)
windowLayerManagerRemote	true
AzureCanvasBackend	skia
AzureContentBackend	cairo
AzureFallbackCanvasBackend	cairo
AzureSkiaAccelerated	0

Not sure why the driver date says the driver is from one week ago when it just came out today tho.
Flags: needinfo?(nasko_naskov)
Hi devs, thank you very much for reenabling HW acceleration with version 40.0.2, Firefox is finally usable again with no issues and top performance, I'm using Windows 10 and NVIDIA driver 355.60. Thank you.
(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #28)
> Is there some way we can do a "soft block" so that people have a way to
> re-enable HWA if they so please at their own risk?

Random related idea: Would it be possible to disable HWA for a user if the user had a crash with a HWA-relevant signature? If feasible it would allow disabling HWA only for affected users, at the cost of them seeing one crash.

The mechanism for doing this could be to push a conditional blacklist entry, meaning something like "blacklist this driver if your crash history has this crash signature".
(In reply to Alon Zakai (:azakai) from comment #40)
> ...
> The mechanism for doing this could be to push a conditional blacklist entry,
> meaning something like "blacklist this driver if your crash history has this
> crash signature".

Good idea - filed bug 1194742 for it.
Crash Signature: [@ nvwgf2um.dll@0x47c5d] [@ nvwgf2um.dll@0x69b75d] [@ nvwgf2um.dll@0x3c7ad] → [@ nvwgf2um.dll@0x47c5d] [@ nvwgf2um.dll@0x69b75d] [@ nvwgf2um.dll@0x3c7ad] [@ nvwgf2um.dll@0x39e5d] [@ nvwgf2um.dll@0x45d2d]
Assignee: nobody → bas
Ronan, have you had any success using the 355.60 drivers from NVIDIA, given that you reported crashing before?
Flags: needinfo?(ronan)
(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #43)
> Ronan, have you had any success using the 355.60 drivers from NVIDIA, given
> that you reported crashing before?

I'm not having these crashes, in comment 31 I highlight that I was only trying to add context, but am not affected.
Flags: needinfo?(ronan)
In one of the minidumps that I checked there was a single rect with dimensions (0,0,39,1920)
the other one had:
	{{top=97 bottom=301 left=25 right=663},
         {top=301 bottom=319 left=25 right=308}}
(In reply to Ronan Jouchet from comment #44)
> I'm not having these crashes, in comment 31 I highlight that I was only
> trying to add context, but am not affected.

Okay thanks. 

Updating the stat analysis since it's been a while I'm getting some variances.

> [@ nvwgf2um.dll@0x47c5d ]
By platform, these are 100% on Windows 10.
By vendor, these are 100% on NVIDIA hardware.
By driver, these are 100% on the 353.* branch.

> [@ nvwgf2um.dll@0x69b75d ]
By platform, these are 100% on Windows 10
By vendor, these are 100% on systems with Intel cards but not NVIDIA cards.
By driver, these are 72% on the 9.17.10.* branch which is not officially supported on Windows 10.

> [@ nvwgf2um.dll@0x3c7ad ]
By platform, these crashes are 94% on Windows 10, 5% on Windows 8, and 1% on Windows 7
By vendor, these crashes are 100% on NVIDIA cards
By driver, these crashes are nearly 100% on the 341.* branch.

> [@ nvwgf2um.dll@0x39e5d ]
By platform, these crashes are nearly 100% on Windows 8 with zero crashes on Windows 10.
By vendor, these crashes are 100% on NVIDIA cards.
By driver, these crashes are 96% on the 327.02 version.

> [@ nvwgf2um.dll@0x45d2d ]
By platform, these are 100% on Windows 10.
By vendor, these are 100% on NVIDIA hardware.
By driver, these are 100% on the 353.30 version.

I've observed a couple things from this data. First, not all of these signatures are uniquely a Windows 10 issue, it may make sense to focus just on those isolated to Windows 10 in this bug. Second, there are no crashes with the latest NVIDIA driver version so maybe this has been "fixed" on NVIDIA's end. If so, maybe we can help this situation through outreach and blocking old drivers only for those affected.
(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #46)
> I've observed a couple things from this data. First, not all of these
> signatures are uniquely a Windows 10 issue, it may make sense to focus just
> on those isolated to Windows 10 in this bug. Second, there are no crashes
> with the latest NVIDIA driver version so maybe this has been "fixed" on
> NVIDIA's end. If so, maybe we can help this situation through outreach and
> blocking old drivers only for those affected.

Given this, it may be time to start working on a driver update notification system on windows.  Having people's hw accel get disabled without any information on how to fix it is not going to help us in the long term... we should be able to display something like "Due to stability issues with your currently installed graphics driver (353.55), we've disabled hardware acceleration in Firefox.  Please go to <geforce.com>|<Windows Update>|... to obtain the latest driver version." when the user starts and we first disable hw accel due to a blocklist update.
Agreed. I raised a similar suggestion to Milan in a recent 1:1. I'm not sure what progress has been made on that suggestion but perhaps that's best dealt with outside of this bug report. I'll leave it to Milan to comment further.
Yes, something like this was discussed with UX at Whistler.
(In reply to Milan Sreckovic [:milan] from comment #49)
> Yes, something like this was discussed with UX at Whistler.

Is that conversation continuing somewhere?
Did NVidia or Microsoft send out a graphics driver update? It looks like the second day in a row the volume of those crashes is decreasing in yesterday's data. That could still be a normal fluctuation (or even people leaving Firefox) but it also could be a good sign.
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #51)
> Did NVidia or Microsoft send out a graphics driver update?

According to nvidia.com, the latest WHQL driver is 355.82 which was released on August 31, 2015.
Tagging this as a topcrash. In combined signatures there have been over 12K reports in the last week for Firefox 40.0.3. This makes it the #2 topcrash overall @ 2.62%, #1 if we ignore OOM|small.

By driver, 97% of these crashes are with NVIDIA 353.62 (July 29, 2015) and there are no crashes with the latest WHQL driver released August 31, 2015.

As an added note, there are over 11K crashes with the latest driver but *this* does not seem to be one of them. Maybe this moved to another signature or maybe NVIDIA fixed this on their end. I'm not sure.
Keywords: topcrash-win
If we look at Win10 crashes only, this is by far the #1 with ~15% of all crashes.
(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #53)
> Tagging this as a topcrash. In combined signatures there have been over 12K
> reports in the last week for Firefox 40.0.3. This makes it the #2 topcrash
> overall @ 2.62%, #1 if we ignore OOM|small.
> 
> By driver, 97% of these crashes are with NVIDIA 353.62 (July 29, 2015) and
> there are no crashes with the latest WHQL driver released August 31, 2015.
> 
> As an added note, there are over 11K crashes with the latest driver but
> *this* does not seem to be one of them. Maybe this moved to another
> signature or maybe NVIDIA fixed this on their end. I'm not sure.

I want to take this up with NVidia, could you point me at some of the most serious crashes with the latest driver?
Flags: needinfo?(anthony.s.hughes)
Well, I expect that even if they don't fix the actual issue, the signature will change with every driver version they release, given that all we have as signatures is some addresses in the binary, and the binary changes, so the addresses change.
Crash Signature: [@ nvwgf2um.dll@0x47c5d] [@ nvwgf2um.dll@0x69b75d] [@ nvwgf2um.dll@0x3c7ad] [@ nvwgf2um.dll@0x39e5d] [@ nvwgf2um.dll@0x45d2d] → [@ nvwgf2um.dll@0x47c5d] [@ nvwgf2um.dll@0x69b75d] [@ nvwgf2um.dll@0x3c7ad] [@ nvwgf2um.dll@0x39e5d] [@ nvwgf2um.dll@0x45d2d] [@ nvwgf2um.dll@0x4d4f1]
Bas, here is the supersearch query for topcrashes in NVIDIA's 355.82 driver:
https://crash-stats.mozilla.com/search/?product=Firefox&adapter_driver_version=%3D10.18.13.5582&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature

Robert added nvwgf2um.dll@0x4d4f1 to *this* bug report which is the #2 crash on the list above. I guess that validates the theory that this moves to a new signature with every driver update.
Flags: needinfo?(anthony.s.hughes)
Clarifying my last comment, the supersearch query shows the topcrashes for users with the NVIDIA 355.82 driver; that's not to say that these are crashes *in* NVIDIA's driver.
There's another signature which just started to show up on September 12, 2015:
https://crash-stats.mozilla.com/report/list?signature=nvwgf2umx.dll%400x5c9bf

100% of the crashes are Windows 10 with NVIDIA 355.82.
40% of the crashes are on GeForce GTX 580 cards (GF110).

I'm not sure if this is the same issue or if it deserves its own bug report. One thing that's different about this signature is that there are no crashes on Firefox 40 or earlier. It appears on Firefox 41.0b8 and later.
(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #59)
> There's another signature which just started to show up on September 12,
> 2015:
> https://crash-stats.mozilla.com/report/list?signature=nvwgf2umx.dll%400x5c9bf

Those have mozilla::layers::DXGITextureHostD3D11::Unlock() as the last frame in our code, not mozilla::layers::CompositorD3D11::EndFrame() like in this bug - so if we want a bug on file on our side, it should be a new one.
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #60)
> (In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #59)
> > There's another signature which just started to show up on September 12,
> > 2015:
> > https://crash-stats.mozilla.com/report/list?signature=nvwgf2umx.dll%400x5c9bf
> 
> Those have mozilla::layers::DXGITextureHostD3D11::Unlock() as the last frame
> in our code, not mozilla::layers::CompositorD3D11::EndFrame() like in this
> bug - so if we want a bug on file on our side, it should be a new one.

Thanks KaiRo, I filed bug 1206210.
Jeff's working on a patch to disable partial present, which is the current theory as to what's exposing the driver bug.
Flags: needinfo?(jmuizelaar)
Yes. The patch is awaiting review in bug 1194335
Flags: needinfo?(jmuizelaar)
[Tracking Requested - why for this release]:

[Tracking Requested - why for this release]:
This (of course) is still an issue at the same volume for 41 as for 40 - actually, it feels like it's rising somewhat, but that's probably just because Win10 usage is climbing.

We should track this to make sure we land the bug 1194335 patch where possible once it's stable/good/fast enough.
tracking-firefox41: --- → ?
tracking-firefox42: --- → ?
tracking-firefox43: --- → ?
Tracking as it is an important crash (but hopefully fixed).
status-firefox43: --- → affected
tracking-firefox41: ? → +
tracking-firefox42: ? → +
tracking-firefox43: ? → +
Has this moved in volume on Nightly since landing bug 1194335?
Flags: needinfo?(kairo)
(In reply to Jeff Muizelaar [:jrmuizel] from comment #66)
> Has this moved in volume on Nightly since landing bug 1194335?

No, but the volume on Nightly was always very low, and actually there were none of those crashes for a few days before this, but there have been some days without that crash on Nightly for a few times. It's hard to diagnose this on any channel below beta.
Flags: needinfo?(kairo)
And actually, I think I mated the question badly in comment #67. Actually, what I meant to say is that the signature has not occurred since then - so, yes, it has moved. And, BTW, this is still true today on Nightly, so it may very well have helped or fixed this and we probably should try uplifting.
Asking for an uplift in bug 1194335.  The volume of the crash is too high for us to let performance trump the stability.
Looks like it is (almost) fixed! We only had one crash with 42.0b8, none with 42.0b9.
Congrat!
Yes, this seems to have been "fixed" successfully by the patch in bug 1194335. I'm marking it "disabled" as that patch actually disabled the code triggering the driver crashes.
status-firefox42: affected → disabled
status-firefox43: affected → disabled
Calling this FIXED by disabling the code. Please reopen if there's something we actually want to fix in this bug.
Status: NEW → RESOLVED
Closed: 9 years ago
status-firefox41: affected → wontfix
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: