FindWindow in einem Service unter Vista

[Shark99]

Hi.

Hier ist mein Code:

Delphi-Quellcode:

procedure SendMessageToWindow(msg: LongWord;value:longword=0);
var Wnd: THandle;
begin
  Wnd := FindWindow('myClass', NIL);
  if Wnd > 0 then
  begin
       if IsWindowResponding(Wnd,100) then
          SendMessage( HWND_BROADCAST,
               RegisterWindowMessage('myAppMessage'),
               msg,
               value )
       else
           Error('hung!!');
  end;
end;

Es funktioniert in einer normalen Application (sowohl vista als auch xp).
Es funktioniert in einem Service unter XP.
Es funktioniert NICHT in einem Service unter Vista. Wnd ist da immer 0.

Anscheinend funktioniert FindWindow in einem Service unter Vista nicht mehr.

Gibt es eine andere Möglichkeit Nachchrichten an ein Fenster zu schicken? (damit es z.B. in den Vordergrund kommt).

Danke im Voraus!

[jaenicke]

Interaktive Dienste gibt es unter Vista aus Sicherheitsgründen nicht mehr, und auch bei XP musste man das ggf. erlauben.

[Shark99]

Der Dienst ist nicht als Interaktiv gekennzeichnet! (funktioniert also unter XP mit ausgeschalteter Interaktivität).

[hoika]

Hallo,

Ursache und mögliche Lösungen hier.

FindWindow Service Vista


Heiko

[Luckie]

Zitat:

Zitat von Shark99

Der Dienst ist nicht als Interaktiv gekennzeichnet!

Und genau da sist das Problem. Ein Service läuft in einer anderen WindowsStation als der Desktop des angemeldeten Benutzers und hat somit keinen Zugriff auf den Desktop des angemeldeten Benutzers. Überlicherweise löst man das so, dass man eine normale Anwendung hat, die mit dem Dienst über IPC kommuniziert.

[Shark99]

Luckie, wieso funktioniert es dann unter XP? Ist es nur Zufall dass es dort in der gleichen WS ist?

[Luckie]

Das kann unter XP nur mit einem interaktiven Service funktionieren.

[hoika]

Hallo,

unter welchem Account läuft denn der Dienst unter XP ?
Vielleicht ist bei dem benutzten Account interaktiv automatisch "freigeschaltet".


Heiko

[Shark99]

Gibt es keinen Workaround um eine Nachricht aus dem Service zu der App zu schicken? In die andere Richtung geht es ja, über den ServiceManager.

[wicht]

Ich habe das über ein MemoryMapped-File und ein Event/Mutex/whatever gebaut. Ist relativ einfach und funktioniert gut, Source kann ich leider keinen posten, da nicht zuhause :)

HTH

[Shark99]

Poste bitte den Code, wenn du wieder zu Hause bist.

[Fridolin Walther]

Die Lösung für Dein Problem:
Benutz einen anderen IPC Mechanismus. Mit Window Messages rumspielen in nem Service ist nicht nur relativ dämlich (weil Du auf Deine eigene Terminal Session begrenzt bist) sondern kann durchaus auch die ein oder andere Gefahr in sich bergen. Sollte Dein Service übrigens ein Window erzeugen um Window Messages zu empfangen, darf ich Dir an dieser Stelle sogar zu Deinem ersten exploitbaren Sicherheitsproblem gratulieren ;).

Das Problem wieso Dein FindWindow innerhalb eines Service unter Vista nicht funktioniert, ist recht einfach. Anders als bei XP rennen Services unter Vista in einer eigenen Terminal Service Session. Da alle Fenster und Fenster Handles nur für die jeweilige Session gelten in der sie auch erstellt wurden, findet Dein Service (der in Session 0 läuft) keinerlei Fenster von Applikationen die Du als Nutzer gestartet hast (welche nämlich in Session 1 laufen). Selbst wenn du übrigens ein Fenster Handle bekommen solltest, wäre es unmöglich von Session 0 heraus eine Message an Session 1 zu schicken.

Ich persönlich würde Dir zur Kommunikation Named Pipes empfehlen, da Du Dir um die Synchronisation weit weniger Gedanken machen muss als z.B. bei Memory Mapped Files. Entsprechende Beispiele findest Du hier im Board zu genüge.

