🚀 go-pugleaf

Paul wrote:

Please don't start messages with "-" as it strips the rest of the message from replys.


>1. EnumWindows does not have this process id in the list returned when
>trying to get the new window handle to use, so no messaging is possible
>withou a valid handle.

The window hasn't been created yet so Enum won't find it.

>2.Manually entering the windows handle of the restarted process into
>the guardian and using PostMessage - The restarted process does not see
>the message.

Probably the wrong handle.
Unless RegisterWindowMessage is messing up.

>Anyone have some clues on what I am doing wrong ?

Pass the starter's (service or guardian) handle (converted to text) to the Application on
the commandline and wait for it to contact you with the  registered message.  It can place
it's own handle in the message. Eliminates enum.

(BTW, who guards the guardian?)

"Paul" <camrad@internode.on.net> wrote in message
news:46a0a522$1@newsgroups.borland.com...

> Each of the above is started with
> if (CreateProcess(...
<snip>

Which means that each process is going to run in the context of the user
account that the service is running it.  By default, that is the SYSTEM
account.  Also, unless you are filling in the lpDesktop member of the
STARTUPINFO structure, then each process is going to run in the context of
the service's workstation as well, which is hidden and does not have access
to the workstation that the user logs into.

> Using Windows Messaging
> - RegisterWindowMessage
> - EnumWindows to get the required handle
> - then PostMessage

That won't work in a service unless you first connect it to the user's
desktop via SetThreadDesktop().  Same thing with spawned processes - they
must be running in the same desktop that the target window is running in, or
else EnumWindows() and PostMessage() will fail to locate it.

> At this point EnumWindows can find the required handle from
> the process id. There may or may not be a user logged on at
> this point - it makes no difference to the following outcomes.

Yes, it does make a difference.

> EnumWindows does not have this process id in the list returned
> when trying to get the new window handle to use, so no messaging
> is possible withou a valid handle.

Every time a process is restarted, the other apps will have to rescan the
active windows in order to get the new ID.  Alternative, assuming the
guardian is running in the same desktop as the other processes, it could
simply broadcast a message containing the old and new IDs, and the processes
can then update themselves accordingly.

> Manually entering the windows handle of the restarted process
> into the guardian and using PostMessage - The restarted process
> does not see the message.

That suggests to me that the guardian is not actually running in the same
desktop afterall, as window messages cannot pass across desktop boundaries.


Gambit

Remy Lebeau (TeamB) wrote:

> 
> "Paul" <camrad@internode.on.net> wrote in message
> news:46a0a522$1@newsgroups.borland.com...
> 
> > Each of the above is started with
> > if (CreateProcess(...
> <snip>
> 
> Which means that each process is going to run in the context of the
> user account that the service is running it.  By default, that is the
> SYSTEM account.  Also, unless you are filling in the lpDesktop member
> of the STARTUPINFO structure, then each process is going to run in
> the context of the service's workstation as well, which is hidden and
> does not have access to the workstation that the user logs into.

I was not setting any value for lpDesktop. Setting this to 
"WinSta0\\Default" in the Service and the Guardian fixed my problem in
this instance. Reading the M$ web on this subject presents other
possibilities I have not yet explored.
> 
...snip

Thanks for you help on this. Got me going in the right direction. Much
appreciated.

cheers
Paul

Bob Gonder wrote:

> Paul wrote:
> 
> Please don't start messages with "-" as it strips the rest of the
> message from replys.

Point taken.

In this case, the problem was solved by setting the lpDesktop parameter
to "WinSta0\\Default" in both the Service and Guardian when calling
CreateProcess()
...snip

> (BTW, who guards the guardian?)

No one, If there was a guardians guardian, who would guard the
guardians guardian ?

cheers
Paul
--