Crash report: https://crash-stats.mozilla.org/report/index/5456da61-64e5-40f0-87a6-b46c70210203

Reason: EXCEPTION_ACCESS_VIOLATION_READ

Top 10 frames of crashing thread:

0 xul.dll mozilla::layers::DataTextureSourceD3D11::DataTextureSourceD3D11 gfx/layers/d3d11/TextureD3D11.cpp:200
1 xul.dll mozilla::wr::RenderCompositorD3D11SWGL::CreateTile gfx/webrender_bindings/RenderCompositorD3D11SWGL.cpp:484
2 xul.dll webrender_bindings::swgl_bindings::{{impl}}::create_tile gfx/webrender_bindings/src/swgl_bindings.rs:1354
3 xul.dll webrender::renderer::Renderer::update_native_surfaces gfx/wr/webrender/src/renderer/mod.rs:4250
4 xul.dll webrender::renderer::Renderer::render_impl gfx/wr/webrender/src/renderer/mod.rs:2102
5 xul.dll webrender::renderer::Renderer::render gfx/wr/webrender/src/renderer/mod.rs:1877
6 xul.dll webrender_bindings::bindings::wr_renderer_render gfx/webrender_bindings/src/bindings.rs:639
7 xul.dll mozilla::wr::RendererOGL::UpdateAndRender gfx/webrender_bindings/RendererOGL.cpp:186
8 xul.dll mozilla::wr::RenderThread::UpdateAndRender gfx/webrender_bindings/RenderThread.cpp:481
9 xul.dll mozilla::wr::RenderThread::HandleFrameOneDoc gfx/webrender_bindings/RenderThread.cpp:337

Can we really assume this call will always succeeded? OOM?

https://searchfox.org/mozilla-central/rev/b2433a832c250c55255e0ee37d05192d04f20427/gfx/webrender_bindings/RenderCompositorD3D11SWGL.cpp#482

The crash stack clearly shows we are using SW-WR but I don't see how it made that decision; no special prefs set, WR/WR-Qualified are available, no fallback mentioned in the critical log. The log suggests a fallback would have happened given the repetitions of DCompositionSurface::BeginDraw failed which disable (Hardware) WebRender.

I just faced the crash that seemed to be related to device reset. bp-8dbe5561-7fa1-422f-84e7-c35ea0210204

Makes sense that it could fail, either due to OOM or device reset.

Sotaro, do you want to handle this? I assume we'd detect device reset already and recreate the compositor, but we shouldn't crash before that happens.

Yes, I take the bug.

I think bug 1691344 may be the same issue as this, where we failed to allocate a texture and then crash trying to access it later.

trivial test case on Windows (Intel HD5500, 8GB RAM) : open the attachment of bug 1693256. Keep clicking on the "increase JS" button till the tab crashes.
mostly you will have OOM|small signature. But occasionally you can get the signature in this bug.
This is what I got : https://crash-stats.mozilla.org/report/index/4c737cb7-102c-4db7-bca6-fd1390210217

https://hg.mozilla.org/mozilla-central/rev/716373e67511