Graphics driver crashes happen from time to time but there's a spike in driver crashes starting in 23.0a1/20130507 making it #5 top browser crasher in 23.0a2. The regression range for the spike might be (worst case because not same begin buildID depending on signature): http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b109e2dbf03b&tochange=b842d26dd5f0 I suspect bug 867844 in this range. Here are interesting correlations in 23.0a2: igdumd32.dll@0x430b4f|EXCEPTION_ACCESS_VIOLATION_READ (34 crashes) 100% (34/34) vs. 11% (219/1942) _etoured.dll (NVIDIA CoProcManager) igdumd32.dll@0x4a8b3f|EXCEPTION_ACCESS_VIOLATION_READ (23 crashes) 100% (23/23) vs. 11% (219/1942) _etoured.dll nvumdshim.dll@0xd706|EXCEPTION_ACCESS_VIOLATION_READ (20 crashes) 100% (20/20) vs. 5% (99/1942) D3Dx10_40.dll (9.24.950.2656) 100% (20/20) vs. 11% (219/1942) _etoured.dll igdumd32.dll@0x43606f|EXCEPTION_ACCESS_VIOLATION_READ (18 crashes) 100% (18/18) vs. 11% (207/1942) sqmapi.dll 72% (13/18) vs. 5% (103/1942) 6.1.7600.16385 28% (5/18) vs. 5% (104/1942) 6.1.7601.17514 100% (18/18) vs. 11% (219/1942) _etoured.dll igdumd32.dll@0x436b4f|EXCEPTION_ACCESS_VIOLATION_READ (16 crashes) 100% (16/16) vs. 11% (219/1942) _etoured.dll igdumd32.dll@0x432ecf|EXCEPTION_ACCESS_VIOLATION_READ (13 crashes) 100% (13/13) vs. 11% (219/1942) _etoured.dll nvumdshim.dll@0xe226|EXCEPTION_ACCESS_VIOLATION_READ (13 crashes) 69% (9/13) vs. 11% (219/1942) _etoured.dll igdumd32.dll@0x432adf|EXCEPTION_ACCESS_VIOLATION_READ (12 crashes) 100% (12/12) vs. 11% (219/1942) _etoured.dll Signature igdumd32.dll@0x430b4f More Reports Search UUID 4fcc53bb-8075-41b0-9461-80ee82130531 Date Processed 2013-05-31 17:17:24 Uptime 7 Last Crash 20.3 hours before submission Install Age 20.3 hours since version was first installed. Install Time 2013-05-30 20:56:31 Product Firefox Version 24.0a1 Build ID 20130530031141 Release Channel nightly OS Windows NT OS Version 6.1.7601 Service Pack 1 Build Architecture x86 Build Architecture Info GenuineIntel family 6 model 42 stepping 7 Crash Reason EXCEPTION_ACCESS_VIOLATION_READ Crash Address 0x8 App Notes AdapterVendorID: 0x8086, AdapterDeviceID: 0x0116, AdapterSubsysID: 04c41028, AdapterDriverVersion: 8.15.10.2253 Has dual GPUs. GPU #2: AdapterVendorID2: 0x10de, AdapterDeviceID2: 0x0df5, AdapterSubsysID2: 04c41028, AdapterDriverVersion2: 8.17.12.6594D2D? D2D+ DWrite? DWrite+ D3D10 Layers? D3D10 Layers+ Processor Notes sp-processor01_phx1_mozilla_com_15876:2012 EMCheckCompatibility True Adapter Vendor ID 0x8086 Adapter Device ID 0x0116 Total Virtual Memory 4294836224 Available Virtual Memory 3511320576 System Memory Use Percentage 44 Available Page File 6307057664 Available Physical Memory 2316423168 Frame Module Signature Source 0 igdumd32.dll igdumd32.dll@0x430b4f More reports at: https://crash-stats.mozilla.com/query/query?product=Firefox&query_search=signature&query_type=startswith&query=ig&do_query=1 https://crash-stats.mozilla.com/query/query?product=Firefox&query_search=signature&query_type=startswith&query=nv&do_query=1

I would think the various graphics changes in the range are more likely...

