WindowFX causes a white screen during the process of restarting or shutting down the OS. There is an issue with dwm.exe. Here is the windbg report :

Bug Report: WindowFX causes dwm.exe crash (Control Flow Guard violation) during system shutdown/restart

Summary

WindowFX's 64-bit module (wfx4_64.dll) crashes dwm.exe during Windows shutdown/restart. The crash is a Control Flow Guard (CFG) violation — Windows fails the process with FAIL_FAST_GUARD_ICALL_CHECK_FAILURE when WindowFX's DLL-detach cleanup code calls into d3d11.dll through a function pointer that CFG considers invalid.

This is fully reproducible and confirmed via WinDbg analysis of a full memory dump.

Environment

• OS: Windows 11, build 10.0.26100.8737 (branch ge_release)
• Architecture: x64
• WindowFX: 32-bit engine executable installed (wfx32.exe), but the crashing module loaded inside dwm.exe is the 64-bit component wfx4_64.dll

Steps to reproduce

1. Have WindowFX running normally (service + engine active, hooked into DWM composition as usual).
2. Trigger a normal system restart or shutdown from the Start menu (a logoff/sign-out alone does not trigger this — only full shutdown/restart does).
3. dwm.exe crashes during teardown. Visually this often appears as a white screen (not the normal black screen) right before/during the restart, especially noticeable on large displays.
4. The crash is logged in Windows Reliability History and Event Viewer (Application log) as:
   • Event Name: BEX64
   • Faulting application: dwm.exe
   • Faulting module: StackHash_b147 (unresolved — see full analysis below for the real cause)
   • Exception code: c0000409

Root cause (confirmed via WinDbg dump analysis)

A full dump of dwm.exe was captured at the moment of the crash (via WER LocalDumps) and analyzed with WinDbg (!analyze -v). Key findings:

FailFast.Name: GUARD_ICALL_CHECK_FAILURE
Failure.Bucket: FAIL_FAST_GUARD_ICALL_CHECK_FAILURE_c0000409_d3d11.dll!CLayeredObject_CClassLinkage_::CContainedObject::Release
Exception code: 0xc0000409 (Subcode 0xa — FAST_FAIL_GUARD_ICALL_CHECK_FAILURE)

Relevant call stack (top of the crashing thread, which is DWM's own event thread):

uDWM!CDesktopManager::DwmEventThreadProc
 -> user32!PeekMessage / _ClientFreeLibrary   (DWM is unloading a DLL)
   -> ntdll!LdrUnloadDll
     -> ntdll!LdrpProcessDetachNode            (DLL_PROCESS_DETACH is being called)
       -> wfx4_64!UpdateSetting+0x232b         (WindowFX's own cleanup code)
         -> d3d11!CLayeredObject<CClassLinkage>::CContainedObject::Release
            [CFG detects an invalid indirect call target here -> FAST_FAIL]

Interpretation: When Windows unloads wfx4_64.dll from dwm.exe as part of the shutdown teardown sequence, WindowFX's own detach/cleanup routine (UpdateSetting) attempts to release a Direct3D 11 object (CContainedObject::Release) through what appears to be a stale or already-invalidated function pointer/vtable entry. Control Flow Guard correctly identifies this as an illegal indirect call and fails the process, crashing dwm.exe.

This strongly suggests that at shutdown, some part of WindowFX's D3D11 resource cleanup runs after the underlying object (or its vtable) has already been partially torn down — a teardown-ordering / cleanup race condition inside WindowFX's own shutdown path, not a general system issue.

Workaround found (does not fix the root cause)

Delaying the actual shutdown/restart by a short interval (e.g. via shutdown.exe -r -t <seconds> instead of an immediate restart) reliably eliminates the visible white-screen symptom. This is consistent with the crash being a race condition: the extra delay likely gives WindowFX's normal cleanup path time to release its D3D11 resources properly before Windows forces the DLL unload. Depending on the delay length, the underlying BEX64 crash may still be logged even though the visible symptom disappears — the delay reduces/avoids the race but is not confirmed to eliminate it entirely in all cases.

Request

Could you investigate the D3D11 resource cleanup path in wfx4_64.dll's UpdateSetting function (and whatever it calls near offset +0x232b) for a use-after-free or premature-unload scenario during application/module shutdown? A full memory dump (dwm.exe, ~845 MB) is available and can be provided if useful for your engineering team.

Thank you for looking into this.