Einschränkungen der verfügbaren Ressourcen im Dienste-Konto?

[Bernhard Geyer]

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]

*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]

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]

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]

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]

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]

In Dienste gehören nunmal keine GUI-Anwendungen ;)

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

[Assarbad]

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.