Wpf: Not enough quota when opening Window

[NickeManarin]

After updating my WPF app from 4.6.1 to 4.8, users started getting this exception (multiple times in a row) when opening windows:

• Message - 
    Not enough quota is available to process this command
• Type - 
    System.ComponentModel.Win32Exception
• Source - 
    PresentationCore
• TargetSite - 
    Void UpdateWindowSettings(Boolean, System.Nullable`1[System.Windows.Media.Composition.DUCE+ChannelSet])
• StackTrace - 
   at System.Windows.Interop.HwndTarget.UpdateWindowSettings(Boolean enableRenderTarget, Nullable`1 channelSet)
   at System.Windows.Interop.HwndTarget.UpdateWindowPos(IntPtr lParam)
   at System.Windows.Interop.HwndTarget.HandleMessage(WindowMessage msg, IntPtr wparam, IntPtr lparam)
   at System.Windows.Interop.HwndSource.HwndTargetFilterMessage(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)

Unfortunately, I could not get this exception on my machine, so I can't really understand what's happening.

I already tried setting HandleDispatcherRequestProcessingFailureOptions.Reset, but people are still reporting crashes to me.

What could possibly be happening? Is there any way to fix this or maybe set an workaround?

[fabiant3]

We'd need a repro to further investigate. Let us know if you can supply one.

You should set HandleDispatcherRequestProcessingFailureOptions to Throw, that will crash the app, hopefully you can get a callstack that way?

[NickeManarin]

Well, I can't reproduce it too with my project. That's the problem.
That's why I'm asking what could cause that exception.

This is my project, some users are triggering the exception when opening the recorder.

Setting the property HandleDispatcherRequestProcessingFailureOptions.Throw sometimes will trigger an exception when using the editor window, but not the same exception.

[SamBent]

The exception happens when HwndTarget fails to post a message to its HWND, because its message queue is full. This is often the app's fault, running a long method on the UI thread and thus not giving the dispatcher a chance to handle incoming messages. Other activity on your machine might contribute by posting messages to the HWND faster than it can handle, but this is rarer.

[NickeManarin]

My computer got slow recently, due to having too many things open, and while testing the app with the option Throw I got this exception:

System.InvalidOperationException
  HResult=0x80131509
  Message=The Dispatcher is unable to request processing.  This is often because the application has starved the Dispatcher's message pump.
  Source=WindowsBase
  StackTrace:
   at System.Windows.Threading.Dispatcher.OnRequestProcessingFailure(String methodName)
   at System.Windows.Threading.Dispatcher.RequestForegroundProcessing()
   at System.Windows.Threading.Dispatcher.CriticalRequestProcessing(Boolean force)
   at System.Windows.Threading.Dispatcher.InvokeAsyncImpl(DispatcherOperation operation, CancellationToken cancellationToken)
   at System.Windows.Threading.Dispatcher.LegacyBeginInvokeImpl(DispatcherPriority priority, Delegate method, Object args, Int32 numArgs)
   at MS.Win32.HwndWrapper.Dispose(Boolean disposing, Boolean isHwndBeingDestroyed)
   at MS.Win32.HwndWrapper.Finalize()

I'm not sure what triggered this. I remembered the app calling an async+delegate method to deleted stuff.
But I'm not able to trigger again. :/

Isn't there a reliable way to detect this kind of crash? At least what causes it?
Or better, is there a way to detect who is using the message pump?

[SamBent]

Sadly, no. Both your crashes occur when WPF tries to post a message to a window whose message queue is full (i.e. has 10,000 pending messages). The queue is private to the kernel, so you'd need a kernel debugger to look at the messages, and even then you wouldn't know who sent them or why the dispatcher's message pump hasn't kept up.

The point of the 'Throw' option is to help you (the app author) debug the problem. When the exception occurs, you might know what your app was doing recently, and/or who was sending it messages (perhaps with the help of Spy++ or a similar tool that records message traffic). With luck, you'll say "Aha! My app was holding the UI thread for 5 seconds", and you'll know how to fix the problem.

[NickeManarin]

Ohh, okay. Thank you for your help. :)
I'm going to close this issue, since a problem on my end.
If I ever find which parts of the app are the culprit, I'll post it in here.

[vatsan-madhavan]

@SamBent I recommend capturing very useful repeatable responses like this under documentation\ in the repo.

<

[NickeManarin]

@SamBent While testing more (with HandleDispatcherRequestProcessingFailureOptions to Throw), I noticed that after hitting the second or third Dispatcher.Invoke(action), the app will crash after finishing executing the action. That's strange, I would expect it to crash when invoke starts.

Switching to Dispatcher.BeginInvoke(action) helps, at least in my tests.

Strange that I don't get the exceptions when running without setting HandleDispatcherRequestProcessingFailureOptions to Throw. What's the reason for that?