WPF App crashes due to COMException (UCEERR_RENDERTHREADFAILURE) from System.Windows.Media.Composition.DUCE.Channel.SyncFlush

[SamBent]

Problem description: HostVisual interacts with its rendering channel on the wrong thread. This can lead to render thread failures, perhaps minutes or hours after the bad interaction.

[Port of servicing fix for .NET 4.7-4.8]

[BrannonKing]

Is this a duplicate of #128?

[jakeyeagley]

I'm also seeing this issue. Here is my stack trace.

System.Runtime.InteropServices.COMException (0x88980406): UCEERR_RENDERTHREADFAILURE (Exception from HRESULT: 0x88980406)
at MS.Internal.HRESULT.Check(Int32 hr)
at System.Windows.Media.Composition.DUCE.Channel.SyncFlush()
at System.Windows.Media.MediaContext.CompleteRender()
at System.Windows.Media.MediaContext.CreateChannels()
at System.Windows.Media.MediaSystem.ConnectChannels(MediaContext mc)
at System.Windows.Media.MediaContext..ctor(Dispatcher dispatcher)
at System.Windows.Media.MediaContext.From(Dispatcher dispatcher)
at System.Windows.Media.MediaContext.RegisterICompositionTarget(Dispatcher dispatcher, ICompositionTarget iv)
at System.Windows.Media.VisualTarget..ctor(HostVisual hostVisual)

[SamBent]

SyncFlush is a catch-all for all render thread failures. The callstack just shows how the main thread learned that the render thread failed, without telling us anything at all about the failure.

This issue addresses a very specific failure, caused by the HostVisual element doing work on the wrong thread. It is not a dupe of #128, and is unlikely to be @jakeyeagley's issue (unless maybe you're using HostVisual).

[BrannonKing]

There's something wrong with .NET Framework 4.8.4200.0 -- that version specifically that came out just recently and was applied via Windows Update over the last few days. That's causing complete breakage of HostVisual, throwing this COMException error. The specific patch is TBD. If you're on Windows build 2004, you can uninstall KB4569745 to repair the issue (and go back to Framework version 4180). If you have KB4562900 installed, you may have success removing that update.

[SamBent]

One problem was reported this week: it occurs when two (or more) HostVisual elements disconnect at (roughly) the same time, and the threads involved interleave in the wrong way. If this doesn't apply to your problem, tell me more.

We have a fix for the new problem, but it will take some time to push it through the Windows Update process. Meanwhile you can opt out of the HostVisual change in the recent update by setting "Switch.System.Windows.Media.HostVisual.DisconnectsOnWrongThread=true", using instructions here.

You should remove the switch when the new fix is published, to guard against the original bug.

[BrannonKing]

Sweet! A workaround! Thank you. Your problem description does describe my issue.

[superware]

One problem was reported this week: it occurs when two (or more) HostVisual elements disconnect at (roughly) the same time, and the threads involved interleave in the wrong way. If this doesn't apply to your problem, tell me more.

I'm still getting this exception on 4.8.4300.0 with multiple displays when disconnecting one of the screens. Should this happen? Is there a workaround and/or fix coming?

Thanks!

[SamBent]

@superware Your problem is almost certainly unrelated to this issue. The same exception is just a coincidence - see here for a full discussion. Please open a new issue to track your problem, following the advice in the doc. To set expectations, there may be nothing WPF can do about it - disconnecting a screen is a pretty violent action that may disrupt lower-level components (graphics drivers, DX, etc) beyond WPF's ability to cope. Meanwhile, the obvious workaround is "don't do that".

[vatsan-madhavan]

disconnecting a screen is a pretty violent action that may disrupt lower-level components (graphics drivers, DX, etc) beyond WPF's ability to cope.

From what I understood about how this works, WPF relies on DdQueryDisplaySettingsUniqueness/GdiEntry13 to listen to mode changes - which treats screen disconnection at par with more common events like screen lock/unlock, remote-desktop connection/disconnection, DPI change etc. events. IIRC WPF simply re-enumerates the display-adapter and monitor topology every time the retval from DdQueryDisplaySettingsUniqueness changes.

For e.g., I believe that monitor-disconnections (and even display-adapter disconnections) - frequently involving changes to multimon topology - is 'seen' by WPF when RDP to console (or vice-versa) transitions happen.