[FIXED ~95%] Touch Dial crashed unexpectedly (0xC0000409)

Touch Dial — Crash Notice.
 

Touch Dial crashed due to a known bug in Microsoft’s WinUI 3 framework (InputStateManager.dll). This is triggered by touch input and is not caused by TouchDial.
 

Error code: Error: STATUS_STACK_BUFFER_OVERRUN (0xC0000409)
 

Microsoft Issue #10929 — WinUI3 touch crash
Microsoft Issue #10674 — Multi-touch crash

This bug is not caused by Touch Dial. ALL Win UI3 applications are hitting this Microsoft Bug. I am monitoring Microsoft’s fix.
 

Touch Dial v1.0.8+ will now display a message that displays this when the logfile has reported the error that matches this issue.
It will only be displayed if the last crash matches this issue.

Touch Dial v1.0.12+ alongside ColorDial Plugin v1.9+ has a workaround that I have implemented that has managed to lower the crash rate down by 95%. This is both by design and a happy little accident (Miss you Bob Ross); Github link at the end has the complete details.

================================
UPDATE — March 9, 2026
================================

MS’ bug is still ongoing, I tried my best to implement a workaround.

Adding details below as reference as it might be useful to other people that might have this issue.

A combination of fixes were implemented into the Plugin as well as the main application since it did still encounter the same crash but just not as often as when the plugin installed.

================================================================================
WHY OTHER APPS DON’T HIT THIS BUG
================================================================================

The crash is in the “Lifted Input” stack — code that Microsoft extracted from the OS into a separately-shipped DLL (Microsoft.InputStateManager.dll) so it could be updated via NuGet independently. This lifted copy is ONLY used by WinUI 3 / Windows App SDK apps.

– Win32 apps get touch input via WM_POINTER messages directly from the kernel
– WPF apps use their own input dispatcher built on HwndSource + WM_POINTER
– UWP apps use the system-level (non-lifted) CoreInput stack baked into Windows
– Windows shell/Explorer is pure Win32

The lifted copy is less mature and less tested than the OS-integrated version. TouchDial is especially affected because it’s a touch-heavy WinUI 3 app.
 

================================================================================
WORKAROUND IMPLEMENTED: InputThrottleHelper
================================================================================

Workaround: We subclass the top-level HWND and all WinUI internal child windows (InputSite, DesktopChildSiteBridge) using SetWindowSubclass + EnumChildWindows. The callback throttles WM_POINTER messages to 125 Hz and limits concurrent touch contacts to 1. Call InstallWithChildren(hwnd) after the window loads so child HWNDs exist.

Paradox: On some OS builds (e.g., 10.0.26200.0), WM_POINTER never reaches any HWND — our counter shows pointer_msgs=0. Yet crashes dropped ~95%. The subclass inserts a callback into the message chain for all Win32 messages, not just pointer messages. The overhead of evaluating every message through the switch(uMsg) slows the overall message pump by microseconds, giving InputStateManager’s race condition enough breathing room. With 4–5 HWNDs subclassed, this effect compounds. The fix works through an unintended mechanism — message pipeline slowdown — making it effective regardless of how the OS routes touch internally.
 

Final complete solution needs to be implemented on Microsoft’s WinUI 3 framework (InputStateManager.dll) by Microsoft.

Complete details available on Github

95%+ of crashes Fixed* by:
Touch Dial v1.0.12 <— Available now.
ColorDial v1.0.9 <– Available now.