26

I have a .NET application that throws the following exception:

System.ComponentModel.Win32Exception : Not enough quota is available to process this command 
   at MS.Win32.UnsafeNativeMethods.PostMessage(HandleRef hwnd, Int32 msg, IntPtr wparam, IntPtr lparam) 
   at MS.Win32.ManagedWndProcTracker.HookUpDefWindowProc(IntPtr hwnd) 
   at MS.Win32.ManagedWndProcTracker.OnAppDomainProcessExit() 
   at MS.Win32.ManagedWndProcTracker.ManagedWndProcTrackerShutDownListener.OnShutDown(Object target) 
   at MS.Internal.ShutDownListener.HandleShutDown(Object sender, EventArgs e)

I can't reproduce this exception personally, but I get lots of exception reports from users.

What is the 'quota' being referred to? The stack trace leads me to believe that it might be a problem with the Windows message queue.

Any ideas about what might cause this error, or how to fix it would be greatly appreciated.

EDIT, further info: This is on 32 bit Windows XP on all machines, and the exception is not in my code as such, but a .NET Framework event handler of some sort. The application itself does not make any PostMessage calls.

sackoverflow
  • 767
  • 1
  • 6
  • 16

4 Answers4

12

The amount of Windows resources of a specific type that a process could allocate is technically only restricted by the amount of virtual memory available to a process. Which can be a rather large number, especially on the 64-bit version of Windows. Some of these resources are withdrawn from an internal heap from which all other processes withdraw as well. Still a very large number if Windows would let one process consume it all.

Which of course doesn't make sense, a process should never be allowed to gobble up all available resources. Which is what a quota does, it sets an upper limit to the counted number of resources of a certain type. Common examples are 10,000 windows, 10,000 GDI objects, 10,000 handles. Not all of them are nice round numbers like this btw.

It would take knowing more about what your PostMessage() call does, but a reasonable guess is that it is pushing the message queue size past the quota. Again, a resource that's technically only limited to the size of available virtual memory. But practically should stay well south of that. If accurate, you are posting messages faster than they can be consumed, throttling is required. That this happens at the exact time your program is terminating suggests another explanation might be necessary. A thread shutdown order problem, maybe.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • 1
    So the quota is a per process limit on (presumably) message queue size. I suppose my next question is how do I discover why the queue is getting so big, one for another post I suppose. – sackoverflow Feb 18 '11 at 11:26
  • 3
    I beleive my answer is more accurate, Hans suggests this is a message **queue** problem, but I think it's a 10,000 message sent limit instead. So to bypass this, either send far less messages, increase the registry value for this limit, or restart your message queue on exception. See http://msdn.microsoft.com/en-us/library/ms644944(VS.85).aspx for more info. – servermanfail Feb 20 '11 at 15:16
  • @servermafail, thanks for help. To clarify - my code doesn't send any messages, if you look at the stack trace you can see that it's .NET framework code making the PostMessage call on (appdomain?) shutdown. The application doesn't explicitly call PostMessage or HandleShutdown. The app runs on hundreds of machines, altering the registry settings is not really an option on any of them. – sackoverflow Feb 22 '11 at 22:02
  • This answer doesn't help me; my callstack also consists purely of .NET framework code. So WPF is broken by design? – springy76 Feb 28 '12 at 14:32
  • yeh this was very helpful. I found we were accidentally posting to a SynchronizationContext 13,000 times which was causing this exact error. – stuzor Aug 04 '21 at 00:57
5

According to MSDN:

There is a limit of 10,000 posted messages per message queue. This limit should be sufficiently large. If your application exceeds the limit, it should be redesigned to avoid consuming so many system resources. To adjust this limit, modify the following registry key. 

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\USERPostMessageLimit

The minimum acceptable value is 4000.

Ian Kemp
  • 28,293
  • 19
  • 112
  • 138
servermanfail
  • 2,532
  • 20
  • 21
  • 1
    This worked for me, nothing changed about our app... The bazaar thing is that a co-workers pc with win 8 and same limit, the screen works fine but on mine win 8.1 it doesn't... – Mark Boltuc Nov 05 '13 at 21:47
0

It could be NTFS Quotas. For more information, see http://technet.microsoft.com/en-us/library/cc786220(WS.10).aspx

servermanfail
  • 2,532
  • 20
  • 21
  • I don't think it's that. None of the users machines should have NTFS quotas configured. – sackoverflow Feb 17 '11 at 17:23
  • Don't underestimate the pervasiveness of Group Policy, Network Storage and/or Citrix and Terminal Server. – Dave White Feb 17 '11 at 17:32
  • Thanks I won't, but as I can't find any evidence that quotas are enabled - I have to assume there is no link between the exception and NTFS quotas (other than the word quota!) – sackoverflow Feb 17 '11 at 17:39
0

The solution from here is:

My solution was to go to Control Panel>Offline Files and increase the amount of disk space available to both offline files in general and the temporary space (for the sake of simplicity, I increased it by the same amount of the number of files I needed to move but less would probably have done).

Chris Haas
  • 53,986
  • 12
  • 141
  • 274
  • Thanks, I already found that technet post but discounted it as the app does not attempt to sync any files and offline files are disabled on users machines by group policy. – sackoverflow Feb 17 '11 at 17:45