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

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).

[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

(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 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.

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

Does this happen on non Nvidia?

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

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

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.

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?

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: ]

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: 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.

Here are is the stack for the errors. I also tried SetBreakOnSeverity for D3D11_MESSAGE_SEVERITY_WARNING but it didn't trigger.

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.

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.

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: https://tbpl.mozilla.org/?tree=Try&rev=95f9a390d4c1

(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/jmuizelaar@mozilla.com-95f9a390d4c1/try-win32/ Hugh, can you give it a try as well?

(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?

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

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.

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.

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+

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

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) 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=????????

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: 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

(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