Win32Exception 没有足够的存储空间来处理此命令 [英] Win32Exception Not enough storage is available to process this command

问题描述

通过我对 MaxTo 的自动崩溃收集，我得到了以下崩溃报告:

V8.12.0.0 - System.ComponentModel.Win32Exception - :Void UpdateLayered():0版本:MaxTo8.12.0.0异常:System.ComponentModel.Win32Exception错误消息:没有足够的存储空间来处理此命令堆栈跟踪:在 System.Windows.Forms.Form.UpdateLayered()在 System.Windows.Forms.Form.OnHandleCreated(EventArgs e)在 System.Windows.Forms.Control.WmCreate(Message& m)在 System.Windows.Forms.Control.WndProc(Message& m)在 System.Windows.Forms.ScrollableControl.WndProc(Message& m)在 System.Windows.Forms.ContainerControl.WndProc(Message& m)在 System.Windows.Forms.Form.WmCreate(Message& m)在 System.Windows.Forms.Form.WndProc(Message& m)在 MaxTo.MainForm.WndProc(Message& m)在 System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)在 System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)在 System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

另一个堆栈跟踪:

版本:MaxTo2009.9.0.0异常:System.ComponentModel.Win32Exception错误消息:没有足够的存储空间来处理此命令堆栈跟踪:在 System.Windows.Forms.Form.UpdateLayered()在 System.Windows.Forms.Form.OnHandleCreated(EventArgs e)在 System.Windows.Forms.Control.WmCreate(Message& m)在 System.Windows.Forms.Control.WndProc(Message& m)在 System.Windows.Forms.ScrollableControl.WndProc(Message& m)在 System.Windows.Forms.ContainerControl.WndProc(Message& m)在 System.Windows.Forms.Form.WmCreate(Message& m)在 System.Windows.Forms.Form.WndProc(Message& m)在 System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)在 System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)在 System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

在这个最新的堆栈跟踪中，根本没有提到 MaxTo，我遇到的 90% 的崩溃都是与上述类似的堆栈跟踪.

在网上阅读我发现如果您忘记释放或处置变量，此错误很常见.在查看我的 WndProc 时，似乎有时会出现问题，但我找不到一个地方可以挂起对任何对象的引用.除了一个变量之外的所有变量都是 WndProc 的本地变量，因此应该在方法终止时进行垃圾回收.

