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...