(In reply to Boris Zbarsky (:bz) from comment #1) > I would think the various graphics changes in the range are more likely... bug 804144, a blocklist?

CCing Benoît who knows side effects of some graphics blocklists.

This does not seem to be a "unintended consequences of adding a blocklist rule" caused by bug 804144: the crash report in comment 0 is with firefox 24, not an older version that wouldn't know about windows 8. Also, the rule added in bug 804144 was on a particular device ID, 0x0046, that does not patch the one here (0x0116).

Here is the breakdown per Intel driver version in 23.0a2: 8.15.10.2253 34 8.15.10.2272 12 8.15.10.2274 13 8.15.10.2291 19 8.15.10.2342 22 8.15.10.2361 23 8.15.10.2401 3 8.15.10.2509 3 8.15.10.2559 17 8.15.10.2622 2 8.15.10.2696 1 The devices IDs are mainly 0x0046, 0x116, 0x126 for Intel driver crashes.

64-bit crashes make me think it happen one build later, 23.0a1/20130508 (see https://crash-stats.mozilla.com/report/list?signature=nvwgf2umx.dll%400x11bb4). If it was the case, the regression range would be: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b842d26dd5f0&tochange=b980d32c366f My guess in that long range is bug 830347.

Bas - can you speak to the likelihood that this is indeed caused by bug 830347 and if so, what the options are here? Would be nice to get a handle on this before going to Beta in 2 weeks.

(In reply to lsblakk@mozilla.com [:lsblakk] from comment #7) > Bas - can you speak to the likelihood that this is indeed caused by bug > 830347 and if so, what the options are here? Would be nice to get a handle > on this before going to Beta in 2 weeks. Extremely unlikely, none of that code is run at the moment, it's all preffed off and I don't see any way off the top of my head the bug could affect the control flow when preffed off. Unless of course a -lot- of people are manually switching this pref, which seems extremely unlikely.

What does this look like now? Can you help with data to reason about overall volume for combined crashes?

Can we send this to our nvidia friends, and see if they have any ideas? (Drop me an email if you need contacts there)

(In reply to lsblakk@mozilla.com [:lsblakk] from comment #9) > What does this look like now? Can you help with data to reason about > overall volume for combined crashes? In 23.0b2 at 6H UTC, there are 1029 nv*.dll crashes and 452 ig*.dll crashes making it #4 browser crasher in this version. For 22.0, there are 1285 nv*.dll crashes and 1509 ig*.dll crashes ie it's #10 browser crasher. It's also #5 browser crasher in 24.0a2 and #3 in 25.0a1. The regression is not obvious for both signature patterns. If restricted to the NVIDIA DLL, it's #22 in 22.0, #5 in 23.0b2, #6 in 24.0a2 and #3 in 25.0a1. In 23.0b1, I don't see comments proving it's a new issue in 23.0. Considering the regression is small and above all signatures might be unrelated issues, I am tempted to close it as invalid.

I have an issue like this and it the nVidia crash only seems to occur when "hardware acceleration" is enabled in the Firefox Advanced options. When it is disabled the issue completely resolves.

(In reply to bob.marietta from comment #12) > I have an issue like this and it the nVidia crash Is this something you have on Firefox 23 and not Firefox 22? What are your steps to reproduce?

I'm sorry this is happening in FireFox 22. I posted here because I suspect the issue I was experiencing was related. Here my bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=898932

Marking status for FF22 as 'affected' based on comment 14.

(In reply to lsblakk@mozilla.com [:lsblakk] from comment #15) > Marking status for FF22 as 'affected' based on comment 14. This bug tracks a spike (see comment 11) not all driver crashes.

Right now, it's not in topcrash ranks (but it might spike again).

The current incantation of this on 27.0a2, though not a topcrasher, is crashing at youtube.com in nvwgf2um.dll@0x100bba with the add-on from http://www.plus-hd.com/ installed and plugin Shockwave Flash Version:11.9.900.117 Filename:NPSWF32_11_9_900_117.dll

I wonder if this has any value in continuing to be tracked like this. It seems like this bug hasn't had any eyes on it in nearly a couple years.

It's a bit stale, yes.

(In reply to Milan Sreckovic [:milan] from comment #20) > It's a bit stale, yes. I'm going to close this bug then. Please reopen if you find there's some use for it.