WindowChromeWorker._ExtendGlassFrame causes COMException - Desktop composition is disabled

[mw-ea]

Description

WPF application, that is left running when user's Remote Desktop session is locked (due to inactivity timeout).
When user reconnects over Remote Desktop (application still running), we sometimes see this exception.

System.Runtime.InteropServices.COMException at Standard.NativeMethods.DwmExtendFrameIntoClientArea
{Desktop composition is disabled} The operation could not be completed because desktop composition is disabled. (0x80263001)

call stack of main thread:

|    System.Windows.Threading.Dispatcher.CatchException
|    System.Windows.Threading.ExceptionWrapper.TryCatchWhen
|    [Managed to Native Transition]
|    System.Windows.Shell.WindowChromeWorker._ExtendGlassFrame
|    System.Windows.Shell.WindowChromeWorker._UpdateFrameState
|    System.Windows.Shell.WindowChromeWorker._HandleDwmCompositionChanged
|    System.Windows.Shell.WindowChromeWorker._WndProc
|    System.Windows.Interop.HwndSource.PublicHooksFilterMessage
|    MS.Win32.HwndWrapper.WndProc
|    System.Windows.Threading.ExceptionWrapper.InternalRealCall
|    System.Windows.Threading.ExceptionWrapper.TryCatchWhen
|    System.Windows.Threading.Dispatcher.LegacyInvokeImpl
|    MS.Win32.HwndSubclass.SubclassWndProc
|    [Native to Managed Transition]
|    [Managed to Native Transition]
|    WPF Dispatcher (0)
|    System.Windows.Threading.Dispatcher.PushFrameImpl
...<our app code>

<our app code> can be as basic as the entry point -> System.Windows.Application.RunDispatcher,
or our application is showing its own dialog at the time, so there are
System.Windows.Threading.Dispatcher.PushFrameImpl + our app code that leads to that
before the _HandleDwmCompositionChanged,
...but ultimately the same WindowChromeWorker call stack at the point of exception.

From the source of WindowChromeWorker.cs, there is a check for DwmIsCompositionEnabled() before calling DwmExtendFrameIntoClientArea().

So seems odd that could then trigger a "Desktop composition is disabled" exception.
Is it a bug within WindowChromeWorker or the native methods it uses?
maybe a race or unreliable result from DwmIsCompositionEnabled in the case of remote desktop reconnect.

Reproduction Steps

Issue presents in different scenarios for some of our users. Have not been able to pin down steps nor reproduce myself.
Simplest case is having the application running when Remote Desktop is locked, then login again (over RDP) to unlock the session.

Expected behavior

no exception

Actual behavior

Getting exception

System.Runtime.InteropServices.COMException at Standard.NativeMethods.DwmExtendFrameIntoClientArea
{Desktop composition is disabled} The operation could not be completed because desktop composition is disabled. (0x80263001)

from System.Windows.Shell.WindowChromeWorker._ExtendGlassFrame call to DwmExtendFrameIntoClientArea

Regression?

No response

Known Workarounds

none

Impact

Crashes the application.

Configuration

.Net 8
Windows 11: Microsoft Windows NT 10.0.26200.0
x64

Other information

Application makes use of DirectX. We do handle device re-init during remote desktop reconnect. This part works, but seems just after this we can see the reported exception - even when there is no direct use of the DirectX device by the app (no content rendered through it at the time).

[h3xds1nz]

This was a longstanding issue, recently "fixed" by a fallback in #11417 to standard window color when DWM crashes or just ain't available at the time of the call to DwmExtendFrameIntoClientArea.

Guess the numerous reports for PowerToys and other Microsoft-owned apps managed to get 1 change/fix (from all the other outstanding 500 issues) into WPF for .NET 11.

[mw-ea]

That's sort of good news, thanks for the tip. Only have to wait until we can update to .NET 11 :(
... backport to .NET 10 would be nice.

I don't suppose anyone knows of workarounds for cases that hit this?
(have now seen some which don't involve Remote Desktop reconnect too)

[h3xds1nz]

Your best bet until then is to handle it in DispatcherUnhandledException in your app. It will be raised on the UI thread.

[Camios]

.NET 8 is LTS until Nov 2026, do LTS versions automatically get fixes for these kinds of issues/crashes? Will it make the monthly patch (aka Patch Tuesday)?
We'll move to .NET 10 this year (LTS until Nov 2028), but we'll likely have users on .NET 8 for some time. So patching both LTS versions would be the best for us.

[himgoyalmicro]

Hey @mw-ea, can you please try out dotnet 11 preview 2 on your system and try out the fix?
We are gathering some data about the fix before backporting.
Thanks for the help!

[mw-ea]

unfortunately I can't reproduce the issue on my machine, nor does anyone in nearby teams. It's only been seen among our users via telemetry, and it's hard to get them a test version with a later dotnet.