Einleitung
Technische Vorgaben durch das Betriebssystem sind die Ursache, warum Überbelegungen von Desktops in VCS vermieden werden müssen.
Da dies immer wieder angefragt wird, soll dieser Artikel erläutern, wie es dazu kommen kann und Lösungen bzw. Hilfestellungen anbieten.
Im Folgenden werden Begriffe und Vorgaben erläutert, die wichtig sind, um die Zusammenhänge zu verstehen.
Begriffe
Diese Begriffe und Abkürzungen werden in diesem Artikel verwendet:
| Begriff | Erläuterung |
| GDI |
Graphics Device Interface, Grafikgeräte-Schnittstelle |
| GDI-Objekt | GDI-Objekte unterstützen nur ein Handle pro Objekt. Nur der Prozess, der das GDI-Objekt erstellt hat, kann das Objekthandle verwenden. |
| Benutzer-Objekt | Ein Benutzerobjekt im GDI-/Windows-Kontext ist ein von der User-Komponente (user32.dll) verwaltetes UI-bezogenes Objekt wie Fenster oder Menüs, während ein GDI-Handle auf ein GDI-Objekt verweist, das mit Zeichenvorgängen zu tun hat. |
| Handle | Ein “Handle” für ein Objekt; Handles beziehen sich auf eine Ressource, die in den Arbeitsspeicher geladen wurde. |
| HWND | Ein Handle für ein Fenster. Ein HWND ist ein Handle, aber nicht alle Handles sind HWND. |
Die Definitionen sind verschiedenen Webseiten von Microsoft Learn entnommen, u. a. “Microsoft Learn: Windows-Datentypen” und “Microsoft Learn: GDI-Objekte”.
Was sind GDI-Objekte?
Jeder Entwicklung steht ein “Handle” für Steuerelemente zur Verfügung, um mit Objekten arbeiten zu können, analog dazu existiert ein entsprechender Handle (HWND) unter Windows. Für jedes Windows-Handle wird ein sogenanntes Benutzer-Objekt erzeugt. Bei der Verwendung von Grafikobjekten (wie Fonts oder Bitmaps) allokiert eine Applikation unter Windows GDI-Objekte.
Vorgaben durch das Betriebssystem
Die Anzahl der GDI-Objekte, die eine Applikation verwenden kann, ist eine vom Betriebsystem fest vorgegebene Größe und unabhängig vom verfügbaren Hauptspeicher.
Jeder Prozess unter Windows kann standardmäßig maximal 10.000 Benutzer- und 10.000 GDI-Objekte allokieren (ab Windows 10).
Das hört sich auf den ersten Blick ausreichend an, kann aber in der Praxis durchaus erreicht werden. Bei Anwendungen, z. B. Auftragsliste, die dem Benutzer zum Beispiel über viele Seiten Informationen zur Verfügung stellen, kann die Anzahl der Objekte eines Fensters unter Umständen zwei bis dreitausend betragen. Bei mehreren gleichzeitig geöffneten Frames wird dann das Limit unvermeidlich erreicht (ErrOutOfMemory).
Standardlimit pro Prozess für GDI-Objekte
Es gibt ein Standardlimit pro Prozess für GDI-Objekte. Laut Microsoft und anderen Quellen ist es möglich, einen Registry Schlüssel zu erstellen
- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\GDIProcessHandleQuota
- HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\GDIUserProcessHandle
und bis auf einen maximalen theoretischen Wert von 65.536 zu setzen (unter den 64bit Systemen im Unterschlüssel WOW6432Node).
Doch mit diesem Wert muss eine Anwendung auch umgehen können.
Hintergrundinfos zum Standardlimit
- Die Erhöhung auf einen Wert jenseits der 10.000 war noch möglich für Systeme bis inkl. Windows 7.
- Seit Windows 10 wird ein Default-Wert von 10.000 GDI-Objekten nicht mehr überschritten.
Es sind auch keine Planungen / Lösungen seitens Microsoft bekannt, um dieses Limit aufzuheben.
Der Grund für die Einführung dieses Limits ist seitens Microsoft nie publiziert worden.
Da es jedoch eine stetig steigende Anzahl an Anwendungen auf den Systemen gibt, ist die Vermutung plausibel, dass ein solches Limit eine “Chancengleichheit” für alle Applikationen herstellen soll.
Mächtige grafische Anwendung wie VCS, die Jahrzehnte gewachsen sind, werden hier nicht anders behandelt als kleine Freeware Lösungen.
Was bis Windows 7 noch funktionierte, erforderte ab Windows 10 / 11 also eine Umstellung innerhalb der Anwendung selbst, z. B. durch Entfernen und Auslagern von Funktionen.
- Für VCS wurde dieser Lösungsweg wo möglich auch gegangen, wie z. B. im Bildercontroll, Übernahmeassistenten, Mailclient, uvm..
Hier werden weitere Prozesse geöffnet, die mit einer Belegung von GDI-Objekten den Hauptprozess nicht weiter belasten.
Diese Vorgehensweise ist das jedoch nicht durchgängig möglich.
Allein eine Auftragsmaske, die Adressenverwaltung, Ersatzteilliste oder auch Dienstleistungen sind so umfangreich in den Funktionen, dass hier nur Neuentwicklungen ein Lösungsansatz sind.
Ursache der Darstellungsfehler bzw. des Absturzes
Die Ursache liegt darin, dass der Benutzer mehr GDI-Objekte öffnen möchte, als das Betriebssystem für die Prozesse in VCS zur Verfügung stellt.
Das Betriebssystem reagiert jedoch nicht mit einem Hinweis oder einer Warnung, sondern mit Darstellungsfehlern oder einem Absturz.
Reaktion des Betriebssystems
Wird die maximale Anzahl von GDI-Objekten überschritten, kommt es zu Darstellungsfehlern oder auch Abstürzen des Programms.
Wichtig: Bei Erreichen der maximalen Anzahl der GDI-Objekte gibt das Betriebssystem Windows keine Warnmeldung aus.
I.d.R. macht sich das Problem durch weiße Bereiche mit fehlenden Oberflächenelementen bemerkbar. Es können dann keine weiteren Oberflächenelemente, wie Felder, Comboboxen oder Menüs dargestellt werden. I.d.R. macht sich das Problem durch weiße Bereiche mit fehlenden Oberflächenelementen bemerkbar.
Reaktion der Anwendung VCS
Damit es in VCS dazu nicht kommt, findet vor dem Laden eines Fensters eine Überprüfung der Windows-Ressourcen statt.
Ab VCS Version 2.30.68
In VCS wird ab der Version 2.30.68 eine Hinweismeldung ausgegeben:
Achtung, es können keine weiteren Masken mehr geöffnet werden!
Schließen Sie bitte Fenster in den anderen Desktops, um diesen Prozess fortsetzen zu können.
Die im Kopf genannte Zahl, im Beispiel (8290) gibt die Anzahl der bereits geöffneten GDI-Objekte an.
Der Anwender muss die Meldung mit “OK” bestätigen und kann im Anschluss in den Desktops Fenster schließen, um wieder ausreichend Speicherplatz für GDI-Objekte zu erhalten.
Seit Jahren setzen wir deshalb konsequent auf Neuentwicklungen via Browser-Technologie. Diese bieten neue Features, erben aber auch nach und nach bestehende Funktionen - eine Verschmelzung der Anwendungen ermöglicht dabei einen möglichst fließenden Übergang der Technologien.
Somit können Sie schon heute in vielen Bereichen auf Browser gestützte Lösungen ausweichen und können dadurch GDI-Ressourcen im VCS-Prozess “einsparen”.
Lösung für VCS selbst
Ein regelmäßiger Neustart des Prozess, wie im Kapitel “Warum funktioniert es je nach Umgebung besser oder weniger gut?” erläutert wird.
Bis VCS Version 2.30.65
Bis zur Version 2.30.65 wurde hier ein Fehler in der udaDATALIST2004 ActiveX erzeugt, mit dem Nebeneffekt, dass der Anwender diesen nicht auflösen und Desktops räumen konnte. Die Anwendung musste beendet werden
Reaktion des Benutzers
Optional: Die aktuelle Anzahl an GDI-Objekten prüfen
Die Anzahl der Handles und GDI-Objekte können im Task-Manager angezeigt werden. Je Prozess wird damit die aktuelle Anzahl an GDI-Handles dargestellt.
Den Task-Manager öffnen und zu “Details” wechseln. Standardmäßig sind die Spalten “Handles” und "GDI-Objekte" nicht eingeblendet.
(1) In der Kopfzeile können Sie mit der rechten Maustaste ein Kontextmenü öffnen. Klicken Sie auf “Spalten auswählen”.
(2) Im Auswahlfenster aktivieren Sie die Checkboxen der beiden Spalten “Handles” und “GDI-Objekte”. Mit dem Mauszeiger können Sie die Spalten verschieben.
(3) Markieren Sie den Task “vcs.exe”. Im Beispielscreenshot sind für diesen Prozess 2.240 Handles sowie 8.291 GDI-Objekte aktiv.
Durch Öffnen und Schließen von Ansichten in VCS können Sie die Änderung bei den aktiven Handles und GDI-Objekten verfolgen.
Warum funktioniert es je nach Umgebung besser oder weniger gut?
Technisch gesehen wird vom Betriebssystem immer die gleiche Anzahl an GDI-Objekten bei Aufruf einer gleichen Maske gerufen, somit auch die identische Anzahl an Handles belegt. “Rechner A” benötigt also für die Adressmaske genau so viele Ressourcen wie ”Rechner B”.
Szenario: “Rechner A” wird zur Mittagspause oder am Feierabend heruntergefahren; "Rechner B” wird nur in den Ruhezustand geschickt oder im Falle eines Terminalservers wird nur die Verbindung getrennt.
Dies bedeutet im Fall von “Rechner A”, dass alle Prozesse, auch Hintergrundprozesse, geschlossen werden. Bei “Rechner B” jedoch bleiben die Hintergrundprozesse geöffnet, das System hält die bereits reservierten GDI-Objekte weiter bereit. Dies führt dazu, dass beim Weiterarbeiten nach der Mittagspause oder dem Feierabend “Rechner B” gefühlt früher in ein Limit läuft, als ”Rechner A”, bei dem die Prozesse immer wieder bei 0 beginnen.
Unsere Entwicklung nutzt zwar in VCS Techniken, die das Betriebssystem anweisen, Objekte wieder frei zu geben, wenn z. B. die Adressliste geschlossen wird - das funktioniert leider nicht immer gleich gut. Zumeist bleiben selbst dann noch einige wenige 100 Handles / GDI-Objekte mehr belegt als vor der Aktion.
Letztendlich zuverlässig geräumt werden die Handles also nur durch einen Neustart des VCS Anwendung, das lässt sich meist in den Arbeitsalltag auch gut integrieren, z. B. in einer Kaffee- oder Raucherpause, zum Mittag und Abend - so sollten Sie den ganzen Arbeitstag über nicht in die Situation gelangen VCS in einem ungünstigen Zeitpunkt beenden zu müssen.
Ist das Speichern noch möglich?
Sollten Sie jemals in die Situation kommen, dass die Anzahl an Handles / GDI-Objekten nicht ausreicht, ist die Arbeit dennoch nicht verloren. Es gehen zu keinem Zeitpunkt Daten verloren, da ein Speichern immer möglich ist.
Nur neue Masken lassen sich nicht öffnen, werden diese aber benötigt, um z. B. noch eine Kontakteintrag anzulegen, versuchen Sie andere Desktops zu räumen, oftmals lassen sich dann Vorgänge noch zu Ende bringen.