protected override void WndProc(ref Message m){base.WndProc(ref m);//我假设第一个跟踪可以在这里捕获IntPtr hwnd = m.WParam;//我们的钩子告诉我们某些东西被最大化了if (Win32Import.UWM_MAXIMIZE == (UInt32)m.Msg){//确定我们是暂时禁用还是使用替代配置文件KeyStateInfo keyState = KeyboardInfo.GetKeyState(Settings.AlternativeProfileKey);矩形 r = FindRectangle(MousePosition, (Settings.EnableAlternativeProfile && keyState.IsPressed ? AlternativeRegions : Regions));//我们是否找到了一个矩形来放置它?if (r != Rectangle.Empty){矩形位置 = Win32Import.GetWindowRectangle(hwnd);矩形 previousPos = GetLocation(hwnd);if (position == r && previousPos != Rectangle.Empty){//我们正在恢复原来的位置Win32Import.SetWindowPos(hwnd, IntPtr.Zero, previousPos.X, previousPos.Y, previousPos.Width, previousPos.Height, Win32Import.SWP_NOZORDER | Win32Import.SWP_NOSENDCHANGING);}别的{//我们正在最大化一个区域Win32Import.ShowWindow(hwnd, Win32Import.WindowShowStyle.Restore);Win32Import.SetWindowPos(hwnd, IntPtr.Zero, r.X, r.Y, r.Width, r.Height, Win32Import.SWP_NOZORDER | Win32Import.SWP_NOSENDCHANGING);//确保我们记住这个位置记住位置(hwnd，位置)；}}}否则如果(MaxTo64WindowHandleMessage == m.Msg){//存储我们 64 位子进程的窗口句柄SubProcess64WindowHandle = m.WParam;}}

我无法重现该错误，即使在多天运行该程序时也是如此.

我的假设是系统的未碎片内存或 GDI 句柄不足，但我无法在任何地方确认这一点.似乎没有关于此错误的任何好的文档.

任何想法它可能是什么?我能做些什么来防止这个错误吗?

更新:由于缺乏合适的解决方案，问题以更多堆栈跟踪重新打开.简单地忽略它并不能解决问题.

解决方案

泄漏或使用了许多 GDI 对象/句柄.这些可能会导致资源堆短缺.您可能无法重现，因为您的用户可能正在运行其他 GDI 资源繁重的程序或使用终端服务器，在这种情况下，他们必须与其他用户共享一些堆.请参阅系统错误.代码:8. 没有足够的存储空间来处理此命令

这里你可以阅读用于诊断桌面堆问题的桌面堆监视器工具.

这里 和这里 和此处是 GDI 泄漏检测工具.>

Through my automated crash collection for MaxTo I got the following crash report:

V8.12.0.0 - System.ComponentModel.Win32Exception - :Void UpdateLayered():0
Version: MaxTo8.12.0.0
Exception: System.ComponentModel.Win32Exception
Error message: Not enough storage is available to process this command
Stack trace: 
  at System.Windows.Forms.Form.UpdateLayered()
  at System.Windows.Forms.Form.OnHandleCreated(EventArgs e)
  at System.Windows.Forms.Control.WmCreate(Message& m)
  at System.Windows.Forms.Control.WndProc(Message& m)
  at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
  at System.Windows.Forms.ContainerControl.WndProc(Message& m)
  at System.Windows.Forms.Form.WmCreate(Message& m)
  at System.Windows.Forms.Form.WndProc(Message& m)
  at MaxTo.MainForm.WndProc(Message& m)
  at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
  at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
  at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

Another stacktrace:

Version: MaxTo2009.9.0.0
Exception: System.ComponentModel.Win32Exception
Error message: Not enough storage is available to process this command
Stack trace: 
  at System.Windows.Forms.Form.UpdateLayered()
  at System.Windows.Forms.Form.OnHandleCreated(EventArgs e)
  at System.Windows.Forms.Control.WmCreate(Message& m)
  at System.Windows.Forms.Control.WndProc(Message& m)
  at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
  at System.Windows.Forms.ContainerControl.WndProc(Message& m)
  at System.Windows.Forms.Form.WmCreate(Message& m)
  at System.Windows.Forms.Form.WndProc(Message& m)
  at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
  at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
  at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

In this latest stack trace there is no reference to MaxTo at all, and 90% of the crashes I get are with stack traces similar to the above.

Reading around on the net I find that this error is usual if you forget to release or dispose variables. When looking through my WndProc, which seems to sometimes have the problem pass through, I cannot find a single place that hangs on to references to any objects. All but one of the variables are local to WndProc, and should therefore be garbage collected when the method terminates.

protected override void WndProc(ref Message m)
{
    base.WndProc(ref m); // I'm assuming the first trace can be caught here
    IntPtr hwnd = m.WParam;
    // Our hook tells us something got maximized
    if (Win32Import.UWM_MAXIMIZE == (UInt32)m.Msg)
    {
        // Figure out if we are temporarily disabled or using alternative profiles
        KeyStateInfo keyState = KeyboardInfo.GetKeyState(Settings.AlternativeProfileKey);
        Rectangle r = FindRectangle(MousePosition, (Settings.EnableAlternativeProfile && keyState.IsPressed ? AlternativeRegions : Regions));
        // Did we find a rectangle to place it in?
        if (r != Rectangle.Empty)
        {
            Rectangle position = Win32Import.GetWindowRectangle(hwnd);
            Rectangle previousPos = GetLocation(hwnd);
            if (position == r && previousPos != Rectangle.Empty)
            {
                // We are restoring the original position
                Win32Import.SetWindowPos(hwnd, IntPtr.Zero, previousPos.X, previousPos.Y, previousPos.Width, previousPos.Height, Win32Import.SWP_NOZORDER | Win32Import.SWP_NOSENDCHANGING);
            }
            else
            {
                // We are maximizing to a region
                Win32Import.ShowWindow(hwnd, Win32Import.WindowShowStyle.Restore);
                Win32Import.SetWindowPos(hwnd, IntPtr.Zero, r.X, r.Y, r.Width, r.Height, Win32Import.SWP_NOZORDER | Win32Import.SWP_NOSENDCHANGING);
                // Make sure we remember this location
                RememberLocation(hwnd, position);
            }
        }
    }
    else if (MaxTo64WindowHandleMessage == m.Msg)
    {
        // Store the window handle of our 64-bit subprocess
        SubProcess64WindowHandle = m.WParam;
    }
}

I have not been able to reproduce the error, even while running the program over multiple days.

My assumption is that the system is low on either unfragmented memory or GDI handles, but I cannot confirm this anywhere. There does not seem to be any good documentation on this error.

Any ideas what else it could be? Can I do anything to prevent this error?

Update: The question was reopened with more stack traces, because of the lack of a decent solution. Simply ignoring it does not solve the problem.

解决方案

Leaking or using to many GDI objects/handles. Those could cause a resource heap shortage. You might not be able to reproduce because your users might have other GDI resource heavy programs running or use Terminal Server in which case they have to share some of the heap with the other users. See System Error. Code: 8. Not enough storage is available to process this command

Here you can read about the Desktop Heap Monitor tool to diagnose desktop heap problems.

Here and here and here are GDI leak detection tools.

这篇关于Win32Exception 没有足够的存储空间来处理此命令的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！