-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Win32Exception (0x80004005): Not enough quota is available to process this command. #137
Comments
Message queues have a limit described in the documentation for PostMessage. Flooding an application with window messages is expected to cause this exception. This is by design. BTW, this will happen on WPF on .NET Framework as well. |
@vatsan-madhavan So, what's the recommended way to avoid this kind of app crash? |
An application architecture that hits that 10000 message limit would need to be changed, I’m afraid. Also, see But then we ran into problems when we started posting 10,000 messages per second. |
This kind of bug report is observed in other UI technologies as well. We hear about this either as a bug report or a crash report now and then, and we usually recommend looking into the application architecture and finding out why the message queue is flooding rapidly. WPF has a flag that you could use to aid in such a diagnosis. Please take a look at When you set it to [Additional debugging tips courtesy of my colleague Sam Bent] |
@vatsan-madhavan I also met this issue in .net framework 4.6.1, and i can't find this flag :BaseCompatibilityPreferences.HandleDispatcherRequestProcessingFailure in 4.6.1 |
That flag doesn’t exist in 4.6.1. It was introduced in 4.7.1. |
Thanks @vatsan-madhavan for the detailed information, it's always nice to learn something every day. I'm going to close this issue since it seems that this issue is by design (and unrelated to WPF specifically). @walterlv if you think that is wrong and there is actually a fundamental issue with WPF, please reply and we can continue the discussion. |
@stevenbrix Thanks for your reply. |
I found out that sInce .NET 4.7 this happens pretty randomly on locks, I initially thought my problem was caused by deadlocks but it was caused by this. the reason for this to happen is using the same synchronization object in one method that has await keyword and in another that doesn't. Lets say you got method without await on button click and the other one with await that executes as some kind of delayed response. If you click button 2-3 times everything will be okay, but if you click it repeatedly 5-15, it will freeze the app and eventually throw 'not enough quota'. Fix for this is to make the other method async, without changing any logic. I recently debugged this scenario extensively and I am sure it is not caussed by my code. |
Could you please attach the solution which reproduces the behavior? |
@rvnlord I would like to see a solution that reproduces the behavior too. |
same issue |
Problem description:
We sometimes get an
Win32Exception (0x80004005)
report from end-user' device, but we can't determine what happed at that time.Actual behavior:
We sometimes get a feedback from the end-user that the app freezes at that moment when the exception is thrown.
Expected behavior:
There is no such an exception.
Minimal repro:
Note that we still can't figure out all the reproduction, but I find a simple procedure to reproduce it.
The text was updated successfully, but these errors were encountered: