Hi,

ich habe schon einige Einträge zum Thema gefunden. Aber los bin ich mein Problem leider nicht.
Ich habe sporadisch Programmabstürze in der Funktion CopyBitmap (Graphics) in der Zeile:
Result := GDICheck(CreateCompatibleBitmap(ScreenDC, bmWidth, bmHeight)) Da CreateCompatibleBitmap 0 liefert, kommt dann GdiError: EOutOfResources "Für diesen Befehl ist nicht genug Speicher verfügbar" ID 5878...

Der Fehler tritt momentan nur unter Citrix[EDIT]aber auch bei Verbindung über RDP (RemoteDesktop)[/EDIT] / Windows Server 2003 und bei großen Bildschirmauflösungen (z.B. 1980 x 1200) auf.
Trotz des Fehlers kann man einfach weitermachen.

Ich dachte, es liegt an den Developer Express - Komponenten.
Dort wurde so etwas schon diskutiert und man kann die Grafik dort von device-dependent bitmaps auf DIB umstellen.

Ich konnte das gestern nachvollziehen.
Ich habe mei Programm mehrmals gestartet und alle möglichen Fenster geöffnet, bis ich jeweils ca. 1000 GDI - Handles hatte.
Beim Start Nummer 6 kam der Fehler.

Da ich die Umstellung auf DIB per INI einstellen konnte, habe ich es wunderbar reproduziert.
DIB in INI ein - Start OK
DIB in INI aus - Error ... *freu*

Also habe ich auf allen Citrix - Servern die INI angepasst.
Heute - wieder der Fehler ... *heul*

Ich verliere jetzt langsam Haare.

Ich habe schon einige Artikel über GDI - Handels, Einträge in der Registrierung etc. gelesen.
Aber solche Änderungen auf Kundenservern mache ich nicht so gern und es betrifft auch nur die Anzahl der GDI - Handles.
Der Fehler deutet aber mehr auf den GDI - Heap hin.

Deshalb noch einmal die Frage, bevor ich auf den Servern anfange, in der Registry Änderungen vorzunehmen:

Hat jemand das gleiche Problem und idealerweise evtll. sogar eine mögliche Lösung?

Ach ja, nutze Delphi 2007 Pro. Im Anhang ist ein Auszug vom Call Stack.

Danke, Frank

Bei Citrix würde ich sagen: Ich auch die letzte Version mit allen Updates installiert?
Bei allen Fehlern die wir bisher mit Citrix hatten (die sonst nicht auftreten) war es immer einer Fehler in deren Implementierung welche mit Updates verschwunden sind.

Zitat von Bernhard Geyer:

Bei Citrix würde ich sagen: Ich auch die letzte Version mit allen Updates installiert?
Bei allen Fehlern die wir bisher mit Citrix hatten (die sonst nicht auftreten) war es immer einer Fehler in deren Implementierung welche mit Updates verschwunden sind.

Hi,

ok, genau kann ich es nicht sagen. Aber bei deinem Hinweis fällt mir auf, dass ich in #1 die Konstellation falsch beschrienen habe.
Meine Test' s gestern habe ich ja gar nicht unter XenApp, sondern einer normalen RDP - Session (RemoteDesktop) gemacht.

Ich werde es heute Abend mal auf einem Server ohne Citrix testen. Dann kann ich Citrix evtll. schon ausschließen bzw. die Ursache eingrenzen.

Vielen Dank,

Frank

Hi,

ich wollte nur das Ergebnis meiner Test' s bekanntgeben, falls noch jemand das Problem mal hat.
Ich habe meine App auf einem anderen Server installiert (Server 2003 R2 SP2) - kein Citrix.
Hier habe ich meine Anwendung 10 mal gestartet, alle möglichen Formulare mit Grids etc. geöffnet.
Es wurden mehr als 10.000 GDI - Handles im TM angezeigt.

Kein Absturz!

Wieder auf Server mit installiertem Citrix probiert.
Nach 7 mal Start meiner Anwendung

