Problème Winforms - Erreur lors de la création du descripteur de fenêtre
Nous voyons cette erreur dans une application Winform. Quelqu'un peut-il nous expliquer pourquoi vous voyez cette erreur et, surtout, comment la corriger ou éviter qu'elle ne se produise.
System.ComponentModel.Win32Exception: erreur lors de la création du descripteur de fenêtre. Sur System.Windows.Forms.NativeWindow.CreateHandle (CreateParams cp) Sur System.Windows.Forms.Control.CreateHandle () sur System.Windows.Forms.Control.CreateControl (Boolean fIgnoreVisible) sur System.Windows.Forms.Control.CreateControl () sur System.Windows.Forms. Control.OnVisibleChanged (EventArgs e) Sur System.Windows.Forms.ButtonBase.OnVisibleChanged (EventArgs e)
Avez-vous exécuté Process Explorer ou le Gestionnaire des tâches de Windows pour consulter les objets GDI Objets, poignées, threads et USER? Sinon, sélectionnez les colonnes à afficher (Gestionnaire des tâches choisissez Affichage-> Sélectionner Colonnes ... Ensuite, exécutez votre application et jetez un œil à ces colonnes pour cette application et voyez si l'une d'entre elles s'agrandit vraiment.
Il se peut que vous ayez des composants d'interface utilisateur que vous pensez sont nettoyés mais qui n'ont pas été éliminés.
Voici un lien à ce sujet qui pourrait être utile.
Bonne chance!
La limite de descripteurs Windows pour votre application est de 10 000 descripteurs. Vous obtenez l'erreur car votre programme crée trop de descripteurs. Vous devrez trouver la fuite de mémoire. Comme d'autres utilisateurs l'ont suggéré, utilisez un profileur de mémoire. J'utilise également le .Net Memory Profiler. Assurez-vous également d'appeler la méthode dispose sur les contrôles si vous les supprimez d'un formulaire avant le formulaire se ferme (sinon les contrôles ne seront pas supprimés). Vous devrez également vous assurer qu'aucun événement n'est enregistré avec le contrôle. J'ai moi-même le même problème, et malgré ce que je sais déjà, j'ai encore quelques fuites de mémoire qui continuent de m'échapper ..
Voir mon article sur "Erreur lors de la création du descripteur de fenêtre" et comment il se rapporte aux objets UTILISATEUR et au tas de bureau. J'apporte quelques solutions.
Ce problème est presque toujours lié au GDI nombre d'objets, nombre d'objets utilisateur ou nombre de poignées et généralement pas en raison d'une condition de mémoire insuffisante sur votre machine.
Lorsque je suis en train de suivre l'un de ces bogues, j'ouvre ProcessExplorer et regarde ces colonnes: Handles, Threads, GDI Objects, USER Objects, Private Bytes, Virtual Size et Working Set).
(D'après mon expérience, le problème est généralement une fuite d'objet due à un gestionnaire d'événements tenant l'objet et l'empêchant d'être éliminé.)
Eh bien, dans mon cas, c'était définitivement les objets USER qui étaient hors de contrôle. J'ai regardé dans le Gestionnaire des tâches de Windows et bien sûr, le nombre d'objets USER était exactement à 10 000.
J'incorpore dynamiquement des feuilles de propriétés et de listes dans les pages à onglets en définissant la propriété Parent du panneau conteneur de la feuille de propriétés ou de listes sur celle de la page à onglets. Je reconditionne ou recrée sous condition les formulaires de feuille de propriété et de liste en fonction du type de collection répertorié ou du type de classe de l'objet inspecté.
NB: Dans Delphi, tous les contrôles avaient un propriétaire et une propriété parent. Même si l'on modifiait la propriété Parent d'un contrôle, il serait quand même détruit par son propriétaire lorsque le contrôle propriétaire serait détruit.
En C #, il semble que si un contrôle par ex. un panneau est réassigné par programme à partir, par exemple, d'un formulaire vers une page à onglet en modifiant la propriété Panel.Parent, l'appel de Dispose () sur le formulaire ne supprimera pas le panneau, pas plus que l'appel de Controls.Clear () sur la page à onglet. Même un appel direct Panel.Dispose () ne le supprimera pas réellement, à moins que son parent ne soit préalablement défini manuellement sur null.
J'ai ajouté un chèque qui le fait fonctionner ...
if (_form.Handle.ToInt32() > 0)
{
_form.Invoke(method, args);
}
c'est toujours vrai, mais le formulaire renvoie une erreur sans lui. BTW, ma poignée est d'environ 4,9 millions
Je pense que c'est normalement lié à la panne de mémoire de l'ordinateur, il n'est donc pas en mesure de créer plus de poignées de fenêtre. Normalement, Windows commence également à montrer un comportement étrange à ce stade.
Certainement trop de poignées (problème de fuite de mémoire):
J'ai obtenu la même erreur dans mon application.Je charge de nombreux contrôles sur une seule page.Dans l'événement de clic sur le bouton, j'efface les contrôles.L'effacement des contrôles ne libère pas les contrôles de la mémoire.Pour éliminer les contrôles de la mémoire. Je viens de commenter la méthode controls.clear () et d'inclure quelques lignes de code pour éliminer les contrôles. Quelque chose comme ça
pour chaque ctl comme contrôle dans controlcollection
ctl.dispose ()
Prochain