This bug was filed from the Socorro interface and is report bp-ee5bb2db-29f9-491c-b66f-bdc770171206. ============================================================= Top 5 frames of crashing thread: 0 d3d11.dll SPipelineState::TrimAllHWM 1 atidxx64.dll atidxx64.dll@0x53ff9 2 atidxx64.dll atidxx64.dll@0x2f6643 3 d3d11.dll CContext::OnRender 4 d3d11.dll NDXGI::CDevice::RenderCB ============================================================= this crash signature during media playback is from windows 7 users on 64bit only and probably got more common mid october due to the win64 migration of release users. a couple of older ati/amd gpus and drivers seem affected: Adapter driver version facet 1 8.653.0.0 2166 48.82 % 2 8.641.0.0 482 10.86 % 3 8.652.0.0 367 8.27 % 4 8.640.0.0 303 6.83 % 5 8.641.1.1000 201 4.53 % 6 8.650.0.0 191 4.30 % 7 8.970.100.1100 154 3.47 % 8 8.660.0.0 116 2.61 % 9 8.641.1.0 95 2.14 % 10 8.652.1.0 66 1.49 % Adapter device id facet 1 0x954f 928 20.92 % 2 0x9553 710 16.00 % 3 0x9710 396 8.92 % 4 0x9552 333 7.51 % 5 0x9616 331 7.46 % 6 0x9480 302 6.81 % 7 0x95c4 259 5.84 % 8 0x9591 167 3.76 % 9 0x95c5 167 3.76 % 10 0x9498 118 2.66 %

under windows 10 the reports appear to have the signature [@ SPipelineStageState::TrimAllHWM]

Milan and Peter, The crash rate is quite high and its report looks like more related to graphics to me. May we have your help check it?

This could be a non-Intel version of bug 1292923?

It's hard to say, I can't find a way to tell what else we're running on the crashing thread. It does look like a multi-thread device issue though, so it's certainly possible. Can we ask AMD to look at a crash dump and see they can figure anything else out?

(In reply to Matt Woodrow (:mattwoodrow) from comment #4) > It's hard to say, I can't find a way to tell what else we're running on the > crashing thread. > > It does look like a multi-thread device issue though, so it's certainly > possible. > > Can we ask AMD to look at a crash dump and see they can figure anything else > out? Kyle, Per comment 4, can you help us check it?

Paul, Since Kyle is not available until next year, would you be available to help us check this bug per comment 4?

We will investigate

Pretty much all of the affected device IDs are long EOL'ed (> 5 years) and no new driver updates are planned for these devices. Most of the affected The driver revisions affected are not the last ones released for these devices however, though most of the affected don't seem to use the last one released (8.970.100) and available here: http://support.amd.com/en-us/download/desktop/legacy?product=legacy2&os=Windows%208%20-%2064 Based on the offsets, the most likely root cause seems indeed to be a multi-threading issue when using the Render() API along with some context state change (from the source it is not clear exactly what other operation occurred). The suggested approach is to ensure that reentry is avoided when calling down to the runtime/driver.