Solltest Du mehr über die Hintergründe der Änderung wissen möchten, empfehle ich Google mit "vista session 0 isolation" und "shatter attacks" als Suchbegriffe.

[Tyrael Y.]

Da springe ich doch mal schnell in den Thread rein und schreibe
"ich bin wie immer in diesem Fall für TCP/IP, funktioniert immer und wird auch immer funktionieren"


...mal gucken in wie vielen anderen Threads, die das Thema "Window Messages /Services /Vista" behandeln ich noch diesen Satz schreiben werde...ich sollte mir einen Counter dafür anlegen :mrgreen:

[nicodex]

Zitat:

Zitat von Tyrael Y.

"ich bin wie immer in diesem Fall für TCP/IP, funktioniert immer und wird auch immer funktionieren"

"Immer" ist relativ. Named Pipes habe auch den Vorteil, dass sie einen Sicherheitskontext mitbringen.

[Bernhard Geyer]

Zitat:

Zitat von Tyrael Y.

"ich bin wie immer in diesem Fall für TCP/IP, funktioniert immer und wird auch immer funktionieren"

Immer na ja: Wenn der Listener beim öffnen des TCP/IP-Port nur lokale verbindungen zu lässst dürften 99,9% der Firewalls still halten. Ansonsten gibt es genügend Firewalls die das (teilweise ohne Meldung) die Port-Öffnung blocken.

[Tyrael Y.]

Zitat:

Zitat von nicodex

"Immer" ist relativ. Named Pipes habe auch den Vorteil, dass sie einen Sicherheitskontext mitbringen.

Wir reden hier über Interprozesskommunikation in diesem Fall wird TCP/IP immer funktionieren.
Wer weiss wie lange Named Pipes noch funktionieren werden. Da kann Microsoft auf die Idee kommen die nicht mehr zu unterstützen. Wie könnten sie aber auf die Idee kommen TCP/IP nicht mehr zu unterstützen?

[nicodex]

Zitat:

Zitat von Tyrael Y.

Wer weiss wie lange Named Pipes noch funktionieren werden. Da kann Microsoft auf die Idee kommen die nicht mehr zu unterstützen. Wie könnten sie aber auf die Idee kommen TCP/IP nicht mehr zu unterstützen?

Sie könnten auch auf die Idee kommen, TCP/IP abzuschaffen.
Bei Named Pipes hast du als Entwickler den Vorteil, dass es der Implementation überlassen bleibt, welches Transportprotokoll verwendet wird (und "Lokales RPC" dürfte schneller sein, als deine TCP/IP-Verbindung).
Wie Bernhard Geyer bereits schrieb, ist eher die Praxis das Problem (Software-Firewalls).

[Tyrael Y.]

Zitat:

Zitat von nicodex

Wie Bernhard Geyer bereits schrieb, ist eher die Praxis das Problem (Software-Firewalls).

Seit wann blockt man eingehende Verbindungen von 127.0.0.1 (localhost) oO?

[nicodex]

Zitat:

Zitat von Tyrael Y.

Seit wann blockt man eingehende Verbindungen von 127.0.0.1 (localhost) oO?

Das musst du unsere Kunden fragen ;)

[Luckie]

Zitat:

Zitat von Tyrael Y.

Wer weiss wie lange Named Pipes noch funktionieren werden. Da kann Microsoft auf die Idee kommen die nicht mehr zu unterstützen.

Also wenn du so anfängst zu argumentieren, dann solltest du besser keine Programme für Windows mehr schreiben. ;)

[Tyrael Y.]

Zitat:

Zitat von Luckie

Zitat:

Zitat von Tyrael Y.

Wer weiss wie lange Named Pipes noch funktionieren werden. Da kann Microsoft auf die Idee kommen die nicht mehr zu unterstützen.

Also wenn du so anfängst zu argumentieren, dann solltest du besser keine Programme für Windows mehr schreiben. ;)

...und was ist wenn ich das selbe vor wenigen Jahren geschrieben hätte in Bezug auf WindowMessages :mrgreen:

Zitat:

Zitat von Tyrael Y. am 05.05.2003

