Closed Bug 1089364 Opened 5 years ago Closed 5 years ago

Crash in mozilla::layers::CompositorD3D11::HandleError


(Core :: Graphics, defect, critical)

Windows 7
Not set



Tracking Status
firefox34 + verified
firefox35 + verified
firefox36 + verified


(Reporter: sciguyryan, Assigned: jrmuizel)



(Keywords: crash, topcrash)

Crash Data


(5 files)

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:

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
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
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).
Duplicate of this bug: 1089466
[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:

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/
11 	xul.dll 	MessageLoop::DeferOrRunPendingTask(MessageLoop::PendingTask const&) 	ipc/chromium/src/base/
12 	xul.dll 	MessageLoop::DoWork() 	ipc/chromium/src/base/
13 	xul.dll 	base::MessagePumpForUI::DoRunLoop() 	ipc/chromium/src/base/
14 	xul.dll 	base::MessagePumpWin::RunWithDispatcher(base::MessagePump::Delegate*, base::MessagePumpWin::Dispatcher*) 	ipc/chromium/src/base/
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/
17 	xul.dll 	MessageLoop::Run() 	ipc/chromium/src/base/
18 	xul.dll 	base::Thread::ThreadMain() 	ipc/chromium/src/base/
19 	xul.dll 	`anonymous namespace'::ThreadFunc(void*) 	ipc/chromium/src/base/
20 	kernel32.dll 	BaseThreadInitThunk 	
21 	ntdll.dll 	__RtlUserThreadStart 	
22 	ntdll.dll 	_RtlUserThreadStart
(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).
Depends on: 1086614
Assignee: nobody → nical.bugzilla
Attachment #8511994 - Flags: review?(bas)
Crash Signature: [@ mozilla::layers::CompositorD3D11::HandleError(long, mozilla::layers::CompositorD3D11::Severity) ]
Summary: Crash [@ mozilla::layers::CompositorD3D11::HandleError(long, mozilla::layers::CompositorD3D11::Severity) ] → Crash in mozilla::layers::CompositorD3D11::HandleError
See Also: → 1089881
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.
Attachment #8511994 - Flags: review?(bas) → review+
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
sorry, forgot to tag leave-open. The patch that just landed will help with investigating but will probably not fix the crash.
Resolution: FIXED → ---
Whiteboard: [leave-open]
Does this happen on non Nvidia?
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
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
Duplicate of this bug: 1091895
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.
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.
Any more ideas? It would be nice to be able to restore Nightly when playing YouTube without crashing most of the time.
Flags: needinfo?(nical.bugzilla)
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.
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?
Flags: needinfo?(nical.bugzilla) → needinfo?(bas)
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.
Make sure you have a recent Windows SDK installed to use this. I find DebugView is good for seeing the messages.
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: ]
Flags: needinfo?(jmuizelaar)
I tend to get the crash when minimizing/restoring around the 10 second mark when YouTube inserts a banner ad.
(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.
David, can you get a stack for the errors? You should be able to get this by doing d3dInfoQueue->SetBreakOnSeverity as described here:

The stack for the error is most interesting. But a stack for the warning would also be interesting.
Flags: needinfo?(dmajor)
Attached file d3d11stack
Here are is the stack for the errors.

I also tried SetBreakOnSeverity for D3D11_MESSAGE_SEVERITY_WARNING but it didn't trigger.
Flags: needinfo?(dmajor)
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.
Flags: needinfo?(dmajor)
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.
Flags: needinfo?(dmajor)
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.
Here's an example of something we could try:
Flags: needinfo?(jmuizelaar)
Flags: needinfo?(bas)
Assignee: nical.bugzilla → jmuizelaar
(In reply to Jeff Muizelaar [:jrmuizel] from comment #31)
> Here's an example of something we could try:

This build resolves the issue for me:

Hugh, can you give it a try as well?
Flags: needinfo?(hughnougher)
Blocks: 1096864
(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)
[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.
Does this bug impact 34 and 35 as the comments all reference 36/nightly only?
Flags: needinfo?(milan)
Jeff should confirm, but I think this helps all releases.
Flags: needinfo?(milan)
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.
I agree with Ryan that it appears fixed in latest Nightly.
Flags: needinfo?(hughnougher)
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 %
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 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.
Attachment #8522494 - Flags: approval-mozilla-beta?
Attachment #8522494 - Flags: approval-mozilla-aurora?
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+
Attachment #8522494 - Flags: approval-mozilla-beta?
Attachment #8522494 - Flags: approval-mozilla-beta+
Attachment #8522494 - Flags: approval-mozilla-aurora?
Attachment #8522494 - Flags: approval-mozilla-aurora+
Depends on: 1092205
Depends on: 1104008
Closing since there are no more instances of this crash over the past month.
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.
Hi Brian, possibly related - could you point us to a crash report from one of these crashes?
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)
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.
00007ff8`f02f81bf c7042500000000b1050000 mov dword ptr [0],5B1h ds:00000000`00000000=????????
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.
(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:

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


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





LAST_CONTROL_TRANSFER:  from 00007ff8f02f7bf5 to 00007ff8f02f7d82

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\ @ 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\ @ 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\ @ 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\ @ 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\ @ 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\ @ 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

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

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


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

FOLLOWUP_NAME:  MachineOwner


IMAGE_NAME:  xul.dll


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


Followup: MachineOwner

More WinDGB output:
(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.
You need to log in before you can comment on or make changes to this bug.