A través de mi automatizado de choque de la colección para MaxTo tengo el siguiente informe de accidente:

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)

Otro 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)

En esta última traza de la pila no hay ninguna referencia a MaxTo en todos, y el 90% de los accidentes que me dan son con seguimientos de pila similar a la anterior.

La lectura de todo en la red me encuentro con que este error es de costumbre si usted se olvida de liberación o de disponer de las variables. Cuando se mira a través de mi WndProc, que parece a veces tienen el problema de pasar, no puedo encontrar un solo lugar que se cuelga en las referencias a objetos. Todas menos una de las variables son locales WndProc, y por lo tanto debe ser el recolector de basura cuando el método termina.

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;
}
}

No he sido capaz de reproducir el error, incluso mientras se ejecuta el programa a lo largo de varios días.

Mi suposición es que el sistema está bajo de cualquiera sin fragmentar la memoria o GDI trata, pero no puedo confirmar esto en cualquier lugar. No parece haber ninguna buena documentación sobre este error.

Alguna idea de qué otra cosa podría ser? Puedo hacer algo para evitar este error?

Actualización: La pregunta fue reabierto con más seguimientos de pila, debido a la falta de una solución digna. Simplemente haciendo caso omiso de que no resuelve el problema.

No relacionadas con la pregunta, pero ¿cómo recopilar los informes de fallos?
El uso de Fogbugz BugzScout (Google), y una escrita personalizada global controlador de errores en el programa. No es demasiado difícil.
Es algo reportados en el registro de sucesos de Aplicación de Windows en el momento del error?
No que yo sepa. Todo lo que sé de este error son los seguimientos de pila anterior.
Está tratando de mostrar un no opaca ventana? Quiero decir, una transparente? Tiene a su usuario una vieja tarjeta gráfica (no el apoyo de transparencias y efectos de cristal, cosas como que?).

OriginalEl autor Vegard Larsen | 2009-02-14

4 Comentarios

  1. 12

    Fuga o el uso de muchos objetos GDI/asas. Esto podría causar un montón de recursos de la escasez. Usted podría no ser capaz de reproducir debido a que sus usuarios pueden tener otros recursos GDI pesados programas de funcionamiento o uso de Terminal Server en cuyo caso han de compartir algunos de los del montón con el resto de usuarios. Ver Error Del Sistema. Código: 8. No hay suficiente almacenamiento está disponible para procesar este comando

    Aquí usted puede leer sobre el Montón del Escritorio del Monitor herramienta para diagnosticar escritorio montón de problemas.

    Aquí y aquí y aquí son GDI herramientas de detección de fugas.

    Este debe ser. Estoy asumiendo que este accidente fue causado por otros programas de fugas de GDI trata. Monitoreo mi programa mostró que no hay ninguna fuga de allí.
    Has probado a elevar el montón del escritorio? Mi experiancia es que este error ocurre más a menudo en el Servidor de Terminal server en sistemas donde las partes del montón de escritorio son compartidos entre los usuarios. Esto podría explicar por qué este error happends más a menudo en estos casos.
    El problema es que nunca ha sido reproducible en cualquiera de mis ordenadores, así que no tengo nada de reproducir en. Voy a añadir más a la recopilación de datos para el análisis de bloqueos, pero va a tomar bastante tiempo antes de que yo tenga más detallado de los datos.
    el uso de GDIView, he confirmado que MaxTo mientras se ejecuta, no aumenta el «GDI Total» o «Todos los GDI» a lo largo del tiempo. De hecho, cuando se ejecuta en el fondo no cambia en absoluto. Con todas las ventanas se pueden crear a la vez abierto, el «Todo GDI» contar apenas llegaba a los 200.
    Tal vez usted podría preguntar a los usuarios a aumentar su montón de escritorio y ver si ayuda? O pídale que utilice la herramienta de diagnóstico y enviar a usted los resultados?

    OriginalEl autor Lars Truijens

  2. 5

    Su programa es probablemente fuga de recursos del núcleo. Iniciar el diagnóstico de este problema con Taskmgr.exe. Ver + Seleccionar Columnas, compruebe los objetos de Usuario, los objetos GDI y número de Identificador. Ejecute el programa y observe si alguno de estos está en constante aumento. Una vez que uno de ellos alcanza los 10.000 tu programa va a morir.

    Con una forma rápida de ver la fuga en la acción, usted puede empezar comentando el código para ver donde se produce la pérdida. Es probable que tenga algo que ver con su «gancho».

    OriginalEl autor Hans Passant

  3. 1

    Probablemente el problema dones no miente en su WndProc – la razón por la que usted lo ve en la pila de llamadas es porque casi todo en interfaz gráfica de usuario en Windows ir a través de las WIN32 procedimiento de ventana. Primordial en el control simplemente te da un punto de gancho para proceso de bajo nivel de material antes de nivel superior .NET framework, ya que el procesamiento se realiza.

    Esto va a ser un completa disparo en la oscuridad, pero tal vez este post podría ser relevante? – probablemente no con los seguimientos de pila, aunque.

    No puedo ver cómo sería relevante, como no puedo ver el post vinculados a la producción de este error. Sin embargo, la MaxTo ventana principal tiene paneles anidados, sólo que no en cualquier lugar cerca de tantos como 12-15 niveles de profundidad, a menos que el usuario es realmente extraño con su configuración. 🙂
    los seguimientos de pila, probablemente se vería diferente si era el problema. Es allí cualquier manera de conseguir la plena Win32 seguimientos de pila y no solo el .red de seguimiento?
    No creo que tan fácilmente. Nunca he sido capaz de reproducir en mis propias máquinas. El seguimiento de pila es, simplemente, el objeto de Excepción, no tengo idea de cómo conseguir el Win32 stacktrace (y tendría que proporcionar al usuario con una versión personalizada después de averiguar cómo conseguirlo .NET).

    OriginalEl autor snemarch

  4. 0

    Tenía costumbre de muchos controles de Windows con recursos propios, así que cuando puedo crear muchos de los controles de este error consiste en aparecer. Para solucionar este problema
    Me hizo archivo de Recursos en mi biblioteca y utiliza los recursos del exterior en lugar de recursos en mi código de componente.
    Después de que la excepción se ha ido, ya probado con 3 veces más abrió las formas y este error ha desaparecido.
    Por lo que parece se trata de una solución.

    OriginalEl autor Eugene Bosikov

Dejar respuesta

Please enter your comment!
Please enter your name here