[Tracking Requested - why for this release]: This bug was filed from the Socorro interface and is report bp-e1b21510-7d02-4166-a5db-856232150415. ============================================================= Stack: 0 xul.dll mozilla::layers::CompositorD3D11::Initialize() gfx/layers/d3d11/CompositorD3D11.cpp 1 xul.dll mozilla::layers::CompositorParent::InitializeLayerManager(nsTArray<mozilla::layers::LayersBackend> const&) gfx/layers/ipc/CompositorParent.cpp 2 xul.dll mozilla::layers::CompositorParent::AllocPLayerTransactionParent(nsTArray<mozilla::layers::LayersBackend> const&, unsigned __int64 const&, mozilla::layers::TextureFactoryIdentifier*, bool*) gfx/layers/ipc/CompositorParent.cpp GFX Adapters: 0x8086 0x0046 846 84.685 % Intel Corporation 3150 Intel Media Accelerator 3150 144 14.414 % Intel Corporation Intel G33 Intel(R) G33 chipset GMA3100 video Driver 4 0.400 % [and a few others with single hits] This startup crash isn't there in any significant volume in 37 but is present visibly in 38 beta. We should solve it before it hits us on release.

I'm seeing a few intel gfx driver crashes in this triage period. Is this something you're aware of in the TO office?

Potential important issue with the 37 release, tracking

All of these are dual GPU Intel+Nvidia, and only Win7 and Win7SP1. This started on Aurora in 20150403004008, which was the day that the typo fix for bug 1137716 landed there. From a quick spot-check, all of the AdapterDriverVersion2 appear to be within the blocklist range. So did the blocklisting just move the crash to a different place?

38 crashes on the machine that I have of this character. 37 does not.

Jeff, any idea how we could progress on this? Thanks

I'll debug it tomorrow.

So dxgiFactory is NULL probably because the nvidia driver is screwing with things.

I think this is probably caused by bug 1147728. We should probably invest in WARP blacklisting. In this case we can probably block WARP if nvdxgi wrap is loaded.

Try: https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/bschouten@mozilla.com-e445cf5edb66

(In reply to Bas Schouten (:bas.schouten) from comment #9) > Try: > https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/ > bschouten@mozilla.com-e445cf5edb66 This build still crashes

(In reply to Jeff Muizelaar [:jrmuizel] from comment #10) > (In reply to Bas Schouten (:bas.schouten) from comment #9) > > Try: > > https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/ > > bschouten@mozilla.com-e445cf5edb66 > > This build still crashes Can you take the patch and look at where this particular build crashes? I'm curious.

Jeff, please fill the uplift request. Thanks!

Approval Request Comment [Feature/regressing bug #]: bug 1147728 [User impact if declined]: Startup crash [Describe test coverage new/current, TreeHerder]: None [Risks and why]: Small patch, low risk. Should cause us to the same path as we do on 37

Comment on attachment 8598724 [details] [diff] [review] 546210eeaf4a [Triage Comment] Should be in 38 beta 9

Hrm, 38.0b9 should have this patch, but it still crashes with this signature. :(

In early 38.0 release data this crash is huge volume (more than 3x OOM|small). ni? to Lawrence as a heads up. (In reply to Pulsebot from comment #12) > https://hg.mozilla.org/integration/mozilla-inbound/rev/546210eeaf4a The file to block should be nvdxgiwrap.dll, not nvdxgiwrapper.dll.

[Tracking Requested - why for this release]: We should track this for all current releases (not nominating for 41, as it hopefully is fixed once inbound merges to central). dmajor, can you please request uplift to all channels, aurora/beta/release?

[Tracking Requested - why for this release]: Ah, probably ESR as well.

Comment on attachment 8604939 [details] [diff] [review] Typo fix I should point out that I am not an expert on this code. I'm just stepping in to fix the typo. I think it's reasonable to expect this fix to work, but we don't have any firsthand experience on how the affected machines will react to it. I do agree that we should get this merged though, because it can't really make things any worse. Approval Request Comment [Feature/regressing bug #]: bug 1147728 [User impact if declined]: Persistent startup crash [Describe test coverage new/current, TreeHerder]: none [Risks and why]: see above [String/UUID change made/needed]: none

I'm agree with what David said in comment 26 but would still much prefer to verify the fix before building 38.0.1 to do our best to ensure that we don't end up in the same position after another release Jeff, as per comment 10, you have a machine that crashes due to this bug. Can you reproduce the bug with Firefox 38? If so, can you try to apply the patch and ensure that this fix is good before we proceed to build 38.0.1?

I can reproduce the bug with FF38. I tried this build: https://hg.mozilla.org/integration/mozilla-inbound/rev/0dc1b8aadb57 and it did not crash.

Comment on attachment 8604939 [details] [diff] [review] Typo fix One review should be enough; there is no nvdxgiwrapper.dll, it should have been nvdxgiwrap.dll all along.

Comment on attachment 8604939 [details] [diff] [review] Typo fix Correction to dll name. Simple change. So much damage. Approved for landing across the board. Note that release is both 38.0.5 and 38.0. The 38.0 change will need to land on a relbranch.

Fx 40: https://hg.mozilla.org/releases/mozilla-aurora/rev/8669967982be Fx 39: https://hg.mozilla.org/releases/mozilla-beta/rev/88503bc88c21 Fx 38.0.5 (default): https://hg.mozilla.org/releases/mozilla-release/rev/fff54632eedd Fx 38.0.1 (GECKO380_2015050320_RELBRANCH) https://hg.mozilla.org/releases/mozilla-release/rev/d204dd3fd48b ESR 38.1 (default): https://hg.mozilla.org/releases/mozilla-esr38/rev/fd7049c777c8 ESR 38.0.1 (GECKO380esr_2015050513_RELBRANCH): https://hg.mozilla.org/releases/mozilla-esr38/rev/c93359b413ac

Release Note Request (optional, but appreciated) [Why is this notable]: Fixed a startup crash [Suggested wording]: Fixed: Systems with first generation NVidia Optimus graphics cards may crash on start-up [Links (documentation, blog post, etc)]:

Jeff, since you reproduced this locally, could you please verify this fix with: Firefox 38.0.1 - ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/38.0.1-candidates/build1/win32/en-US/ Firefox 38.0.1 ESR - ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/38.0.1esr-candidates/build1/win32/en-US/

Both of those builds work.

Updating flags according to Comment 35.

The latest nvidia drivers 352.86, which were released today, mention having fixed a start-up crash in Firefox on Optimus systems. Not sure if it is referring to this bug, but I just wanted to throw it out there. http://us.download.nvidia.com/Windows/352.86/352.86-win8-win7-winvista-desktop-release-notes.pdf

That's a good tip Trevor, we'll check if this fixes it without our patch, and we can then perhaps narrow the blocklisting.