We zien deze fout in een Winform-toepassing. Kan iemand helpen waarom u deze fout zou zien, en nog belangrijker, hoe u deze kunt oplossen of voorkomen.
System.ComponentModel.Win32Exception: fout bij het maken van vensterhandle. bij System.Windows.Forms.NativeWindow.CreateHandle (CreateParams cp) bij System.Windows.Forms.Control.CreateHandle() bij System.Windows.Forms.Control.CreateControl (Boolean fIgnoreVisible) bij System.Windows.Forms.Control.CreateControl() bij System.Windows.Forms.Control.OnVisibleChanged(EventArgs e) bij System.Windows.Forms.ButtonBase.OnVisibleChanged(EventArgs e)
Antwoord 1, autoriteit 100%
Heb je Process Explorer of Windows Taakbeheer uitgevoerd om de GDI-objecten, handvatten, threads en USER-objecten te bekijken? Als dat niet het geval is, selecteert u die kolommen die u wilt bekijken (Taakbeheer kiest View->Select Columns… Start vervolgens uw app en bekijk die kolommen voor die app en kijk of een van die kolommen echt groot wordt.
Het kan zijn dat u UI-componenten heeft waarvan u denktdat ze zijn opgeschoond, maar die nog niet zijn verwijderd.
Hier is een linkhierover die nuttig kan zijn.
Veel succes!
Antwoord 2, autoriteit 52%
De limiet voor Windows-handles voor uw toepassing is 10.000 grepen. U krijgt de foutmelding omdat uw programma te veel handvatten maakt. U moet het geheugenlek vinden. Gebruik, zoals andere gebruikers hebben gesuggereerd, een Memory Profiler. Ik gebruik ook de .Net Memory Profiler. Zorg er ook voor dat u de verwijderingsmethode voor besturingselementen aanroept als u ze uit een formulier verwijdert voordathet formulier wordt gesloten (anders worden de besturingselementen niet verwijderd). U moet er ook voor zorgen dat er geen gebeurtenissen zijn geregistreerd bij de besturing. Ik heb zelf hetzelfde probleem, en ondanks wat ik al weet, heb ik nog steeds enkele geheugenlekken die me blijven ontglippen..
Antwoord 3, autoriteit 21%
Zie dit post van mij over “Fout bij het maken van vensterhandle”en hoe dit verband houdt met USER-objecten en de Desktop Heap. Ik bied enkele oplossingen.
Antwoord 4, autoriteit 12%
Dit probleem houdt bijna altijd verband met het aantal GDI-objecten, het aantal gebruikersobjecten of het aantal handle en meestal nietvanwege een onvoldoende geheugen op uw computer.
Als ik een van deze bugs volg, open ik ProcessExplorer en bekijk ik deze kolommen: Handles, Threads, GDI Objects, USER Objects, Private Bytes, Virtual Size en Working Set.
(In mijn ervaring is het probleem meestal een objectlek doordat een gebeurtenishandler het object vasthoudt en voorkomt dat het wordt verwijderd.)
Antwoord 5, autoriteit 4%
Nou, in mijn geval waren het zeker de USER Objects die niet meer onder controle waren. Ik keek in Windows Taakbeheer en ja hoor, het aantal USER Objects was precies 10.000.
Ik sluit dynamisch eigenschappen en lijstbladen in tabbladen in door de bovenliggende eigenschap van het containerpaneel van het eigenschappen- of lijstblad in te stellen op die van de tabbladpagina. Ik ben voorwaardelijk bezig met het recyclen of opnieuw maken van de eigendom en lijstformulieren, afhankelijk van het type collectie dat wordt vermeld of het klassetype van het object dat wordt geïnspecteerd.
NB: In Delphi hadden alle besturingselementen een Owner- en een Parent-eigenschap. Zelfs als men de Parent-eigenschap van een besturingselement zou wijzigen, zou het nog steeds worden verwijderd door de eigenaar wanneer het eigenaarsbesturingselement werd vernietigd.
In C# lijkt het erop dat als een besturingselement b.v. een paneel wordt programmatisch opnieuw toegewezen van bijvoorbeeld een formulier naar een tabbladpagina door de eigenschap Panel.Parent te wijzigen, door Dispose() op het formulier aan te roepen, wordt het paneel niet verwijderd en ook niet door Controls.Clear() op de tabbladpagina aan te roepen. Zelfs een directe oproep Panel.Dispose() zal het niet daadwerkelijk verwijderen, tenzij de bovenliggende ervan vooraf handmatig op null is ingesteld.
Antwoord 6, autoriteit 2%
Ik denk dat het normaal gesproken te maken heeft met het geheugen van de computer dat bijna vol is, dus hij kan geen vensterhandvatten meer maken. Normaal gesproken beginnen Windows op dit punt ook wat vreemd gedrag te vertonen.
Antwoord 7, autoriteit 2%
Ik kreeg dezelfde fout in mijn toepassing. Ik laad veel besturingselementen op één pagina. In een klik op de knop wis ik de besturingselementen. Als u de besturingselementen wist, worden de besturingselementen niet uit het geheugen verwijderd. Verwijder de besturingselementen dus uit het geheugen.
Ik heb zojuist de methode controls.clear() becommentarieerd en enkele regels code toegevoegd om de bedieningselementen te verwijderen.
Zoiets
voor elke ctl als controle in controlcollection
ctl.dispose()
Volgende
Antwoord 8, autoriteit 2%
Ik heb een vinkje toegevoegd waardoor het werkt…
if (_form.Handle.ToInt32() > 0)
{
_form.Invoke(method, args);
}
het is altijd waar, maar het formulier geeft een fout zonder.
Trouwens, mijn handvat is ongeveer 4,9 miljoen
Antwoord 9
Absoluut te veel handvatten (probleem met geheugenlek):
IT Jungles: System.ComponentModel.Win32Exception: Fout bij maken van venstergreep
Antwoord 10
De suggestie voor onvoldoende geheugen lijkt geen slechte aanwijzing.
Wat doet uw programma dat deze foutmelding krijgt?
Maakt het een groot aantal vensters of bedieningselementen?
Creëert het ze programmatisch in tegenstelling tot tijdens het ontwerp?
Zo ja, doe je dit in een lus? Is die lus oneindig?
Verbruikt u op een andere manier duizelingwekkende bootladingen geheugen?
Wat gebeurt er als u het geheugen bekijkt dat door uw toepassing wordt gebruikt in Taakbeheer? Schiet het omhoog naar de maan? Of beter nog, zoals hierboven gesuggereerd, gebruik procesmonitor om in de details te duiken.