GDI Handles einer Anwendung

[Alex_ITA01]

Hallo zusammen,
ich weiß, wie man die Anzahl der GDI Handles einer Anwendung auslesen kann.
Ich habe allerdings folgende Frage.

Ich benutze dieses Tool zum auslesen und Anzeigen der GDI Handles:
http://www.nirsoft.net/utils/gdi_handles.html

Da gibt es eine Spalte, "GDI Total" und "alle GDIs".
GDI Total ist die Aufsummierung der Spalten vorher (Bitmap, Pen usw).
In der Hilfe steht folgender Abschnitt zu den beiden Spalten:

The 'GDI Total' column (a new column added on v1.05) displays the total number of all GDI handles found in the GDI table for the specified process. This means that 'GDI Total' column display the sum of the following columns: Pen, ExtPen, Brush, Bitmap, Font, Palette, Region, DC, Metafile DC, Enhanced Metafile DC, and Other GDI.
The 'All GDI' value is taken from Windows API call (GetGuiResources), and it usually contains a value larger than 'GDI Total', probably because it also counts some internal kernel GDI objects that are not included in the GDI objects table of the process.

Jetzt meine Frage:
Wenn ich mir zum Beispiel bei dem Programm "VMWare Player" die Spalten angucke (ohne das eine VM gestartet ist), dann steht bei "GDI Total = 61" und bei "alle GDIs = 319".

Entsprechend der Hilfe sind die 61 GDI Handles in der GDI Objekt Tabelle registriert. Die anderen 258 (319-61) sind ja nicht registriert, benutzen aber ein GDI Handle.
Wie bekomme ich heraus, wer diese Ressourcen anfordert bzw wie bekomme ich nähere Informationen zu diesen "anderen" Handles heraus?
Das mit VMWare ist nur ein Beispiel. Es geht natürlich darum, eine eigene Anwendung genauer zu beleuchten aber die Zahlen stimmen zumindest und ich würde gerne wissen, wie sich diese Differenz ergibt.

Viele Grüße

[Alex_ITA01]

Ich nochmal :-)

Ich wollte das Problem mal noch ein bisschen mit Zahlen vertiefen.
Meine Anwendung benötigt laut TaskManager (entspricht bei dem oben genannten Programm der Spalte "Alle GDIs") 7440 GDI Objekte.
Das oben genannte Programm sagt mir in der Spalte "GDI Total" ein Wert von 6083. Das liegt daran, weil da ohne Ende Bitmaps drinne sind. Das weiß ich also woher der Wert kommt. Ob das nun sinnvoll ist oder nicht, spielt hier keine Rolle. Ich möchte nur gerne wissen, was für GDI Objekte noch reserviert werden, da ja anscheind in der GDI Handle Table nur die 6083 registriert wurden aber insgesamt die Anwendung 7440 verbraucht.
Vielleicht könnt ihr da weiterhelfen.

Viele Grüße

Edit:

Oder um es ganz einfach zu beschreiben.

1)
Neues Projekt -> Leere Form, Anwendung starten
GDI Total = 16
Alle GDIs = 39 <- das zeigt auch der TaskManager an

2)
Neues Projekt -> Form mit einem Label und einem Button (keine Eigenschaften der Komponenten geändert), Anwendung starten
GDI Total = 23
Alle GDIs = 44 <- das zeigt auch der TaskManager an

Warum diese Differenz also?

[Whookie]

Also wirklich konkretes kann ich dir dazu auch nicht sagen, aber wenn ich mir die Funktion im MSDN ansehe könnte man auch auf die Idee kommen, dass der höhere Wert einfach nur der Peak-Wert ist...

[Alex_ITA01]

