Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Win32/Win64 API (native code) (https://www.delphipraxis.net/17-win32-win64-api-native-code/)
-   -   Delphi Einschränkungen der verfügbaren Ressourcen im Dienste-Konto? (https://www.delphipraxis.net/101334-einschraenkungen-der-verfuegbaren-ressourcen-im-dienste-konto.html)

Bernhard Geyer 11. Okt 2007 16:21


Einschränkungen der verfügbaren Ressourcen im Dienste-Konto?
 
Wir haben eine Anwendung die auch eine Automatisierung-Schnittstelle (COM) besitzt.
Diese läuft auch wunderbar wenn die Anwendung "normal" Automatisiert wird.

Erfolgt die Anwendung jedoch aus einem NT-Dienst heraus, so bekommen wir Windows-Systemfehler
(Systemfehler. Code: 14, Not enough storage is available to complete this operation)

Nach Debug-Sitzung habe ich den Funktionsaufruf "CreateWindowExW" aus den TNTControls ausgemacht. Es scheint für mich so zu sein das die Anzahl der verfügbaren (GDI-)Ressourcen im Dienste-Konto beschränkt ist. Gibt es evtl. ähnliche leidvolle Erfahrungen bzw. Wissen über eine solche Einschränkung?

Bernhard Geyer 10. Jan 2017 11:56

AW: Einschränkungen der verfügbaren Ressourcen im Dienste-Konto?
 
*Ping*

Da wir ein ähnliches Problem (diesmal mit Code 8) haben wäre es gut ob es nach fast 10 Jahren jemand entsprechende Infos hat.

CCRDude 10. Jan 2017 12:15

AW: Einschränkungen der verfügbaren Ressourcen im Dienste-Konto?
 
GDI und Systemdienst? Passt ja schon nicht zusammen, Systemdienste sind doch grafiklos ;)

Ist also zu erwarten. Was man da tricksen kann, weiß ich nicht.
Ggfls. kann der Systemdienst einzelne Threads oder Prozesse im User-Kontext ausführen, ob das machbar ist, hängt stark von der Aufgabe ab.

bra 10. Jan 2017 12:29

AW: Einschränkungen der verfügbaren Ressourcen im Dienste-Konto?
 
Eigentlich sollten Dienste doch gar keine Fenster o.ä. anzeigen. Eventuell hilft hier die Option in den Diensteinstellungen "Datenaustausch zwischen Dienst und Desktop zulassen" zu aktivieren? Dann kommt im schlimmsten Fall am Server aber immer wieder ein Popup, wenn der Dienst versucht irgendwas anzuzeigen. :oops:

Bernhard Geyer 10. Jan 2017 13:32

AW: Einschränkungen der verfügbaren Ressourcen im Dienste-Konto?
 
Es ist eine Anwendung die ähnlich wie Word oder Excel ein GUI hat, aber im Rahmen einer Automatisierung kein Modalen blockierenden Dialoge anzeigt.
Und diese lässt sich unter dem normalen Desktop sehr oft (per COM) starten.
Im Dienst ist nach dem drittten (alle Instanzen laufen) Start schluss und es kommt der Fehler 8.

Es scheint so zu sein das neben der bekannten Grenzen für Ressourcen für einen einzelnen Prozess (AFAIK aktuelle 10.000 GDI-Handles) in einem Dienstekonto noch eine weitere Grenze zu geben welche alle (GDI)-Handles in einem Dienst beschränkt.

nahpets 10. Jan 2017 14:00

AW: Einschränkungen der verfügbaren Ressourcen im Dienste-Konto?
 
Keine Lösung, aber eventuell weiterführende Literatur?

increasing user handle and gdi handle limits

pushing the limits of windows handles

pushing the limits of windows user and gdi objects part 1

Applications may not run correctly in a Terminal Services environment

CCRDude 11. Jan 2017 00:05

AW: Einschränkungen der verfügbaren Ressourcen im Dienste-Konto?
 
In Dienste gehören nunmal keine GUI-Anwendungen ;)

Kann der Dienst sie nicht im User-Kontext starten? Oder fehlen ihm dann Rechte?

Assarbad 11. Jan 2017 10:44

AW: Einschränkungen der verfügbaren Ressourcen im Dienste-Konto?
 
Moin Bernhard, also Fenster sind erstmal natürlich keine GDI-Ressourcen, sondern User-Ressourcen. GDI-Ressourcen sind bspw. Schriftart, Pinsel, Gerätekontext.

Daß seit mindestens Vista Dienste in Sitzung 0 untergebracht sind und damit auch eigene Desktops haben, weißt du sicher. Lokal ("Konsole") angemeldete Benutzer haben ihre Programme in Sitzung 1 laufen und weitere Sitzungen können über RDP erzeugt werden. Ab XP gab es schon erweiterte Einschränkungen (da waren ja TS von Haus aus schon an Bord). Das alles dient der Verhinderung von Shatter-Angriffen (eine Form von Angriffen welche die Rechte von Diensten mit Fenstern auszunutzen versuchten, indem den Fenstern von unprivilegierten Prozessen Befehle übermittelt). Die wichtigste Information fehlt so gesehen: welche Windowsversion benutzt du?

Hab auf meinen Rechner nur eine englische Windowsversion, aber mit Vista wurde der Dienst UI0Detect eingeführt um solche interaktiven Dienste wie du sie beschreibst halbherzig zu unterstützen. Mit folgender Beschreibung:
Zitat:

Enables user notification of user input for interactive services, which enables access to dialogs created by interactive services when they appear. If this service is stopped, notifications of new interactive service dialogs will no longer function and there might not be access to interactive service dialogs. If this service is disabled, both notifications of and access to new interactive service dialogs will no longer function.
Dieser Dienst dient dazu eine Abwärtskompatibilität mit Diensten herzustellen die veraltet sind und deshalb noch immer Fenster im Kontext des Dienstes benutzen. Soweit ich weiß, wird dann auch

Grob gesagt hängt in deinem Fall also die Beschränkung an der Sitzung in welcher Dienste laufen, nicht am jeweiligen Dienstekonto (es gibt ja mehrere mit verschiedenen Einschränkungen bzgl. Netzwerkfähigkeit).

Die korrekte Methode wäre, daß dein Dienst selbst keine Fenster erzeugt, sondern sich ein anderes Programm auf dem Desktop des Benutzers als interaktiver Akteur betätigt, der über COM oder einen beliebigen anderen RPC-Mechanismus mit dem Dienst schnackt um Ausgaben von diesem anzuzeigen bzw. Eingaben entgegenzunehmen und weiterzuleiten.

Es gibt zwar auch Möglichkeiten für einen Dienst Fenster in andere Sitzungen einzuschleusen, aber das wird dann schon ziemlich kompliziert und setzt - zumindest in den mir bekannten Methoden - voraus daß ein Programm in der gewünschten Sitzung/WindowStation/Desktop existiert und dazu mißbraucht werden kann. USBDLM benutzt eine solche Methode, soweit ich das sehen konnte.


Alle Zeitangaben in WEZ +1. Es ist jetzt 23:09 Uhr.

Powered by vBulletin® Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2018 by Daniel R. Wolf