WindowChromeWorker._ExtendGlassFrame dereferences HwndSource.CompositionTarget without a null check (NullReferenceException during window creation)

[m-smkim]

Description

WindowChromeWorker._ExtendGlassFrame() dereferences _hwndSource.CompositionTarget without a null check. HwndSource.CompositionTarget returns null when the HwndSource is disposed or when its HwndTarget has been disposed independently, so this throws a NullReferenceException while a window is being created.

The guard in _UpdateFrameState does not cover this case:

if (IntPtr.Zero == _hwnd || _hwndSource.IsDisposed)   // WindowChromeWorker.cs:703
{
    return;
}

It checks the HwndSource, but CompositionTarget also returns null based on the state of a different object (_hwndTarget). So _hwndSource.IsDisposed == false and CompositionTarget == null can hold at the same time, and the guard lets execution through.

This is the sibling of #11440. That issue reported a COMException from DwmExtendFrameIntoClientArea a few lines later in the same method, and was addressed by the crash containment in #11417. The null dereference that happens before that call is still unguarded.

Unguarded dereference sites on main:

Location	Method
WindowChromeWorker.cs:942	_ExtendGlassFrame — DWM-disabled branch
WindowChromeWorker.cs:952	_ExtendGlassFrame — DWM-enabled branch
WindowChromeWorker.cs:998	_ExtendGlassFrame
WindowChromeWorker.cs:1142	_RestoreGlassFrame

Reproduction Steps

I have not been able to reproduce this deterministically — it is a race, and it was observed in production rather than in a test.

What can be stated precisely is the exposure. Any window whose WindowChrome has a non-zero GlassFrameThickness runs the unguarded code on every window creation, because _ApplyNewCustomChrome() calls _UpdateFrameState(force: true), and force bypasses the state-change check:

_isGlassEnabled = frameState && _chromeInfo.GlassFrameThickness != default(Thickness);
if (!_isGlassEnabled) { _SetRoundingRegion(null); }
else { _ClearRoundingRegion(); _ExtendGlassFrame(); }   // <-- always reached while DWM composition is on

So, with a style such as:

<Setter Property="shell:WindowChrome.WindowChrome">
  <Setter.Value>
    <shell:WindowChrome CaptionHeight="27" ResizeBorderThickness="5"
                        GlassFrameThickness="5" CornerRadius="5"/>
  </Setter.Value>
</Setter>

calling ShowDialog() at a moment when the render target is being torn down or recreated hits the null dereference. We suspect a DWM composition state change (remote-desktop reconnect, session lock/unlock, GPU driver reset) — the same circumstances reported in #11440.

Expected behavior

_ExtendGlassFrame() returns without doing anything when there is no composition target, consistent with the crash containment introduced in #11417.

Actual behavior

NullReferenceException. It is thrown inside Window.CreateSourceWindow, i.e. from within Window.ShowDialog(), so application code cannot meaningfully handle it.

System.NullReferenceException: Object reference not set to an instance of an object.
   at System.Windows.Shell.WindowChromeWorker._ExtendGlassFrame()
   at System.Windows.Shell.WindowChromeWorker._UpdateFrameState(Boolean force)
   at System.Windows.Shell.WindowChromeWorker._ApplyNewCustomChrome()
   at System.Windows.Window.CreateSourceWindow(Boolean duringShow)
   at System.Windows.Window.ShowHelper(Object booleanBox)
   at System.Windows.Window.ShowDialog()
   at MyApp.CustomPopupWindow.ShowDialog()        <-- application code below this point
   at MyApp.SomeScreen.OpenDetailPopup()

Regression?

No. This code path looks unchanged since the WPF Shell Integration Library was folded into the framework.

Known Workarounds

Set GlassFrameThickness="0" on the WindowChrome. _UpdateFrameState then computes _isGlassEnabled == false and _ExtendGlassFrame() is never called, so the crash path becomes unreachable.

