Dispatcher processing has been suspended, but messages are still being processed exception in WPF application

• .NET Core Version: (e.g. 3.0 Preview1, or daily build number, use dotnet --info) .NET Core SDK used to build: 3.1.302
• Windows version: (winver) 18363.0, 19041.388, 19041.0
• Does the bug reproduce also in WPF for .NET Framework 4.8?: Not tested
• Is this bug related specifically to tooling in Visual Studio (e.g. XAML Designer, Code editing, etc…)? No
• Security issues and bugs should be reported privately, learn more via our responsible disclosure guidelines.

Problem description:

We have been getting reports of users hitting the following exception on our WPF app. There don’t seem to be any specific steps, but the exception that the users are hitting is:

System.InvalidOperationException: Dispatcher processing has been suspended, but messages are still being processed.
at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)`

https://github.com/microsoft/PowerToys/issues/5658 is the linked issue on our repository, and this is the code base for the WPF project which is throwing the exception. A couple of users mentioned they hit this while just typing in the search TextBox, and one user mentioned it occurred while typing in the TextBox and scrolling in the ListView with their mouse simultaneously. I couldn’t find any documentation which explains this WPF error. This StackOverflow post was the only source of information I could find, which mentioned that this error could happen if you try to change the visual state inside a visual state handler and the error appears to prevent reentrancy problems. But the odd part is that the exception doesn’t always occur for them, and as per the answers, users just avoid it by adding Dispatcher.BeginInvoke around a code path if such an exception is observed and there doesn’t seem to be a doc which points out what kind of code paths can be problematic, so I don’t know if this is the recommended way to go about it. I don’t think we have any code path where a visual state is changed explicitly inside a visiblity changed handler (as shown in the example in the StackOverflow post), and adding Dispatcher.BeginInvoke on all binding updates could cause performance issues because of unnecessary messages on the dispatcher thread.

We haven’t been able to reproduce the exception locally, so it we can’t test if any of the changes mentioned above will actually fix the exception. It would be great if anyone in the community could provide some insights on what causes the exception and what could be done to avoid it. If we can get a reliable repro it would make debugging much easier.

Actual behavior:

System.InvalidOperationException: Dispatcher processing has been suspended, but messages are still being processed.
at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)`

Expected behavior: No exceptions

Minimal repro: Unable to reproduce locally.

[phenni01]

Like @ole1986, we see this a lot in Citrix. Not a new issue, has been so for the last 10 years or so.

[SamBent]

@arjunbalgovind @crutkas - Hard to say anything helpful. This is a generic error that comes up when WPF suspends its message pump temporarily, typically to avoid re-entrancy during some operation that can’t withstand it - the chief example is layout. If the message pump runs anyway, you get this error. But it doesn’t say why the pump was suspended, or what caused it to run anyway; these can only be answered by digging through a repro or TTD trace, or possibly a full crash dump (with luck). Got any of those?

I’ve seen this error when running debug WPF bits, and hitting a situation when the layout engine calls into code that fails a Debug.Assert. The assert tries to bring up a new window to display the callstack, which forces messages to pump while layout has suspended the dispatcher. But I doubt that explains your problem.