dwm.exe FAIL_FAST (purecall in dwmcore!CExpressionManager::UpdateExpressions) when browsing Microsoft Store product pages — Windows 10 22H2 19045

Question

dwm.exe FAIL_FAST (purecall in dwmcore!CExpressionManager::UpdateExpressions) when browsing Microsoft Store product pages — Windows 10 22H2 19045

MSH™ ® 31

Summary: dwm.exe terminates via fail-fast (FAST_FAIL_FATAL_APP_EXIT) when browsing product pages in the Microsoft Store app. The desktop composition restarts, producing a 1–2 second black screen. Reproducible on demand. The crash is a pure virtual call (ucrtbase!purecall) inside dwmcore!CExpressionManager::UpdateExpressions, indicating a virtual dispatch on an object whose destructor has already run — a use-after-destruction 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 from the same servicing branch ucrtbase.dll 10.0.19041.7181 GPU: NVIDIA RTX 4070 SUPER Last LCU/SSU installed: 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: Open the Microsoft Store app. Navigate between product pages (apps/games), scrolling and going back and forth. Timing varies: sometimes dwm.exe fail-fasts almost immediately — as soon as you open the Store page of an already-installed app — other times it takes a few minutes of browsing. This variability is consistent with a race condition rather than a deterministic fault., 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.

Investigation already performed (all ruled out): Third-party DLL injection: lm f on every dump shows only modules from C:\Windows\System32 and System32\DriverStore. No overlay/hook DLLs present at crash time. Overlay software (RTSS/Afterburner) was not loaded. User profile: reproduced on three separate profiles, including a freshly created local account with no Microsoft account signed in and no customization. Not profile-specific. 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 / multiplane overlay: HKLM\SOFTWARE\Microsoft\Windows\Dwm\OverlayTestMode = 5 (MPO disabled) was already set before the crashes began. Not related. Graphics driver: the faulting stack never enters the display driver or D3D device creation. No nvlddmkm TDR (Event ID 4101) accompanies these crashes. Not a buffer overrun: 0xc0000409 with subcode 0x7 is a deliberate abort(), not memory corruption. WER's generic "stack buffer overrun" text is misleading here.

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.

Note on the code path: The frames from CExpressionManager::UpdateExpressions downward match the stack documented publicly in the analysis of CVE-2023-36033 (dwmcore.dll privilege escalation, exploited in the wild), including identical offsets for CComposition::PreRender+0xdf6 and CPartitionVerticalBlankScheduler::ProcessFrame+0x55f. The trigger differs (that was an attacker-controlled DCOMPOSITION_EXPRESSION_TYPE_PATH; this is a purecall), but it establishes prior history of object-lifetime fragility in this specific function.

Artifacts: Four full user-mode dumps with full memory (~600–800 MB each) are available on request. Not attached due to size.

0 comments

1 answer

Your answer

Answer 1

Hi MSH™ ®,

Thank you for sharing such a detailed analysis. I can see you've already performed far more extensive testing and investigation than most users would typically undertake. However, while your findings may suggest a potential issue within the Windows composition stack, there is currently no documented Windows 10 22H2 issue matching the behaviors you described.

And since Microsoft Q&A is a user-to-user support forum, contributors here do not have access to internal tools or backend resources. Realistically, I don't think anyone here can confirm your theory, or escalate it for further investigation. Given those limitations, consider reporting this through Microsoft’s official channels:

Press Win + F to open Feedback Hub > submit under relevant category.
I recommend including the same information you provided above.
Attach at least one of the full user-mode dumps (if possible).

While posting here may help attract others who have observed similar behavior, it is unlikely that the thread itself will be reviewed by the Windows engineering team. Since you already have multiple full dumps and a reliable repro, this should be useful for investigation if submitted through the correct channel.

That said, I also need to note that Windows 10 already reached end of support. So even if your analysis is correct, there is no guarantee that a fix would be produced for Windows 10 at this stage of its lifecycle.

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

MSH™ ® 31 Reputation points

2026-08-02T08:31:14.0633333+00:00

Lychee-Ng , thank you for the honest and detailed reply — genuinely appreciated, especially the candor about Windows 10's support status. I doubt Feedback Hub will let me attach the dump directly given its size, but I'll try uploading it to OneDrive and sharing the link instead. That said, given everything you've explained, I've lost any real hope this will go anywhere — I suspect this will end up being a waste of time on my part. Still, at least the analysis stays documented here for anyone who runs into the same signature.
Lychee-Ng 28,915 Reputation points Microsoft External Staff Moderator

2026-08-03T08:36:39.3+00:00

Yes, the situation does seem dire. But it's not like the end of the road, given that there are still many people actually remain using Windows 10! So your report might not go to waste, especially with this much information. I hope the engineering team will look into it!