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

WINDBG
1

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.