A user on reddit reports that 37.0.1 is crashing on startup. He reports the following: > I can only start Firefox in safe mode. Disabling all add-ons, unchecking "use hardware acceleration", refreshing Firefox, and even uninstalling and reinstalling the browser have not worked. > Edit: Update: just tried a clean install (including removing everything in AppData) and it still crashes. He later reported that it actually crashes during the refresh. He also reports that updating his graphic drivers did not help. I'm attaching the crash report signature he provided and will encourage him to CC himself here. You can see the original post (and potential updates) as well as interact here: http://www.reddit.com/r/firefox/comments/31jub5/firefox_3701_crashes_on_startup_typical_fixes_not/

FYI, there are 258 crashes with this signature in the last week (500 in the last month), all Win7 (no surprise there). GFX adapter *seems* to be mostly Intel and AMD/Radeon

In the startup crash in bug 1149761 (fixed in 37.0.1), we were not dealing with the failed call to "D3D11CreateDevice" (from d3d11.dll). In this bug, we crash in the call to D3D11CreateDevice instead, before we would get to the failure of bug 1149761. There was some mention out there of uninstalling something called Sendori removing a similar crash with IE. No clue if it's related to this one yet.

It'd be good to see if there is a driver/hardware correlation here.

Does setting layers.d3d11.disable-warp to true make the crash go away?

(In reply to Milan Sreckovic [:milan] from comment #5) > Does setting layers.d3d11.disable-warp to true make the crash go away?

Assuming I've done my math correctly, the original reporter of this issue is zdeno (I'll confirm on reddit). Zdeno, does setting layers.d3d11.disable-warp (in about:config) to true make the crash go away? I saw you downgraded to 36, just a reminder, that you can install 37 separately (instead of on top of). During the install process, you can click "custom install" (something to that effect) and choose a separate directory to install 37 into. Though you may want to rename your shortcuts so they don't get updated to point at 37.

