在大多数情况下作为一个.NET开发人员给了我们自由地浪费时间在高层次，抽象的我们的世界，但有时现实踢你的私处，并告诉你找到一个男人谁的真的的理解。

我刚刚的这些经验之一。我认为这将足以列出栏目数据作为一个项目列表让你了解我们在这里：

在Win2008的服务器 在64位环境 由多个客户端同时使用在WPF应用程序 应用程序是一个发射器，打开使用的Process.Start其他应用程序（） 有时，我们得到下列异常

  System.ComponentModel.Win32Exception（0X80004005）：没有足够配额
处理此命令
在MS.Win32.UnsafeNativeMethods.PostMessage（HandleRef HWND，
   WindowMessage味精，IntPtr的WPARAM，IntPtr的LPARAM）
在System.Windows.Interop.HwndTarget.UpdateWindowSettings（布尔
   enableRenderTarget，Nullable`1 channelSet都）
在System.Windows.Interop.HwndTarget.UpdateWindowPos（IntPtr的lParam的）
在System.Windows.Interop.HwndTarget.HandleMessage（WindowMessage味精，
   IntPtr的WPARAM，IntPtr的LPARAM）
在System.Windows.Interop.HwndSource.HwndTargetFilterMessage（IntPtr的HWND，
   味精的Int32，IntPtr的wParam中，IntPtr的lParam的，布尔和放大器;处理）
在MS.Win32.HwndWrapper.WndProc（IntPtr的HWND，味精的Int32，IntPtr的wParam中，IntPtr的lParam的，
   布尔和放大器;处理）
在MS.Win32.HwndSubclass.DispatcherCallbackOperation（对象o）
在System.Windows.Threading.ExceptionWrapper.InternalRealCall（代表
   回调，对象的args，的Int32 numArgs）
在MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen（对象
   源，委托方法，对象的args，的Int32 numArgs，代表
   catchHandler）
 

编辑＃1 一些检查后，这里的更多详细信息：

下水是一个2步的过程中，发射器发射的中间 使用Process.WaitForExit窗口（）

从中间窗口，进一步处理可以以相同的方式（Process.WaitForExit）开始。

由于只有中间窗口打开，没有用户交互，对手柄随时间增加发射过程中的号码。我们在这里看到的最大增幅为400 - > 6000手柄。

在编辑中添加的事实，真的让我怀疑是否有可能在该框架中的句柄泄漏的地方。我试图隔离问题，检查是否我可以从头开始重现。在此期间，任何一种暗示，想法，支持甚至巧克力是欣然接受！

编辑＃2 ：在试图使这一进程响应 PostMessage的（），我们去掉了发.WaitForExit 。相反，我们增加了一个处理程序进程的Exited事件和发送的启动到像下面这样的循环：

 而（富==真）
        {
            System.Threading.Thread.Sleep（1000）;
        }
 

已退出处理程序设置富来假的，没有别的。 仍然，柄的数量的增加（400到800在半小时内）。

编辑＃3 这里说到一些有趣的事情，在最后。

 而（富==真）
        {
            System.Threading.Thread.Sleep（1000）;
            所以GC.Collect（）;
        }
 

这使其保持它应该是，几个把手，所有漂亮的方式。现在，让我知道什么是错在这里......我会跟负责开发再回来看看还有什么发射呢。到目前为止，我听说它读取使用 XMLDocument.load方法的几个配置值（ ），这是不是一个的IDisposable - 使其成为一种很难在这里产生任何泄漏...

解决方案

该错误是告诉你，张贴消息到它时，窗口的消息队列达到其最大容量。这意味着，拥有该窗口中的线程不处理邮件足够快的速度，如果在所有。

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

解决方案

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.