Hallo,
der Peak-Wert wird es nicht sein, da ich bei einem Test festgestellt habe, die Anwendung bei 10000 GDI Handles (Anzeige TaskManager) auch wirklich die Grätsche macht. Das ist auch ein Wert, der entsprechend in der Registry hinterlegt ist aber bis Windows 8 konnte man den Wert in der Registry erhöhen und schon war es kein Problem mehr, mehr als 10000 GDI Handles zu haben. Unter Windows 10 gibt es zwar den Schlüssel in der Registry noch, man kann ihn auch verstellen, aber trotzdem ist bei 10000 Handles Schluss. Keine Ahnung warum der Registry Schlüssel keine Auswirkung mehr hat. Ich möchte ja nur gerne wissen, wer denn so viele Handles belegt/benutzt. Ich habe es absichtlich in meiner Anwendung nicht gemacht ;-)

Viele Grüße

[Alex_ITA01]

push ;-)

Hat keiner eine Idee?

Mich wundert auch, dass die entsprechenden Registry Schlüssel alle im Win10 noch da sind aber anscheind keine Auswirkungen haben.

Ich bin ja nicht der einzige, der das Problem hat.
Siehe hier:

http://exception198.blogspot.de/2015...-limit-in.html

https://social.msdn.microsoft.com/Fo...scompatibility

http://stackoverflow.com/questions/3...-in-windows-10

[Alex_ITA01]

push :-D

[Luckie]

Es gibt auch nicht sichtbare GDI Objekte. Unter "All GDI objects" fallen eventuell auch die nicht sichtbaren, wie Bitmaps, Fonts und DCs usw.

https://msdn.microsoft.com/de-de/lib...=vs.85%29.aspx

[Alex_ITA01]

Leider sind die nicht sichtbaren in der GDI Handle Table registriert und somit auch in der Spalte "GDI Total" enthalten. Der größere Wert steht aber in "Alle GDIs" und das ist auch der Wert, den der TaskManager anzeigt.

Wie macht ihr das denn mit euren Anwendungen?
Wenn ich ein neues Projekt erstelle mit einer Form, mit einem Label und einem Button (keine Eigenschaften der Komponenten geändert) und ich schon 44 GDI Handles belege, dann komme ich bei 10000 GDI Handles auf maximal 227,xxx Forms, die maximal diese beiden Komponenten haben dürfen. Das eine Form nur diese beiden Komponenten beinhaltet, glaube ich allerdings nicht. Deswegen fällt die Anzahl der möglichen Forms auch mit dem Anstieg der Komponentenanzahl.
Was verbrauchen eure "größeren" Anwendungen denn?

Ob es sich lohnt, dass mal in der Quality Central zu beschreiben?

Viele Grüße

[TiGü]

Zitat:

Zitat von Alex_ITA01 (Beitrag 1314137)

Ob es sich lohnt, dass mal in der Quality Central zu beschreiben?

Nein, wozu?
An die Grenze von 10000 stößt man eigentlich nur wenn man etwas "falsch" macht.
Vielleicht ist dein Ansatz einfach verkehrt?

Formuliere mal dein konkretes Problem!

Denn was bringt es, ins QC zu schreiben, dass Windows eine Grenze von 10000 GDI-Handles hat und die das bei Emba bitteschön fixen sollen?

Selbst deine IDE verbraucht relativ wenig und dabei ist das eine große und umfangreiche Software (bspw. XE8 - GDI Total: 1982; All GDI: 2830).

[Whookie]

Ich hab hier mal eine App mit knapp 100 Forms - die eine Art Bildbearbeitung erlaubt - und die Spitzenwerte im GDIView sind 460/650 (bei intensivem Arbeiten) also weit ab von jeglichen Problemen.
Auch das Öffnen und Bearbeiten von ettlichen (10) Grafikdateien mit gemeinsam gut 300 Layern verbraucht gerade mal 350/420 Handles (alle Ebenen sichtbar + Kopien in neuen Bildern).

Grundsätzlich stellt sich also die Frage ob ein so hoher Wert nicht einfach ein Designproblem ist?

Was Delphiprogramme anbelangt mache ich mir da jedenfalls keine Sorgen.

[mm1256]

Zitat:

Zitat von Whookie (Beitrag 1314183)

Grundsätzlich stellt sich also die Frage ob ein so hoher Wert nicht einfach ein Designproblem ist?

