问题
Most of the time working as a .Net developer gives us the freedom to mess around in our high-level-of-abstraction world, but sometimes reality kicks you in the private parts and tells you to find a man who really understands.
I've just had one of those experiences. I think it'll suffice to list the corner data as an item list for you to understand what we have here:
- Win2008 Server
- 64Bit Environment
- WPF Application used by multiple Clients simultaneously
- Application is a launcher, that opens other applications using Process.Start()
- Occasionally we get the exception listed below
System.ComponentModel.Win32Exception (0x80004005): Not enough quota is available to process this command at MS.Win32.UnsafeNativeMethods.PostMessage(HandleRef hwnd, WindowMessage msg, IntPtr wparam, IntPtr lparam) 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 MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(Object source, Delegate method, Object args, Int32 numArgs, Delegate catchHandler)
EDIT #1 After some inspection, here's more detail:
Launching is a 2-Step-Process, the Launcher launches an intermediate window using Process.WaitForExit()
From the intermediate window, further processes can be started in the same way (Process.WaitForExit).
With only the intermediate window open and no user interaction, the launcher process's number of handles increases over time. The maximum increase we've seen here is 400 --> 6000 handles.
The facts added in the Edit really make me wonder whether there might be a handle leak in the framework somewhere. I'm trying to isolate the problem and check whether I can reproduce it from scratch. In the meantime, any kind of hint, idea, support or even chocolate is gladly accepted!
EDIT #2 : In an attempt to make the process responsive to PostMessage()
, we removed the Thread.WaitForExit
. Instead, we added a Handler for the Process's Exited event and sent the Launcher into a loop like the following:
while (foo == true)
{
System.Threading.Thread.Sleep(1000);
}
The Exited-Handler sets foo
to false and does nothing else.
Still, the number of Handles rises (400 to 800 in half an hour).
EDIT #3 Here comes something interesting, at last.
while (foo == true)
{
System.Threading.Thread.Sleep(1000);
GC.Collect();
}
This keeps it the way it's supposed to be, few handles, all nifty. Now that makes me wonder what's wrong here...I'll talk to the developer in charge again to check back what else the launcher does. So far, I've heard that it reads a few config values using XmlDocument.Load(), which is not an IDisposable
- makes it kind of hard to produce any leakage here...
回答1:
The error is telling you that a window's message queue reached its max capacity when posting a message to it. That means the thread that owns that window is not processing messages fast enough, if at all.
回答2:
I know this question is six years old, but we have just had the same issue happen to us, and I used this for inspiration. What I didn't like though is the idea of sleeping the thread and a loop.
Instead, I created a WPF window. Made it transparent and one pixel high and wide, and added a public property of type Process to it.
Then, instead of calling .WaitForExit, I wrote a Shared Sub (sorry, I'm using VB.NET terminology) that does the following
Public Shared Sub DoWaitForProcessToExit(ByVal poProc As Process, ByVal oOwner As Window)
Dim oWFE As WaitForProcessToExit
poProc.EnableRaisingEvents = True
oWFE = New WaitForProcessToExit
oWFE.oProc = poProc
If Not oOwner Is Nothing Then
oWFE.Owner = oOwner
End If
oWFE.ShowDialog()
oWFE = Nothing
End Sub
JUST in case something mad happens and the process has already exited by the time this dialog is activated:
Private Sub WaitForProcessToExit_Activated(sender As Object, e As EventArgs) Handles Me.Activated
Try
If oProc.HasExited Then
Try
RemoveHandler oProc.Exited, AddressOf oProc_Exited
Catch ex As Exception
End Try
'whatever happened .... it seems to have gone too quick for this to invoke the _Exited event
Me.Close()
End If
Catch
Try
Try
RemoveHandler oProc.Exited, AddressOf oProc_Exited
Catch ex As Exception
End Try
Me.Close()
Catch
End Try
End Try
End Sub
Now I only have to do this when the dialog is loaded:
Private Sub WaitForProcessToExit_Loaded(sender As Object, e As RoutedEventArgs) Handles Me.Loaded
AddHandler oProc.Exited, AddressOf oProc_Exited
End Sub
And then just respond to the Exited event. No Sleeps, no loops.
Private Sub oProc_Exited(sender As Object, e As EventArgs)
'This event is raised by the exiting process, which is in a different thread, so, invoke my own
'close method from my own Dispatcher
Windows.Application.Current.Dispatcher.Invoke(Sub() CloseMe(), Windows.Threading.DispatcherPriority.Render)
End Sub
Private Sub CloseMe()
Me.Close()
End Sub
来源:https://stackoverflow.com/questions/10086985/diagnosis-on-quota-exceeded-win32exception