The cost is losing the extended glass frame. _SetRoundingRegion is called instead, which applies a window region via SetWindowRgn — and per the rounded corners guidance, a window with a region can never be rounded by DWM, so this also opts the window out of Windows 11 corner rounding.

Impact

Affects any WPF application that uses WindowChrome with a non-zero GlassFrameThickness — a common pattern for custom title bars, including several third-party WPF UI libraries. Because _ApplyNewCustomChrome forces _UpdateFrameState(force: true), every window creation goes through the unguarded code, so the exposure is not limited to unusual windows. The crash cannot be handled by the application.

Configuration

• .NET 10.0 (net10.0-windows), WPF
• Windows 11, x64
• Appears correlated with environments where DWM composition state changes (remote desktop / VDI), but we cannot confirm this.

Other information

Suggested fix, in the same spirit as the containment added in #11417:

private void _ExtendGlassFrame()
{
    Assert.IsNotNull(_window);

    if (IntPtr.Zero == _hwnd)
    {
        // Can't do anything with this call until the Window has been shown.
        return;
    }

    // The composition target can be gone even when the HwndSource itself is not disposed,
    // so _UpdateFrameState's _hwndSource.IsDisposed check is not sufficient here.
    if (_hwndSource?.CompositionTarget is null)
    {
        return;
    }

    // ... unchanged
}

_RestoreGlassFrame (line 1142) needs the same treatment.

Related: #11440, #11417.

[m-smkim]

In the original report I wrote that I could not reproduce this deterministically and suspected a race around DWM composition state changes. That was wrong, and I want to correct it because it understates the problem.

This is 100% reproducible in our application. One specific popup window hits it every single time, on a specific code path. Other popup windows in the same application, using the same base class and the same WindowChrome style, never hit it.

What is specific to the failing case: the popup is closed while it is still being brought up. Its content control runs a query in its Loaded handler, and when the query returns no rows it shows an informational message and calls Close(). ShowDialog() on that window then throws.

This is consistent with the analysis in the original report: HwndSource.CompositionTarget returns null once the HwndSource or its HwndTarget has been disposed, and _ExtendGlassFrame() dereferences it without a null check. A window that is torn down before its source-creation sequence completes satisfies that condition — no race with DWM required.

I have not yet pinned down the exact point at which the teardown happens, or why other popups in the same application are unaffected. I will follow up if I can narrow it further. But the trigger being deterministic rather than timing-dependent seemed worth correcting straight away, since it changes how reproducible this is expected to be.

The suggested fix is unchanged:

if (_hwndSource?.CompositionTarget is null)
{
    return;
}

_RestoreGlassFrame needs the same treatment.

[m-smkim]

In the original report I wrote that I could not reproduce this deterministically and suspected a race around DWM composition state changes. That was wrong, and I want to correct it because it understates the problem.

This is 100% reproducible in our application. One specific popup window hits it every single time, on a specific code path. Other popup windows in the same application, using the same base class and the same WindowChrome style, never hit it.

What is specific to the failing case: the popup is closed while it is still being brought up. Its content control runs a query in its Loaded handler, and when the query returns no rows it shows an informational message and calls Close(). ShowDialog() on that window then throws.

This is consistent with the analysis in the original report: HwndSource.CompositionTarget returns null once the HwndSource or its HwndTarget has been disposed, and _ExtendGlassFrame() dereferences it without a null check. A window that is torn down before its source-creation sequence completes satisfies that condition — no race with DWM required.

I have not yet pinned down the exact point at which the teardown happens, or why other popups in the same application are unaffected. I will follow up if I can narrow it further. But the trigger being deterministic rather than timing-dependent seemed worth correcting straight away, since it changes how reproducible this is expected to be.

The suggested fix is unchanged:

if (_hwndSource?.CompositionTarget is null)
{
    return;
}

_RestoreGlassFrame needs the same treatment.