So sehe ich das auch und wette mal einen alten Hut gegen einen neuen PC, dass sehr extensiv (wenn überhaupt) von der Möglichkeit Gebrauch gemacht wird, Formulare dynamisch zur Laufzeit zu erzeugen, und wenn sie nicht mehr gebraucht werden wieder freizugeben. Testweise habe ich mit dem og. Tool mal meine größte App geprüft, eine MDI-Anwendung mit insgesamt über 150 Fenstern/Formularen. Wenn ich alle 12 MDI's aufmache und dazu noch einen modalen Dialog mit Bildanzeige (mehr geht nicht) dann komme ich auf ~700 Handles (All GDI).

[Alex_ITA01]

Danke für eure Antworten.
Jetzt kommen wir doch der Sache näher.

Doch, ich habe die meisten Fenster dynamisch gestaltet.

Ich komme ja in der Spalte "GDI Total" auf nur knapp 1000. Aber bei "Alle GDIs" stehen mal eben 5000.
Die Frage ist also immernoch, wo kommt diese Differenz her, da ich ja anscheind keinen Einfluss darauf nehmen kann. Also was für Handles könnten das sein, die sich als GDI Handle ausgeben aber nicht in der GDI Handle Table stehen. Ich bin ja gerne bereit etwas an meinem Design der Anwendung zu ändern aber dafür müsste ich ja erstmal wissen, wo ich anpacken kann.

Viele Grüße

[mm1256]

Hallo,

wenn ich mir auf meinem Arbeits-PC das Verhältnis von "GDI Total" zu "All GDI" ansehe, dann fällt mir positiv der TeamViewer mit 442 zu 483 auf, und negativ der Total-Commander mit 207 zu 429. Da schlagen vermutlich die vielen Bitmaps zu. Wenn ich z.B. die Laufwerkbuttons weg nehme, sind es nur mehr 165 zu 390.

So ähnlich könnte es sich vielleicht bei dir auch verhalten. Abhilfe....vielleicht ImageList verwenden, Fenster vererben...usw. Läuft halt ohne Detailkenntnisse leider nur auf Glaskugel hinaus. Du müsstest also schon etwas mehr Infos/Details benennen.

[Alex_ITA01]

aber in dem Verhältnis 207 zu 429 sind doch in den 207 die Bitmaps mit drinne.
Also egal wie hoch die Anzahl ist, ich würde ja gerne mal wissen, was die anderen Handles für welche sind, da ja Bitmaps zu dem ersten Wert gehören. Die sind für mich auffindbar und anpassbar...

Viele Grüße

[Alex_ITA01]

Noch ein Beispiel:

Leeres Formular mit einem Button hat ungefähr ~40 GDI Handles (Total GDIs) -- Verhältnis 3 / 43.
Beim Button Klick ein zweites Formular dynamisch erzeugen mit einem leeren VirtualStringTree drauf (keine Eigenschaften angepasst). Verhältnis 9 / 140

Also auf einmal 100 GDI Handles mehr (Totale GDIs, nicht die aufsummierten aus Bitmap und Co) nur wegen einem Formular und einem VirtualStringTree.

Ich würde nur zu gerne wissen, was das für Ressourcen sein sollen...

Viele Grüße

[TiGü]

Zitat:

Zitat von Alex_ITA01 (Beitrag 1314232)

Ich würde nur zu gerne wissen, was das für Ressourcen sein sollen...

Was genau hält dich jetzt auf in die Quelltexte des Frameworks zu gucken?

Beispiel:
TCustomForm hat einen TControlCanvas, der wiederrum alle entsprechenden Eigenschaften belegt (Font, Pen, Brush) und die Elternklasse TWinControl hat einen TBrush als Membervariable. Allein schon das erzeugen von derartigen Objekten belegt GDI-Ressourcen.

[TiGü]

Ja, ne...oder? :shock:
http://www.delphipraxis.net/118257-a...i-objekte.html

[Alex_ITA01]

Anscheind ist das Problem noch nicht korrekt beschrieben...

