1089364 - Crash in mozilla::layers::CompositorD3D11::HandleError

Status: VERIFIED FIXED

(Core :: Graphics, defect)

Description

[Ryan Jones-Ward [:sciguyryan]]

Hey guys.

I've been noting a strange intermittent crash since the nightly for the 24th of October. I had not seen this specific one before that (confirmed by examining my recent about:crashes reports).

A few examples of the crashes are as follows:
https://crash-stats.mozilla.com/report/index/cbb50220-7fc5-4517-8c1b-876722141024
https://crash-stats.mozilla.com/report/index/0da00c62-0a3f-4482-9675-5772e2141026
https://crash-stats.mozilla.com/report/index/9931dea8-8d93-44aa-8a58-8522b2141026
https://crash-stats.mozilla.com/report/index/696ca7ed-82f0-4fbd-8485-73c862141026
https://crash-stats.mozilla.com/report/index/dd520996-0620-47ef-8f6a-341252141026

This crash usually seems to happen when switching back to the Nightly browser window via the task bar. I am unable to explicit reproduce it but it does happen frequently as is demonstrated by the above.

Since it seems to be releated to graphics I will also include a copy of the graphics information from about:support below. If you need anything else, just let me know.

Adapter Description	NVIDIA GeForce GTX 780
Adapter Drivers	nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um
Adapter RAM	3072
Device ID	0x1004
Direct2D Enabled	true
DirectWrite Enabled	true (6.2.9200.16571)
Driver Date	10-16-2014
Driver Version	9.18.13.4448
GPU #2 Active	false
GPU Accelerated Windows	1/1 Direct3D 11 (OMTC)
Subsys ID	104b10de
Vendor ID	0x10de
WebGL Renderer	Google Inc. -- ANGLE (NVIDIA GeForce GTX 780 Direct3D9Ex vs_3_0 ps_3_0)
windowLayerManagerRemote	true
AzureCanvasBackend	direct2d
AzureContentBackend	direct2d 1.1
AzureFallbackCanvasBackend	cairo
AzureSkiaAccelerated	0

Comment 1

[Nicolas Silva [:nical]]