Absturz!

Bei Einstellung auf DIB kann ich lediglich meine App etwas häufiger starten.

Auffälliger Unterschied - in der Reg auf Citrix ist kein Eintrag von SessionPoolSize und SessionViewSize, wobei auf dem Server ohne Citrix
SessionPoolSize auf 4 und SessionViewSize auf 30(48) gesetzt ist.

Nachdem ich dieses gefunden habe,
werde ich am Montag doch bei einen Server mal die Werte setzen und einen neuen Versuch starten.

Frank

Zitat von dataspider:

Hier habe ich meine Anwendung 10 mal gestartet, alle möglichen Formulare mit Grids etc. geöffnet.
Es wurden mehr als 10.000 GDI - Handles im TM angezeigt.

Für alle Instanzen oder pro Instanz?

Zitat von Bernhard Geyer:

Für alle Instanzen oder pro Instanz?

Für alle Instanzen. Pro Instanz schaffe ich wohl nicht. So viele Forms habe ich nicht.
Aber auf ca. 1.300 pro Instanz bin ich gekommen, wobei das nicht üblich sein wird.
In der Regel haben die Anwender nicht mehr als 5 Form' s offen.
Ein Schnitt von bis zu 500 GDI - Handles wird aber schon herauskommen.

Ich hatte ja erwartet, dass es ab 10.000 Handles kracht (irgendwie hatte ich das als magische Grenze gespeichert).
Aber lauf Versuch auf Server 1 scheint das ja kein Problem (mehr?) zu sein.

Frank

Hi,

für alle, die Anwendungen mit DevExpress VCL - Komponenten entwickeln und unter Terminal - Sitzungen auch die Probleme haben.

Ich habe heute einen Server umgestellt.
In der Registrierung habe ich den SessionPoolSize auf 60 (Dezimal) und SessionViewSize auf 120 (Dezimal) gesetzt.
Nach Neustart des Servers sind die Probleme verschwunden.

Die von DevExpress auch vorgeschlagene Umstellung auf DIB:

markieren

Code:

cxGraphics.cxDoubleBufferedBitmapPixelFormat := pf32bit;

geht wohl schonender mit den Resourcen um, hat mein Problem aber nicht lösen können (Der Fehler kommt dann halt etwas später).

Frank

Zitat von dataspider:

Die von DevExpress auch vorgeschlagene Umstellung auf DIB:

markieren

Code:

cxGraphics.cxDoubleBufferedBitmapPixelFormat := pf32bit;

Haben wir bei uns auch. Ist eigentlich eine generelle Empfehlung.

Zitat von dataspider:

geht wohl schonender mit den Resourcen um, hat mein Problem aber nicht lösen können (Der Fehler kommt dann halt etwas

Das ist dann Generell das Problem das die Ressourcen unter Citrx sehr beschränkt sind. Hier bei mir läuft der Windows Explore auch schon mit 600 GDI-Objekten.

Zitat von Bernhard Geyer:

Das ist dann Generell das Problem das die Ressourcen unter Citrx sehr beschränkt sind

Das kann ich so leider auch bestätigen.
Das Schlimme ist, dass sich die Probleme jedesmal anderst äussern: irgendwelche Exceptions, Menuepunkte fehlen, Berichte und Etiketten werden gar nicht oder nur unvollständig gedruckt,...
Die VCL reagiert oftmals sehr undefiniert wenn die Handles ausgehen weil sie nie unter Resourcenmangel entwickelt und gestestet wurde.

Es kann auch sein, dass irgendeine anderer Anwendung in einer anderen Session die Resourcen wegvespert und die Delphianwendung dannn darunter leiden muss.
Und die Kunden sind sauer weil sie glauben die Delphianwendung wäre Schrott.

Bei meinen Tests reagierte z.B. MS Word relativ stabil auf Resourcenmangel (vielleicht hat MS da spezielle Vorkehrungen getroffen) so dass es recht schwierig ist den Kunden zu überzeugen das Citrix die Schuld trägt.