Font, Pen, Brush, Bitmaps, DC usw. sind in der GDI Handle Table registriert und ergeben in Summe den Wert, der in der Spalte "GDI Total" steht. Ich möchte aber gerne die Differenz zu "Alle GDIs" herausfinden und evtl. daran etwas ändern.

Viele Grüße

Es hat nichts mit dem von dir geposteten Link zu tun.
Es geht doch um ein neues, leeres (bis auf paar Standardkomponenten) Projekt.

[TiGü]

Die Hilfe/Beschreibung zu den Programm hast du aber schon gelesen, oder?

Zitat:

Zitat von http://www.nirsoft.net/utils/gdi_handles.html

'GDI Total' and 'All GDI' columns
The 'GDI Total' column (a new column added on v1.05) displays the total number of all GDI handles found in the GDI table for the specified process. This means that 'GDI Total' column display the sum of the following columns: Pen, ExtPen, Brush, Bitmap, Font, Palette, Region, DC, Metafile DC, Enhanced Metafile DC, and Other GDI.
The 'All GDI' value is taken from Windows API call (GetGuiResources), and it usually contains a value larger than 'GDI Total', probably because it also counts some internal kernel GDI objects that are not included in the GDI objects table of the process.

Notice: If you have a problem that the 'All GDI' value is increased, while there is no leak with the other GDI values, it means that you probably have a leak in the creation of icons or cursors (Icons and cursors are created without destroying them later).

[Alex_ITA01]

Sorry aber versteh mich nicht...
Klar habe ich die gelesen und da steht das man anscheind irgendwo Leaks mit Cursors und Icons oder ähnlichem hat.

Aber wie erklärst du mir dann damit das Beispiel mit den 2 Formularen und dem einen VirtualStringTree auf dem zweiten Formular. Ich habe doch gar keine Cursoren, Icons oder ähnliches angepackt. Nicht mal Quelltext habe ich geschrieben außer das Form2 initialisiert und angezeigt wird.

[Whookie]

Also mal kurz experimentell herausgefunden:

1.
Kleines Progamm mit ein paar Buttons, geöffnet 16/44 (hatte auch schon 21/44).
Mit dem Button erstelle ich eine sonst leere Form und zeige sie Modal an: 16/47 (braucht also drei geheime Ressourcen).

Daraus lässt sich ableiten das die Analyse der Handles von seiten GDIView wohl nicht komplett ist, denn so eine Form benötigt bestimmt Ressourcen und die sind wohl auch nicht geheim. Vielmehr denke ich, das Microsoft - die bewusst undokumentierte - GDI-Table umgestaltet/ausgebaut/erweitert/... hat und damit nicht alle Werte angezeigt werden (können).

2.
Weiterer Button zum Erzeugen eines Icons (das braucht so eine Form) und schon geht der Zähler von 16/44 auf 16/45. Daraus folgt: Icons werden schon mal nicht mitgezählt...

Die Jagd auf die anderen beiden Ressourcen sei also hiermit offizell eröffnet :wink:

[Alex_ITA01]

Hi Whookie,
das habe ich auch schon festgestellt, dass nach dem Anwendungsstart der erste Wert kurzzeitig immer höher ist (zwischen 3 und 4 bei mir) und dann geht die Anzahl wieder nach unten und ist dann aber stabil (solange nix gemacht wird -> neues Formular etc.).

Vielleicht bekommen wir ja doch noch raus, was das so für Ressourcen sind ;-)

[TiGü]

Zitat:

Zitat von Alex_ITA01 (Beitrag 1314304)

Sorry aber versteh mich nicht...

Wenn du dich selber nicht verstehst, wie sollen wir es? :gruebel: :mrgreen:

Zitat:

Zitat von Alex_ITA01 (Beitrag 1314304)

Klar habe ich die gelesen und da steht das man anscheind irgendwo Leaks mit Cursors und Icons oder ähnlichem hat.

Okay, das übliche Lesen <> Verstehen.
Ich frage mal ganz konkret: Steigt bei dir denn die Zahl in der Spalte "All GDI" während alle anderen ungefähr konstant bleiben und somit nicht ansteigen?