That fixed it! Thanks a lot. (In reply to Caspy7 from comment #7) > Assuming I've done my math correctly, the original reporter of this issue is > zdeno (I'll confirm on reddit). > > Zdeno, does setting layers.d3d11.disable-warp (in about:config) to true make > the crash go away? > > I saw you downgraded to 36, just a reminder, that you can install 37 > separately (instead of on top of). During the install process, you can click > "custom install" (something to that effect) and choose a separate directory > to install 37 into. Though you may want to rename your shortcuts so they > don't get updated to point at 37.

[Tracking Requested - why for this release]: Not a high volume, but a startup crash. We could block D3D11, but I'm unclear if doing that actually also blocks D3D11 WARP, and also not sure what the correlation is for the blocking. Either way, should do something. Lawrence, how do we tell people about the workaround of running in safe mode, about:config to set layers.d3d11.disable-warp to true?

We can create a SUMO article that describes the issue and how to disable WARP.

Tracking this start-up crash.

If it means anything - this crash happened when D3D11 tried to QI a pointer for IDXGIAdapter2, got back a null, and dereferenced it without checking the hr. Does that help at all?

Bas may be able to do something with that info, thanks David. That's all happening outside of our code, so we're hitting a bug in D3D11, but perhaps there is a way to avoid setting the call up to trigger that bug.

(In reply to David Major [:dmajor] from comment #12) > If it means anything - this crash happened when D3D11 tried to QI a pointer > for IDXGIAdapter2, got back a null, and dereferenced it without checking the > hr. Does that help at all? Does this mean you're able to reproduce this bug? :)

No, it just means I found a GUID and a very typical COM pattern in the disassembly :)

Does this build fix the issue for people? https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/bschouten@mozilla.com-d6587e8b72d1

(In reply to David Major [:dmajor] from comment #15) > No, it just means I found a GUID and a very typical COM pattern in the > disassembly :) Shame, it would've been nice to know where it's getting the adapter from, if we can figure it out we may be able to check for it manually.

Here's another build that I'd like people who experience this bug to try: https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/bschouten@mozilla.com-67c7f5c6d4f1

Zdeno, in trying to fix this issue for all users (and allowing all the preferred technologies to be enabled on your browser) would you use the installer from the link that Bas provided above in comment 18 to install that special build with a potential fix? Then set layers.d3d11.disable-warp to false and restart the browser. Please report back if the crash persists or goes away. Thanks!

Hi Caspy7, The crash persists when layers.d3d11.disable-warp is set to false, even on that build.

Can anyone try: https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/bschouten@mozilla.com-d6587e8b72d1 As well?

My guess is that this is caused by a version mismatch between D3D10Warp.dll and d3d11.dll. Dmajor can you get a histogram of d3d11.dll, d3d10warp.dll version pairs for this crash and one for the general public?

I can't do pairs but we can probably just look at them individually. In a nutshell, the crashing population all have d3d11 from 9200, but are split between 7601 and 9200 versions of d3d10warp. 96% (214/222) vs. 12% (6970/59423) D3D10Warp.dll 0% (0/222) vs. 0% (3/59423) 10.0.10041.0 0% (0/222) vs. 0% (1/59423) 10.0.10049.0 0% (0/222) vs. 0% (3/59423) 10.0.9926.0 0% (0/222) vs. 0% (4/59423) 6.1.7100.0 0% (0/222) vs. 2% (1023/59423) 6.1.7600.16385 0% (0/222) vs. 0% (62/59423) 6.1.7600.16699 0% (0/222) vs. 0% (5/59423) 6.1.7600.16961 0% (0/222) vs. 0% (170/59423) 6.1.7600.16972 0% (0/222) vs. 0% (2/59423) 6.1.7600.20781 0% (0/222) vs. 0% (2/59423) 6.1.7600.20830 0% (0/222) vs. 0% (3/59423) 6.1.7600.21162 0% (0/222) vs. 0% (3/59423) 6.1.7601.16562 55% (121/222) vs. 2% (991/59423) 6.1.7601.17514 0% (0/222) vs. 0% (5/59423) 6.1.7601.17702 0% (0/222) vs. 0% (1/59423) 6.2.8102.0 0% (0/222) vs. 0% (20/59423) 6.2.9200.16384 0% (0/222) vs. 0% (10/59423) 6.2.9200.16420 0% (0/222) vs. 0% (9/59423) 6.2.9200.16440 0% (1/222) vs. 1% (337/59423) 6.2.9200.16492 3% (6/222) vs. 1% (546/59423) 6.2.9200.16783 0% (0/222) vs. 0% (14/59423) 6.2.9200.16795 39% (86/222) vs. 5% (2857/59423) 6.2.9200.17033 0% (0/222) vs. 0% (1/59423) 6.3.9431.0 0% (0/222) vs. 0% (25/59423) 6.3.9600.16384 0% (0/222) vs. 0% (19/59423) 6.3.9600.16505 0% (0/222) vs. 0% (46/59423) 6.3.9600.17211 0% (0/222) vs. 0% (112/59423) 6.3.9600.17415 0% (0/222) vs. 0% (1/59423) 6.4.9841.0 0% (0/222) vs. 0% (2/59423) 7.0.6002.18107 0% (0/222) vs. 0% (20/59423) 7.0.6002.18392 0% (0/222) vs. 0% (1/59423) 7.0.6002.18582 0% (0/222) vs. 0% (22/59423) 7.0.6002.18592 0% (0/222) vs. 0% (2/59423) 7.0.6002.23097 0% (0/222) vs. 1% (648/59423) 7.0.6002.23200 100% (222/222) vs. 65% (38504/59423) d3d11.dll 0% (0/222) vs. 0% (1/59423) 10.0.10036.0 0% (0/222) vs. 0% (64/59423) 10.0.10041.0 0% (0/222) vs. 0% (32/59423) 10.0.10049.0 0% (0/222) vs. 0% (2/59423) 10.0.10051.0 0% (0/222) vs. 0% (1/59423) 10.0.10054.0 0% (0/222) vs. 0% (34/59423) 10.0.9926.0 0% (0/222) vs. 0% (4/59423) 6.1.7100.0 0% (0/222) vs. 0% (2/59423) 6.1.7600.16384 0% (0/222) vs. 6% (3769/59423) 6.1.7600.16385 0% (0/222) vs. 0% (1/59423) 6.1.7601.16537 0% (0/222) vs. 0% (1/59423) 6.1.7601.16556 0% (0/222) vs. 0% (10/59423) 6.1.7601.16562 0% (0/222) vs. 0% (2/59423) 6.1.7601.17105 0% (0/222) vs. 6% (3474/59423) 6.1.7601.17514 0% (0/222) vs. 0% (18/59423) 6.2.8102.0 0% (0/222) vs. 0% (2/59423) 6.2.8250.0 0% (0/222) vs. 0% (2/59423) 6.2.8400.0 0% (0/222) vs. 0% (202/59423) 6.2.9200.16384 0% (0/222) vs. 0% (6/59423) 6.2.9200.16399 0% (0/222) vs. 0% (125/59423) 6.2.9200.16420 0% (0/222) vs. 0% (19/59423) 6.2.9200.16440 0% (0/222) vs. 1% (301/59423) 6.2.9200.16492 100% (222/222) vs. 35% (20988/59423) 6.2.9200.16570 0% (0/222) vs. 1% (753/59423) 6.2.9200.16699 0% (0/222) vs. 0% (1/59423) 6.2.9200.20521 0% (0/222) vs. 0% (9/59423) 6.2.9200.20807 0% (0/222) vs. 0% (1/59423) 6.3.9431.0 0% (0/222) vs. 0% (99/59423) 6.3.9600.16384 0% (0/222) vs. 0% (45/59423) 6.3.9600.16408 0% (0/222) vs. 0% (46/59423) 6.3.9600.16419 0% (0/222) vs. 0% (118/59423) 6.3.9600.16421 0% (0/222) vs. 0% (3/59423) 6.3.9600.16610 0% (0/222) vs. 0% (94/59423) 6.3.9600.17031 0% (0/222) vs. 4% (2411/59423) 6.3.9600.17041 0% (0/222) vs. 0% (14/59423) 6.3.9600.17393 0% (0/222) vs. 8% (4891/59423) 6.3.9600.17415 0% (0/222) vs. 0% (4/59423) 6.4.9841.0 0% (0/222) vs. 0% (2/59423) 6.4.9879.0 0% (0/222) vs. 2% (953/59423) 7.0.6002.18107

All of the reports that I've looked at had mismatches. Sometimes WARP matched by dxgi did not.

There are definitely crashes that don't have as big a version mismatch: https://crash-stats.mozilla.com/report/index/936f54dc-e195-42d5-a97a-a3a1b2150407

Over the shoulder review by jrmuizel.

Comment on attachment 8592510 [details] [diff] [review] Wrap D3D11 WARP device creation in a try catch block Approval Request Comment [Feature/regressing bug #]: 1102499 [User impact if declined]: Some rare machines will crash upon startup [Describe test coverage new/current, TreeHerder]: Local testing only [Risks and why]: Very low, exception handling only [String/UUID change made/needed]: None

Comment on attachment 8592510 [details] [diff] [review] Wrap D3D11 WARP device creation in a try catch block Lawrence mentioned during the last channel meeting that he wants to take it. I am going to approve it now to make sure it lands asap for 37.0.2 Should be also in 38 beta 5.

Jeff, Milan and I discussed disabling WARP in 37 yesterday. This looks to be a fix. Do you expect that this fix will catch all of the cases? What potential issues do you see with this change? Is it safer to simply disable WARP in 37?

(In reply to Lawrence Mandel [:lmandel] (use needinfo) from comment #33) > Jeff, Milan and I discussed disabling WARP in 37 yesterday. This looks to be > a fix. Do you expect that this fix will catch all of the cases? What > potential issues do you see with this change? Is it safer to simply disable > WARP in 37? Bas, Milan and I discussed this yesterday. This is a lower risk change because most users won't notice a difference, but the users that are crashing should fall back to the non-WARP path. We agreed that this, while having a slightly different risk profile, was the wiser choice.

Thank you for the clarification. We'll take this change in 37.0.2.

Zdeno, would you be willing to test this build out? https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/bschouten@mozilla.com-d6587e8b72d1/try-win32/ You can just choose the installer ( firefox-40.0a1.en-US.win32.installer.exe ). Remember to set layers.d3d11.disable-warp to false and restart. Thanks!

Hi Caspy7, That build works with layers.d3d11.disable-warp set to false.

We now have build 37.0.2 created - https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/37.0.2-candidates/build1/win32/en-US/Firefox%20Setup%2037.0.2.exe Zdeno, would you be willing to install it and see that it does not crash on startup? I think you would need to also set layers.d3d11.disable-warp to false and restart, as indicated in comment 37.

Hi Florin, Build 37.0.2 does not crash when layers.d3d11.disable-warp is set to false. Thanks!

Many thanks Zdeno! Marking as verified.

relnoted as "Stability fixes for select graphics hardware and feature sets". Takes into account this bug, bug 1151721 and bug 1137716.