dwm.exe fail-fast: purecall in dwmcore!CExpressionManager::UpdateExpressions (Win10 22H2 19045) — reproducible, need eyes / workaround

[Insider]

I've isolated a reproducible dwm.exe fail-fast on Windows 10 22H2 and I'm looking for either confirmation that this is a known dwmcore issue in the 19041 branch, or a viable workaround. Microsoft's own reporting channels have been a dead end (Q&A auto-deletes the write-up, Feedback Hub can't hold the detail), so I'm bringing the full analysis here where it might actually be understood.

Full diagnosis below — dumps ruled out third-party injection, driver, profile, and AppX state; it reproduces across three separate user profiles including a fresh one.

Summary

dwm.exe terminates via fail-fast when browsing product pages in the Microsoft Store app. Desktop composition restarts, producing a 1–2 second black screen. Reproducible on demand.

The termination is a pure virtual call (ucrtbase!purecall) inside dwmcore!CExpressionManager::UpdateExpressions, i.e. a virtual dispatch on an object whose destructor has already run — an object-lifetime race in the expression evaluator, on the composition (vblank) thread.

Environment

• Windows 10 22H2, build 19045 (build lab 19041.1.amd64fre.vb_release.191206-1406)

• dwm.exe 10.0.19041.7417

• dwmcore.dll same servicing branch

• ucrtbase.dll 10.0.19041.7181

• GPU: NVIDIA RTX 4070 SUPER

• Last LCU/SSU: KB5094145 + KB5094127 (2026-06-12)

Crash signature (identical across all four captured dumps)

Failure.Bucket:  FAIL_FAST_FATAL_APP_EXIT_c0000409_ucrtbase.dll!abort
Failure.Hash:    {e31753ac-c98a-8055-3663-47e707543d20}
Exception Code:  0xc0000409
Subcode:         0x7 FAST_FAIL_FATAL_APP_EXIT

Stack, identical in every dump, same offsets:

ucrtbase!abort+0x4e
ucrtbase!purecall+0x2d
ucrtbase!__crt_state_management::wrapped_invoke<int (__cdecl*)(void),int>+0x18
dwmcore!CExpressionManager::UpdateExpressions+0x112
dwmcore!CComposition::PreRender+0xdf6
dwmcore!CPartitionVerticalBlankScheduler::ProcessFrame+0x55f
dwmcore!CPartitionVerticalBlankScheduler::ScheduleAndProcessFrame+0xb4
dwmcore!CConnection::RunCompositionThread+0x21d
kernel32!BaseThreadInitThunk+0x14
ntdll!RtlUserThreadStart+0x21

Repro steps

1. Open the Microsoft Store app.

2. Navigate between product pages (apps/games), scrolling and going back and forth.

3. Within a few minutes dwm.exe fail-fasts. Screen goes black 1–2 seconds while composition restarts.

Timing varies between sessions — consistent with a race condition rather than a deterministic fault.

Already ruled out

• Third-party DLL injection: lm f on every dump shows only modules from C:\Windows\System32 and System32\DriverStore. No overlay or hook DLLs loaded at crash time.

• User profile: reproduced on three separate profiles, including a freshly created local account with no Microsoft account signed in and no customization.

• AppX package state: Store package fully unregistered and re-registered from the on-disk provisioned copy. Status: Ok, IsPartiallyStaged: False, SignatureKind: Store. Crash persists.

• App local state: %LOCALAPPDATA%\Packages\Microsoft.WindowsStore_8wekyb3d8bbwe renamed, forcing full regeneration. Crash persists with a freshly generated cache.

• MPO: HKLM\SOFTWARE\Microsoft\Windows\Dwm\OverlayTestMode = 5 was already set before the crashes began.

• Graphics driver: the faulting stack never enters the display driver or D3D device creation. No nvlddmkm TDR (Event ID 4101) accompanies these crashes.

• Not memory corruption: 0xc0000409 with subcode 0x7 is a deliberate abort() from a fail-fast path, not a corrupted stack.

Timeline

Reliability Monitor shows a perfect stability index (10/10, zero events) from 2026-06-13 through 2026-06-20. On 2026-06-21 a Store package update failed (Installation Failure ... error 0x80073D02: 9WZDNCRFJBMP-MICROSOFT.WINDOWSSTORE). The first dwm.exe crashes appear on 2026-06-22 and have recurred since. Whether the failed deployment is causally related or coincidental is unclear — the crash persists after a complete package rebuild.

Artifacts

Four full user-mode dumps with full memory (~600–800 MB each) available on request.

I'm aware this is Windows 10 on ESU, so a fix from Microsoft is unlikely. What I'm hoping for:

1. Has anyone seen this specific signature (purecall in CExpressionManager::UpdateExpressions) before, or is it new?

2. Is there any known workaround at the dwmcore / composition level short of avoiding the Store UI entirely?

3. Is there a channel that actually reaches the composition team, given that Q&A and Feedback Hub have both been dead ends?

Full dumps available if anyone wants to look. Thanks for reading.

[Insider]

Update: identified the object's vtable at the moment of the failed call

For anyone following this — I went one level deeper into the dump. At .ecxr, rdi holds the this pointer for the virtual call that fails:

0:002> dps @rdi L1
0000021c`6e13c9c0  00007ffd`851b5588 dwmcore!CMILCOMBase::`vftable'

ln poi(@rdi) confirms it resolves exactly to dwmcore!CMILCOMBase::vftable, the base COM object class for MIL/DirectComposition resources — not a leaf expression type.

Given that C++ rewrites an object's vptr as each destructor in the chain runs (most-derived first, base last), landing on the base vtable here is consistent with catching the object mid-destruction: the derived expression class's destructor has already run and reset the vptr to CMILCOMBase, while the composition thread still held a live pointer to it and attempted a virtual call that lands on a pure stub in the base — hence purecall.

So this looks like a textbook partial-destruction race on a COM-style object in dwmcore, not memory corruption. Unfortunately the original derived type is unrecoverable from this dump alone — by the time of the failing call the vptr has already been overwritten, and there's no way to reconstruct it without private symbols/source.

Posting this in case it rings a bell for anyone who's worked with the MIL/DirectComposition object model — happy to pull anything else from the dumps if it'd help narrow down which expression subtype this was.