Ich hoffe, dass das nicht gänzlich kalter Kaffe ist - aber damit nicht irgendein anderer in die gleiche Falle stolpert wie ich, schreibe ich es hier noch einmal ausführlich hin:

Auf MSDN steht unter CreateProcessAsUser:

Zitat:

If the lpDesktop member is NULL, the new process inherits the desktop and window station of its parent process. If this member is an empty string, "", the new process connects to a window station using the rules described in Process Connection to a Window Station.

Und in der WIN32.HLP ist folgendes zu finden:

Zitat:

The process created will not run on the application desktop. Rather, Windows will create a separate desktop on which it can run. This desktop can never be made visible so any interactive operations will never get a response. This function should be used for processes that do not require a GUI.

Beide Erklärungen stimmen offensichtlich nicht (WIN32.HLP), bzw. sind nicht vollständig.
Wenn man die STARTUPINFO Struktur nicht füllt, holt sich CreateProcessAsUser die Info, auf welchem Desktop der Prozess gestartet werden soll, aus dem DesktopName Member der RTL_USER_PROCESS_PARAMETERS Struktur des Elternprozesses (der PEB verweist auf diese Struktur).
Was dort steht, wird nur einmal aktualisiert - nämlich beim Start des Prozesses. Wird ein Thread später auf einen anderen Desktop geswitched, wird ein aus diesem Thread mit CreateProcessAsUser oder CreateProcess gestarteter Prozess standardmäßig nicht auf dem Desktop ausgeführt, auf dem der Thread jetzt läuft, sondern auf dem Desktop, auf dem der jeweilige Elternprozess beim Start lief.

Damit sich ein nachträglich interaktiv gemachter Prozess wirklich so verhält wie ein von Anfang an interaktiver Prozess (d.h. standartmäßig Kindprozesse auf dem aktiven Desktop erzeugt), muss also unbedingt auch die RTL_USER_PROCESS_PARAMETERS Struktur mittels WriteProcessMemory angepasst werden.

Es gibt ja "zig" verschieden Möglichkeiten einen Prozess zu starten, und nicht immer hat man dabei die Möglichkeit, eine STARTUPINFO Struktur zu übergeben.

Das wars eigentlich.


Moderiert von Narses: Topic aus Windows API verschoben am Di 26.02.2008 um 17:38

Kannst Du für die betroffenen WinAPI-Funktionen zur Aktualisierung des Desktops bitte kurze Wrapper-Funktionsbeispiele angeben, damit man nen kurzen Einblick bekommt, was man wo patchen muss?

Ansonsten Danke für den Hinweis, kann man sicherlich mal gebrauchen.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

BenBE hat folgendes geschrieben:

Kannst Du für die betroffenen WinAPI-Funktionen zur Aktualisierung des Desktops bitte kurze Wrapper-Funktionsbeispiele angeben, damit man nen kurzen Einblick bekommt, was man wo patchen muss? Ansonsten Danke für den Hinweis, kann man sicherlich mal gebrauchen.

Das geht leider nicht, da ich nicht in Delphi proggen kann. Da ich aber von eurer Bereitschaft hier begeistert bin, anderen - auch wenn man nicht unbedingt selbst etwas davon hat - zurechtzuhelfen, wollte ich auch etwas nützliches dalassen.

An einen Pointer auf den PEB kommst du über die Native API ZwQueryInformationProcess. Der PEB ist schon recht gut dokumentiert und enthält wiederum einen einen Pointer auf die Struktur RTL_USER_PROCESS_PARAMETERS. Wichtig ist, das in der RTL_USER_PROCESS_PARAMETERS Struktur Unicode Strings verwendet werden. Ansi muss man natürlich da erst (mit MultiByteToWideChar oder Native API) umwandeln.

Gerade für dich dürfte diese Erklärung eigentlich schon ausreichend sein.

---Moderiert von Narses: Beiträge zusammengefasst---

Noch was zur Ergänzug...

Was dieser Artikel eigentlich Aussagen soll:
Genau das, wovon Microsoft ganz gern behauptet, dass es nicht möglich sei, ist sehr wohl möglich - nämlich das nachträgliche Ändern der beim Start u.a. in der STARTUPINFO Struktur mitgegebenen Prozessparameter; denn die dort mitgegebenen Daten werden komplett im Usermode gespeichert.