Zitat:

Zitat von Alex_ITA01 (Beitrag 1314304)

Aber wie erklärst du mir dann damit das Beispiel mit den 2 Formularen und dem einen VirtualStringTree auf dem zweiten Formular. Ich habe doch gar keine Cursoren, Icons oder ähnliches angepackt. Nicht mal Quelltext habe ich geschrieben außer das Form2 initialisiert und angezeigt wird.

Was gibt es da zu erklären?
Der VirtualStringTree ist eine visuelle Komponente, die mithilfe der GDI/Canvas gezeichnet wird.
Das verbraucht GDI-Handles.

[Alex_ITA01]

Zitat:

Zitat von Alex_ITA01:
Sorry aber versteh mich nicht...

Wenn du dich selber nicht verstehst, wie sollen wir es?

Eigentlich sollte das heißen:
Sorry aber versteh mich nicht falsch... Das war eher auf dich bezogen :mrgreen:

Zitat:

Okay, das übliche Lesen <> Verstehen.
Ich frage mal ganz konkret: Steigt bei dir denn die Zahl in der Spalte "All GDI" während alle anderen ungefähr konstant bleiben und somit nicht ansteigen?

Nein da hast du schon Recht. Mir ging es ja lediglich darum zu verstehen, welche Handles in der Spalte "Alle GDIs" enthalten sind, die bei der Spalte "GDI Total" fehlen.

Zitat:

Was gibt es da zu erklären?
Der VirtualStringTree ist eine visuelle Komponente, die mithilfe der GDI/Canvas gezeichnet wird.
Das verbraucht GDI-Handles.

Das der VST eine visuelle Komponente ist weiß ich aber 100 GDI Handles für einen VST? Find ich irgendwie viel oder nicht?

Es wurde in früheren Beiträgen geschrieben, dass ihr bei euren größten Anwendungen auf max 750 GDI Handles kommt. Das heißt ja, dass ich eine Anwendung mit ein paar Fenstern und ein paar VSTs mal ganz locker auf die 750 Handles bringen kann. Und dann habe ich noch keinen Source dahinter, der irgendwas sinnvolles macht.

[TiGü]

Zitat:

Zitat von Alex_ITA01 (Beitrag 1314388)

Das der VST eine visuelle Komponente ist weiß ich aber 100 GDI Handles für einen VST? Find ich irgendwie viel oder nicht?

Es wurde in früheren Beiträgen geschrieben, dass ihr bei euren größten Anwendungen auf max 750 GDI Handles kommt. Das heißt ja, dass ich eine Anwendung mit ein paar Fenstern und ein paar VSTs mal ganz locker auf die 750 Handles bringen kann. Und dann habe ich noch keinen Source dahinter, der irgendwas sinnvolles macht.

Probiere das doch mal aus.
Nach deiner Rechnung müsstest du ja nur sieben bis acht Formulare mit den VST erstellen und anzeigen lassen.
Wächst das alles linear?

[Alex_ITA01]

Jup habe ich gemacht.
Ist nicht linear aber sind genau 50 Fenster mit jeweils einem VST drinne. Dann sind die 700 GDIs erreicht...

[TiGü]

Na dann ist doch jetzt alles soweit in Butter, oder?

[Alex_ITA01]

Prinzipiell schon aber dennoch würde ich gerne die Handles ermitteln, die zwischen den beiden Werten sich "verstecken". Mir geht es doch nicht um irgendwelche max Anzahlen von Komponenten oder Fenstern oder sonstwas. Ich will wissen was da noch GDI Handles benutzt.

[TiGü]

Solange du nicht den Windows-Quelltext vorzuliegen hast, kannst du da anscheinend nicht ran.

Grund:

Zitat:

The 'All GDI' value is taken from Windows API call (GetGuiResources), and it usually contains a value larger than 'GDI Total', probably because it also counts some internal kernel GDI objects that are not included in the GDI objects table of the process.