Wer weiss wie lange WindowMessages noch funktionieren werden. Da kann Microsoft auf die Idee kommen die nicht mehr immer und überall zu unterstützen.

[nicodex]

Fensternachrichten (bzw. Fensterhandles) bezogen sich schon immer auf einen Desktop. Wenn der Dienst nicht auf dem gleichen/interaktiven Desktop läuft, dann hatte man schon vorher das Problem (Windows Terminal Server mit mehreren Benutzern).

[Bernhard Geyer]

Zitat:

Zitat von Tyrael Y.

Seit wann blockt man eingehende Verbindungen von 127.0.0.1 (localhost) oO?

SW wird auch nur von Menschen geschrieben und wenn diese Denken das man sowas auch blocken müsste ...
Es muss nicht alles immer logisch sein was in SW realisiert wurde.

[Tyrael Y.]

Ich weiss nicodex.
Ich kenn den Zusammenhang. Wir hatten auch Dienste die über nicht sichtbare Fenster im Dienst mit anderen Applikationen über Fensternachrichten (WM_COPYDATA) kommuniziert haben.

Diese Programme und Dienste waren nicht für Terminals konzipiert.
Bei unseren Kunden lief alles super.

...dann kam Vista...und wir standen vor der Entscheidung, was nun?
...wir haben für die IPC TCP/IP gewählt, weil wir vermuten, daß das im Rahmen des IPC lange funktionsfähig bleiben wird.

Wir haben angenommen, daß es wahrscheinlich länger funktionieren dürfte als andere IPC Verfahren, die u.U. irgendwann in einer in Zukunft liegenden Windowsversion nicht mehr läuft.

Ist halt eine Entscheidung, die jeder für sich treffen muss. Keine Frage Named Pipes funktionieren wunderbar.
Ich bevorzuge aber immer noch TCP/IP.

[Dezipaitor]

Das funkz schon nicht mehr in XP, weil dort FUS und RDP mit TS realisiert wurde.

[Fridolin Walther]

Zitat:

Zitat von Tyrael Y.

Ich weiss nicodex.
Ich kenn den Zusammenhang. Wir hatten auch Dienste die über nicht sichtbare Fenster im Dienst mit anderen Applikationen über Fensternachrichten (WM_COPYDATA) kommuniziert haben.

Autsch. Ich hoffe solche Installationen finden sich nicht mehr. Ansonsten wäre jetzt der Zeitpunkt die Bestandskunden auf ein Sicherheitsproblem innerhalb eurer Software aufmerksam zu machen.

Zitat:

Zitat von Tyrael Y.

...dann kam Vista...und wir standen vor der Entscheidung, was nun?
...wir haben für die IPC TCP/IP gewählt, weil wir vermuten, daß das im Rahmen des IPC lange funktionsfähig bleiben wird.

TCP/IP hat mehrere Probleme - nicht nur Firewalls. TCP/IP hat auch einen gigantischen Overhead. Wenn Du also wirklich viele Daten möglichst schnell von einen Prozess in den anderen schaffen willst, dann ist TCP/IP denkbar ungeeignet.

Zitat:

Zitat von Tyrael Y.

Wir haben angenommen, daß es wahrscheinlich länger funktionieren dürfte als andere IPC Verfahren, die u.U. irgendwann in einer in Zukunft liegenden Windowsversion nicht mehr läuft.

Memory Mapped Files, RPC/LPC und Pipes sind elementarer Bestandteil von Windows und werden von Windows selbst exzessiv genutzt. Ich bezweifel ernsthaft das man die jemals entfernen wird. Eher wird irgendwann TCP/IP v4 Support eingestellt ;).

[Dezipaitor]

Memory Mapped Files, RPC/LPC und Pipes sind Grundlagen von Betriebsystemen, die es schon von (fast) Anfang an gibt. Wenn es das nicht mehr gibt, möchte ich gerne sehen, was da Besseres kommt :)

Der Vorteil von Memory Mapped Files, RPC/LPC und Pipes ist u.a., dass man sie schützen kann, so dass nicht jeder Prozess darauf zugreifen kann. Bei TCP/IP muss man sich selbst etwas ausdenken. Aber zumindest funktioniert schonmal die Verbindung.