My guess is that we are doing something wrong (or something that doesn't account for what can happen when the window is going back and forth between hidden and shown) in CompositorD3D11::VerifyBufferSize. This part is missing some error checking so I'll add it and we'll see if we can narrow down the error (I doubt that the mSwapChain->GetBuffer call is the real problem, I think we get into an invalid state just before that).

Comment 3

[juan becerra [:juanb]]

[Tracking Requested - why for this release]: Number 2 top crasher in nigthly 36. 

Currently #2 in the list of top crashers for nightly 36. It's a recent signature. It started happening on 10/24. There are only three builds showing in the list, and nothing further than 10/25.

It's got lots of comments including some saying people are watching video in youtube using the html5 version, or resizing the browser window, or installing updates to their graphics card drivers. 

More reports at: https://crash-stats.mozilla.com/report/list?product=Firefox&signature=mozilla%3A%3Alayers%3A%3ACompositorD3D11%3A%3AHandleError%28long%2C+mozilla%3A%3Alayers%3A%3ACompositorD3D11%3A%3ASeverity%29

0 	xul.dll 	mozilla::layers::CompositorD3D11::HandleError(long, mozilla::layers::CompositorD3D11::Severity) 	gfx/layers/d3d11/CompositorD3D11.cpp
1 	xul.dll 	mozilla::layers::CompositorD3D11::Failed(long, mozilla::layers::CompositorD3D11::Severity) 	gfx/layers/d3d11/CompositorD3D11.cpp
2 	xul.dll 	mozilla::layers::CompositorD3D11::UpdateRenderTarget() 	gfx/layers/d3d11/CompositorD3D11.cpp
3 	xul.dll 	mozilla::layers::CompositorD3D11::BeginFrame(nsIntRegion const&, mozilla::gfx::RectTyped<mozilla::gfx::UnknownUnits> const*, mozilla::gfx::RectTyped<mozilla::gfx::UnknownUnits> const&, mozilla::gfx::RectTyped<mozilla::gfx::UnknownUnits>*, mozilla::gfx::RectTyped<mozilla::gfx::UnknownUnits>*) 	gfx/layers/d3d11/CompositorD3D11.cpp
4 	xul.dll 	mozilla::layers::LayerManagerComposite::Render() 	gfx/layers/composite/LayerManagerComposite.cpp
5 	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
6 	xul.dll 	mozilla::layers::LayerManagerComposite::EndEmptyTransaction(mozilla::layers::LayerManager::EndTransactionFlags) 	gfx/layers/composite/LayerManagerComposite.cpp
7 	xul.dll 	mozilla::layers::CompositorParent::CompositeToTarget(mozilla::gfx::DrawTarget*, nsIntRect const*) 	gfx/layers/ipc/CompositorParent.cpp
8 	xul.dll 	mozilla::layers::CompositorParent::CompositeCallback(mozilla::TimeStamp) 	gfx/layers/ipc/CompositorParent.cpp
9 	xul.dll 	RunnableMethod<mozilla::layers::CompositorParent, void ( mozilla::layers::CompositorParent::*)(mozilla::TimeStamp), Tuple1<mozilla::TimeStamp> >::Run() 	ipc/chromium/src/base/task.h
10 	xul.dll 	MessageLoop::RunTask(Task*) 	ipc/chromium/src/base/message_loop.cc
11 	xul.dll 	MessageLoop::DeferOrRunPendingTask(MessageLoop::PendingTask const&) 	ipc/chromium/src/base/message_loop.cc
12 	xul.dll 	MessageLoop::DoWork() 	ipc/chromium/src/base/message_loop.cc
13 	xul.dll 	base::MessagePumpForUI::DoRunLoop() 	ipc/chromium/src/base/message_pump_win.cc
14 	xul.dll 	base::MessagePumpWin::RunWithDispatcher(base::MessagePump::Delegate*, base::MessagePumpWin::Dispatcher*) 	ipc/chromium/src/base/message_pump_win.cc
15 	xul.dll 	base::MessagePumpWin::Run(base::MessagePump::Delegate*) 	ipc/chromium/src/base/message_pump_win.h
16 	xul.dll 	MessageLoop::RunHandler() 	ipc/chromium/src/base/message_loop.cc
17 	xul.dll 	MessageLoop::Run() 	ipc/chromium/src/base/message_loop.cc
18 	xul.dll 	base::Thread::ThreadMain() 	ipc/chromium/src/base/thread.cc
19 	xul.dll 	`anonymous namespace'::ThreadFunc(void*) 	ipc/chromium/src/base/platform_thread_win.cc
20 	kernel32.dll 	BaseThreadInitThunk 	
21 	ntdll.dll 	__RtlUserThreadStart 	
22 	ntdll.dll 	_RtlUserThreadStart

Comment 4

[Nicolas Silva [:nical]]

(In reply to juan becerra [:juanb] from comment #3)
> It's got lots of comments including some saying people are watching video in
> youtube using the html5 version, or resizing the browser window, or
> installing updates to their graphics card drivers. 

This sounds like we are losing the D3D device (which we don't handle very well, see bug 1086614) and trying to use a lost device is causing the errors. It's normal that this crash appeared recently because I landed some aggressive assertions in order to catch this kind of errors.
If we don't manage to get the assertion hit rate to an acceptable level we can at some point make it only crash debug builds but I'd like to keep it like this at least for some time in nightly since those crashes are symptoms of real issues (which we probably also have in the release channel now).

Comment 5

[Nicolas Silva [:nical]]

Attachment: Add some missing HRESULT checks

Comment 6

[Bas Schouten (:bas.schouten)]

Comment on attachment 8511994 [details] [diff] [review]
Add some missing HRESULT checks

Review of attachment 8511994 [details] [diff] [review]:
-----------------------------------------------------------------

I'm not convinced all of these are useful, but these aren't hot codepaths so I guess it can't hurt. They do clutter the code a little which is somewhat sad.

Comment 7

[Nicolas Silva [:nical]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/c30b79646349

Comment 8

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/c30b79646349

Comment 9

[Nicolas Silva [:nical]]

sorry, forgot to tag leave-open. The patch that just landed will help with investigating but will probably not fix the crash.

Comment 10

[Jeff Muizelaar [:jrmuizel]]

Does this happen on non Nvidia?

Comment 11

[Mathieu Marquer]

Just did for me with Intel Graphics on Win 7 x64
https://crash-stats.mozilla.com/report/index/e6666fe6-002a-4a02-9d26-5802a2141031

Comment 12

[Benoit Jacob [:bjacob] (mostly away)]

Crash data confirms that this is mostly NVIDIA specific, with 100x more NVIDIA crashes than either Intel or AMD:

$ zcat 20141030-pub-crashdata.csv.gz | grep -F 'AllocateCB(void*, _D3DDDICB_ALLOCATE*)'  | sed 's/.*AdapterVendorID\:\ \(0x\)\?\([0-9a-f]\+\).*/with vendor: 0x\2/g' | sort | uniq -c | sort -rn
  14001 with vendor: 0x10de
    149 with vendor: 0x1002
    128 with vendor: 0x8086
      9 with vendor: 0x15ad
      1 with vendor: 0x0000

Comment 13

[Benoit Jacob [:bjacob] (mostly away)]

Sorry had the wrong signature. With the correct signature, it's actually not NVIDIA specific:

$ zcat 20141030-pub-crashdata.csv.gz | grep -F 'mozilla::layers::CompositorD3D11::HandleError(long, mozilla::layers::CompositorD3D11::Severity)'  | sed 's/.*AdapterVendorID\:\ \(0x\)\?\([0-9a-f]\+\).*/with vendor: 0x\2/g' | sort | uniq -c | sort -rn
    665 with vendor: 0x8086
    391 with vendor: 0x10de
    387 with vendor: 0x1002
      2 with vendor: 0x1414

Comment 15

[Benoit Jacob [:bjacob] (mostly away)]

On Intel, we see it affects all generations of Intel GPUs:

$ zcat 20141030-pub-crashdata.csv.gz | grep -F 'mozilla::layers::CompositorD3D11::HandleError(long, mozilla::layers::CompositorD3D11::Severity)' | grep -F 'AdapterVendorID: 0x8086' | sed 's/.*AdapterDeviceID\:\ \(0x\)\?\([0-9a-f]\+\).*/with device: 0x\2/g' | sort | uniq -c | sort -rn | tee intel-devices-breakdown
    201 with device: 0x0166
     85 with device: 0x0a16
     72 with device: 0x0116
     48 with device: 0x0416
     34 with device: 0x0046
     33 with device: 0x0106
     30 with device: 0x0152
     28 with device: 0x0126
     26 with device: 0x0102
     23 with device: 0x0156
     18 with device: 0x0f31
     15 with device: 0x2e32
     14 with device: 0x2a42
      7 with device: 0x0042
      6 with device: 0x2a12
      6 with device: 0x0162
      5 with device: 0x2e22
      4 with device: 0x0412
      3 with device: 0x2e12
      3 with device: 0x041e
      1 with device: 0x2a02
      1 with device: 0x0d26
      1 with device: 0x0a06
      1 with device: 0x0112

Similarly, a driver version breakdown can be obtained by this command, and also shows an even distribution of all driver versions:

$ zcat 20141030-pub-crashdata.csv.gz | grep -F 'mozilla::layers::CompositorD3D11::HandleError(long, mozilla::layers::CompositorD3D11::Severity)' | grep 'AdapterVendorID: 0x8086' | grep 'AdapterDriverVersion\:\ [0-9]\+\.[0-9]\+\.[0-9]\+\.[0-9]\+' | sed 's/.*AdapterDriverVersion\:\ \([0-9]\+\.[0-9]\+\.[0-9]\+\.[0-9]\+\).*/\1/g' | sort -n | uniq -c

So at this point we can be certain that this is a bug on our side, not a driver bug.

Comment 16

[Hugh Nougher [:Hughman]]

After my own crash and looking through the comments on the crash reports I have been able to make a reproducible crash of this.

In a new profile on nightly:
1. Have a Youtube video playing in a tab. The 3 videos I tried were all HTML5.
2. Minimize and restore the window repeatedly.
3. Usually within 4 cycles of step 2 I have a crash.

Comment 17

[Hugh Nougher [:Hughman]]

Any more ideas? It would be nice to be able to restore Nightly when playing YouTube without crashing most of the time.

Comment 18

[(Away)]

I was able to reproduce using Hugh's steps: minimize and restore YouTube a few times. I have an Intel HD 5000. No e10s.

I stepped through the dxgi code and have a pretty good guess at the mSwapChain object's layout. The reason for the error code is that mSwapChain->buffers[0] == nullptr. I have no idea what that means in practice.

Comment 19

[Nicolas Silva [:nical]]

I couldn't find any documentation about what can make GetBuffer Return DXGI_ERROR_VALID_CALL, apart from passing a bad texture pointer which is not the case here.
Also nothing about mSwapChain->buffers[0] being null or how this interacts with minimized windows. Bas, do you have any idea?

Comment 20

[Jeff Muizelaar [:jrmuizel]]

I feel like running with D3D11 debug layer could be revealing. David, I'll put together a patch that causes us to use the debug layer.

Comment 21

[Jeff Muizelaar [:jrmuizel]]

Attachment: Enable the D3D11 debug layer

Make sure you have a recent Windows SDK installed to use this. I find DebugView is good for seeing the messages.

Comment 22

[(Away)]

Here's what I got. My log got spammed with the OMSetRenderTargets message the entire time that I was trying to repro. The other messages only kicked in just before the crash.

    [4060] D3D11 WARNING: ID3D11DeviceContext::OMSetRenderTargets: Resource being set to OM RenderTarget slot 0 is inaccessible because of a previous call to ReleaseSync or GetDC. [ STATE_SETTING WARNING #9: DEVICE_OMSETRENDERTARGETS_HAZARD]
    [4060] D3D11 ERROR: ID3D11Device::CreateTexture2D: The Dimensions are invalid. For feature level D3D_FEATURE_LEVEL_11_1, the Width (value = 144) must be between 1 and 16384, inclusively. The Height (value = -11) must be between 1 and 16384, inclusively. And, the ArraySize (value = 1) must be between 1 and 2048, inclusively. [ STATE_CREATION ERROR #101: CREATETEXTURE2D_INVALIDDIMENSIONS]
    [4060] D3D11 ERROR: ID3D11Device::CreateTexture2D: Returning E_INVALIDARG, meaning invalid parameters were passed. [ STATE_CREATION ERROR #104: CREATETEXTURE2D_INVALIDARG_RETURN]
    [4060] DXGI ERROR: IDXGISwapChain::GetBuffer: buffer creation failed allocation; no buffers available. [ MISCELLANEOUS ERROR #10: ]

Comment 23

[(Away)]

I tend to get the crash when minimizing/restoring around the 10 second mark when YouTube inserts a banner ad.

Comment 24

[(Away)]

(In reply to Nicolas Silva [:nical] from comment #4)
> It's normal that this crash appeared recently because I landed some
> aggressive assertions in order to catch this kind of errors.

This is still causing a huge number of crashes on nightly. If comment 22 doesn't give you or Jeff any good ideas, we need to consider a backout of whatever caused this to flare up. I can stay on my current build and help you guys investigate.

Comment 25

[Jeff Muizelaar [:jrmuizel]]

David, can you get a stack for the errors? You should be able to get this by doing d3dInfoQueue->SetBreakOnSeverity as described here: http://blogs.msdn.com/b/chuckw/archive/2012/11/30/direct3d-sdk-debug-layer-tricks.aspx

The stack for the error is most interesting. But a stack for the warning would also be interesting.

Comment 26

[(Away)]

Attachment: d3d11stack

Here are is the stack for the errors.

I also tried SetBreakOnSeverity for D3D11_MESSAGE_SEVERITY_WARNING but it didn't trigger.

Comment 27

[Jeff Muizelaar [:jrmuizel]]

Can you add a check/assert in CompositorD3D11::VerifyBufferSize() before we call ResizeBuffers to make sure mSize.width and mSize.height are positive? It's conceivable that were passing in negative numbers here and that's causing things to blow up later on.

Comment 28

[(Away)]

Attachment: debugging negative height

Comment 29

[(Away)]

Then I added this to CompositorD3D11::EnsureSize
  if (rect.height <= 0 || rect.width <= 0) { rect.height = 1; rect.width = 1; }

And it seems to prevent the crashes.

Comment 30

[Nicolas Silva [:nical]]

I looked into why a widget would have negative sizes, and the code that sets the SizeConstraints on a widget goes pretty deep into layout code. I am not sure whether we want to just ensure that the widget's bounds are positive in the compositor or in the widget code, or make sure that a SizeConstraint's minimum size is always positive, although I have no idea what the impact of the later would be since it's used in many places outside of gfx.

Otherwise we can make sure the compositor doesn't do anything while the widget has bounds that are inferior or equal to zero. Since nothing would get to the screen nothing good can come from trying to render stuff in that state.

Comment 31

[Jeff Muizelaar [:jrmuizel]]

Here's an example of something we could try:
https://tbpl.mozilla.org/?tree=Try&rev=95f9a390d4c1

Comment 32

[(Away)]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #31)
> Here's an example of something we could try:
> https://tbpl.mozilla.org/?tree=Try&rev=95f9a390d4c1

This build resolves the issue for me: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-95f9a390d4c1/try-win32/

Hugh, can you give it a try as well?

Comment 33

[Jeff Muizelaar [:jrmuizel]]

Attachment: Avoid trying to resize the swap chain to a negative size.

Comment 34

[Jeff Muizelaar [:jrmuizel]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/a9034a65b529

Comment 35

[Hugh Nougher [:Hughman]]

(In reply to David Major [:dmajor] (UTC+13) from comment #32)
> Hugh, can you give it a try as well?

I must be doing something wrong because when I try running the one in the zip package it crashes on startup before the profile selector. (I tried the same procedure with yesterday's nightly and it worked fine)

Comment 36

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/a9034a65b529

Comment 37

[Milan Sreckovic [:milan] (needinfo for best results)]

[Tracking Requested - why for this release]:
We're verifying whether the proposed fix we have makes this go away, but if we have a fix, we'd like it uplifted. Stay tuned.

Comment 38

[Lawrence Mandel [:lmandel] (use needinfo)]

Does this bug impact 34 and 35 as the comments all reference 36/nightly only?

Comment 39

[Milan Sreckovic [:milan] (needinfo for best results)]

Jeff should confirm, but I think this helps all releases.

Comment 40

[Ryan Jones-Ward [:sciguyryan]]

I can confirm that the latest nightlies (with the patch merged in) completely eliminates the problem.

Accidental and spam-clicking the taxkbar icon for the browser while a youtube video is playing no longer triggers a crash.

Comment 41

[Hugh Nougher [:Hughman]]

I agree with Ryan that it appears fixed in latest Nightly.

Comment 42

[(Away)]

I can't speak to whether the code is generally nice to have for 34/35, but this particular crash signature only came up on 36.

Version facet 
Rank 	Version 	Count 	%
1 	36.0a1 	32242 	100.00 %

Comment 43

[Nicolas Silva [:nical]]

The signature is only present on 36 because we landed a patch that makes us crash whenever there is an invalid D3D command. The problem exists on other channels but we just don't check the error there and so we don't assert.

Comment 44

[Jeff Muizelaar [:jrmuizel]]

Comment on attachment 8522494 [details] [diff] [review]
Avoid trying to resize the swap chain to a negative size.

Approval Request Comment
[Feature/regressing bug #]: OMTC
[User impact if declined]: Crashes and occasional black screens
[Describe test coverage new/current, TBPL]: Has been on trunk for a while. Users have reported that it fixes the errors they were seeing.
[Risks and why]: Pretty limited. It should just not introduce any new code paths.

Comment 45

[Lawrence Mandel [:lmandel] (use needinfo)]

Comment on attachment 8522494 [details] [diff] [review]
Avoid trying to resize the swap chain to a negative size.

Jeff thinks that this is likely to fix bug 1096864 as well. Beta+

Comment 46

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/59bdd524ada8
https://hg.mozilla.org/releases/mozilla-beta/rev/86ea676ed2e2

Comment 47

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

Closing since there are no more instances of this crash over the past month.

Comment 48

[Brian Carpenter [:geeknik]]

I'm able to cause a crash on demand at xul!mozilla::layers::CompositorD3D11::HandleError+0x000000000000002a. Is this related or should I file a new bug.

Comment 49

[Milan Sreckovic [:milan] (needinfo for best results)]

Hi Brian, possibly related - could you point us to a crash report from one of these crashes?

Comment 50

[Brian Carpenter [:geeknik]]

I don't have a crash report, this was found while fuzzing Nightly. Here is some output from WinDBG:

[JavaScript Error: "uncaught exception: Permission denied to add file:///d:/cross_fuzz_v3/targets/target2.html as a content or protocol handler"]
(5875c.5a770): C++ EH exception - code e06d7363 (first chance)
(5875c.5a770): C++ EH exception - code e06d7363 (first chance)
(5875c.5a770): C++ EH exception - code e06d7363 (first chance)
(5875c.5a770): Break instruction exception - code 80000003 (first chance)
xul!mozilla::layers::CompositorD3D11::HandleError+0x2a:
00007ff8`f02f81be cc              int     3

I'm unable to get WinDBG to give me an exception analysis, but I am seeing this as well:

First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
xul!mozilla::layers::CompositorD3D11::HandleError+0x2b:
00007ff8`f02f81bf c7042500000000b1050000 mov dword ptr [0],5B1h ds:00000000`00000000=????????

Comment 51

[Milan Sreckovic [:milan] (needinfo for best results)]

Yeah, crash inside of CompositorD3D11::HandleError is usually due to us explicitly calling MOZ_CRASH, so it's the rest of the stack that makes things interesting.

Comment 52

[Brian Carpenter [:geeknik]]

(In reply to Milan Sreckovic [:milan] from comment #51)
> Yeah, crash inside of CompositorD3D11::HandleError is usually due to us
> explicitly calling MOZ_CRASH, so it's the rest of the stack that makes
> things interesting.

I got WinDBG working properly again:

FAULTING_IP: 
xul!mozilla::layers::CompositorD3D11::HandleError+2a [c:\builds\moz2_slave\m-cen-w64-ntly-000000000000000\build\gfx\layers\d3d11\compositord3d11.cpp @ 1457]
00007ff8`f02f7d82 cc              int     3

EXCEPTION_RECORD:  ffffffffffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 00007ff8f02f7d82 (xul!mozilla::layers::CompositorD3D11::HandleError+0x000000000000002a)
   ExceptionCode: 80000003 (Break instruction exception)
  ExceptionFlags: 00000000
NumberParameters: 1
   Parameter[0]: 0000000000000000

FAULTING_THREAD:  000000000005a618

DEFAULT_BUCKET_ID:  STATUS_BREAKPOINT

PROCESS_NAME:  firefox.exe

ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION}  Breakpoint  A breakpoint has been reached.

EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - One or more arguments are invalid

EXCEPTION_PARAMETER1:  0000000000000000

NTGLOBALFLAG:  70

APPLICATION_VERIFIER_FLAGS:  0

PRIMARY_PROBLEM_CLASS:  STATUS_BREAKPOINT

BUGCHECK_STR:  APPLICATION_FAULT_STATUS_BREAKPOINT

LAST_CONTROL_TRANSFER:  from 00007ff8f02f7bf5 to 00007ff8f02f7d82

STACK_TEXT:  
000000f4`07fff3a0 00007ff8`f02f7bf5 : 887a0001`00000000 00000000`00000000 000000f4`07fff7e0 000000f4`06540a08 : xul!mozilla::layers::CompositorD3D11::HandleError+0x2a [c:\builds\moz2_slave\m-cen-w64-ntly-000000000000000\build\gfx\layers\d3d11\compositord3d11.cpp @ 1457]
000000f4`07fff3d0 00007ff8`f02f8587 : 000000f4`07bd1b90 00000000`00000000 00007ff9`17c96d20 00007ff8`887a0001 : xul!mozilla::layers::CompositorD3D11::Failed+0xd [c:\builds\moz2_slave\m-cen-w64-ntly-000000000000000\build\gfx\layers\d3d11\compositord3d11.cpp @ 1469]
000000f4`07fff400 00007ff8`f02f604e : 00000000`00000000 000000f4`07fff580 00000075`00000130 000000f4`07fff4e9 : xul!mozilla::layers::CompositorD3D11::UpdateRenderTarget+0x63 [c:\builds\moz2_slave\m-cen-w64-ntly-000000000000000\build\gfx\layers\d3d11\compositord3d11.cpp @ 1259]
000000f4`07fff440 00007ff8`efa8ed12 : 000000f4`0b02ed70 000000f4`07fff640 000000f4`0b02ed70 00000000`00000000 : xul!mozilla::layers::CompositorD3D11::BeginFrame+0x86 [c:\builds\moz2_slave\m-cen-w64-ntly-000000000000000\build\gfx\layers\d3d11\compositord3d11.cpp @ 1058]
000000f4`07fff540 00007ff8`efa8f363 : 000000f4`0b02ec40 000000f4`0b02ec40 000000f4`0b02ed50 00000000`00000000 : xul!mozilla::layers::LayerManagerComposite::Render+0x2b2 [c:\builds\moz2_slave\m-cen-w64-ntly-000000000000000\build\gfx\layers\composite\layermanagercomposite.cpp @ 712]
000000f4`07fff860 00007ff8`efa8f205 : 00007ff8`efa80001 000000f4`0b0c3400 00000000`00000000 00000000`00000000 : xul!mozilla::layers::LayerManagerComposite::EndTransaction+0x14b [c:\builds\moz2_slave\m-cen-w64-ntly-000000000000000\build\gfx\layers\composite\layermanagercomposite.cpp @ 312]
000000f4`07fff910 00007ff8`efa8c242 : 000000f4`0657c000 000000f4`0b0c3400 00000000`00000000 00000000`00000000 : xul!mozilla::layers::LayerManagerComposite::EndEmptyTransaction+0x19 [c:\builds\moz2_slave\m-cen-w64-ntly-000000000000000\build\gfx\layers\composite\layermanagercomposite.cpp @ 258]
000000f4`07fff940 00007ff8`efa8b8b4 : 000000f4`0b598cf0 000000f4`034d7e80 000000f4`07fffc30 000000f4`0657c000 : xul!mozilla::layers::CompositorParent::CompositeToTarget+0x12a [c:\builds\moz2_slave\m-cen-w64-ntly-000000000000000\build\gfx\layers\ipc\compositorparent.cpp @ 986]
000000f4`07fffa00 00007ff8`ef9a648e : 000000f4`07fffc20 000000f4`060050b0 000000f4`07fffae0 00007ff9`1d6b30ef : xul!RunnableMethod<mozilla::layers::CompositorParent,void (__cdecl mozilla::layers::CompositorParent::*)(mozilla::TimeStamp) __ptr64,Tuple1<mozilla::TimeStamp> >::Run+0x44 [c:\builds\moz2_slave\m-cen-w64-ntly-000000000000000\build\ipc\chromium\src\base\task.h @ 311]
000000f4`07fffa50 00007ff8`ef9a5a41 : 000000f4`06005150 000000f4`060050b0 00000000`00000000 00000000`00000001 : xul!MessageLoop::DoWork+0x12e [c:\builds\moz2_slave\m-cen-w64-ntly-000000000000000\build\ipc\chromium\src\base\message_loop.cc @ 447]
000000f4`07fffab0 00007ff8`ef9a558f : 000000f4`06005150 00000000`00000000 000000f4`060050b0 00000000`00000000 : xul!base::MessagePumpForUI::DoRunLoop+0x71 [c:\builds\moz2_slave\m-cen-w64-ntly-000000000000000\build\ipc\chromium\src\base\message_pump_win.cc @ 217]
000000f4`07fffb20 00007ff8`ef9a62f7 : 000000f4`07fffc20 00000000`00000000 00000000`0000000a 00007ff8`efa946c5 : xul!base::MessagePumpWin::Run+0x3b [c:\builds\moz2_slave\m-cen-w64-ntly-000000000000000\build\ipc\chromium\src\base\message_pump_win.h @ 78]
000000f4`07fffb70 00007ff8`ef9a613e : 000000f4`07fffc20 00000000`00000000 000000f4`060050b0 00007ff9`1afd149c : xul!MessageLoop::RunHandler+0x17 [c:\builds\moz2_slave\m-cen-w64-ntly-000000000000000\build\ipc\chromium\src\base\message_loop.cc @ 227]
000000f4`07fffba0 00007ff8`efbcdb39 : 000000f4`060050d8 000000f4`060050b0 000000f4`060050b0 00000000`00000000 : xul!MessageLoop::Run+0x3e [c:\builds\moz2_slave\m-cen-w64-ntly-000000000000000\build\ipc\chromium\src\base\message_loop.cc @ 201]
000000f4`07fffbf0 00007ff8`efbcda66 : 00000000`00000000 00007ff9`1da716a0 00000000`00000000 00000000`00000000 : xul!base::Thread::ThreadMain+0xc9 [c:\builds\moz2_slave\m-cen-w64-ntly-000000000000000\build\ipc\chromium\src\base\thread.cc @ 173]
000000f4`07fffd80 00007ff9`1da716ad : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : xul!`anonymous namespace'::ThreadFunc+0xa [c:\builds\moz2_slave\m-cen-w64-ntly-000000000000000\build\ipc\chromium\src\base\platform_thread_win.cc @ 27]
000000f4`07fffdb0 00007ff9`1dc1eb64 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : KERNEL32!BaseThreadInitThunk+0xd
000000f4`07fffde0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x34


FOLLOWUP_IP: 
xul!mozilla::layers::CompositorD3D11::HandleError+2a [c:\builds\moz2_slave\m-cen-w64-ntly-000000000000000\build\gfx\layers\d3d11\compositord3d11.cpp @ 1457]
00007ff8`f02f7d82 cc              int     3

FAULTING_SOURCE_CODE:  
No source found for 'c:\builds\moz2_slave\m-cen-w64-ntly-000000000000000\build\gfx\layers\d3d11\compositord3d11.cpp'


SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  xul!mozilla::layers::CompositorD3D11::HandleError+2a

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: xul

IMAGE_NAME:  xul.dll

DEBUG_FLR_IMAGE_TIMESTAMP:  54f46e78

STACK_COMMAND:  ~31s ; kb

FAILURE_BUCKET_ID:  STATUS_BREAKPOINT_80000003_xul.dll!mozilla::layers::CompositorD3D11::HandleError

BUCKET_ID:  X64_APPLICATION_FAULT_STATUS_BREAKPOINT_xul!mozilla::layers::CompositorD3D11::HandleError+2a

WATSON_STAGEONE_URL:  http://watson.microsoft.com/StageOne/firefox_exe/39_0_0_5539/54f45d48/xul_dll/39_0_0_5539/54f46e78/80000003/00d17d82.htm?Retriage=1

Followup: MachineOwner

More WinDGB output: https://db.tt/g0Anrv6I

Comment 53

[Brian Carpenter [:geeknik]]

(In reply to Milan Sreckovic [:milan] from comment #51)
> Yeah, crash inside of CompositorD3D11::HandleError is usually due to us
> explicitly calling MOZ_CRASH, so it's the rest of the stack that makes
> things interesting.

https://bugzilla.mozilla.org/show_bug.cgi?id=1174603