child process in windows services

  • Thread starter Thread starter Anonuser
  • Start date Start date
A

Anonuser

I have a service which calls into an exec by the name A.exe. Can I
write a wrapper around A.exe called B.exe which basically does some
custom settings( settng Env variables) and then call A.exe. So A.exe
is the child of B.exe. Would service update messages sent by A.exe be
passed to the Service control manager. What all functions do I need to
write in the code for B.exe.

When A.exe dies will the service control manager report the service as
stopped?
Would I have to monitor A.exe's state in B? I cannot put these custom
settings into A.exe.
Thanks
 
Please see inline...


--
John Phillips
MVP - Windows SDK


Anonuser said:
I have a service which calls into an exec by the name A.exe. Can I
Click to expand...

I don't know what you mean by "calls into an exec". Do you mean "launches a
process"?

write a wrapper around A.exe called B.exe which basically does some
custom settings( settng Env variables) and then call A.exe. So A.exe
Click to expand...

Certainly. The environment settings of the parent are passed to the child
process when calling CreateProcess() and passing NULL for the lpEnvironment
parameter.

is the child of B.exe. Would service update messages sent by A.exe be
passed to the Service control manager. What all functions do I need to
Click to expand...

I'm still foggy about which of these things are services (B I assume is
not). But assuming A is launched by a service, then the answer is no.
SetServiceStatus() requires a handle to the service which is sending its
status, and I'm pretty sure that these handles can't be duplicated with
DuplicateHandle(). One way you might accomplish this is for A to send
messages to the service (via some IPC method such as COM, Window Messages,
Pipes, etc., etc., etc.), and the service would call SetServiceStatus()
based on the content of the message.

write in the code for B.exe.
Click to expand...

You haven't mentioned what B is supposed to do, so this isn't really a valid
question.
When A.exe dies will the service control manager report the service as
stopped?
Click to expand...

No, unless the service tells the SCM that it is stopped. When A dies, it
can instruct the service to stop, via some IPC mechanism (see above).

Would I have to monitor A.exe's state in B? I cannot put these custom
settings into A.exe.
Click to expand...

Really can't say, seeing as how you're a little short on details.
 
Hi John,
Thanks for the reply. Here is a more detailed description.

I have a service which launches process A.exe. A.exe is a third party
process to which I dont have access. I want to create a wrapper around
A or an intermediate process called B.exe.

Not my service launches process B.exe which internally sets some
environment variables and does a create process to launch A.exe.

A.exe was initially built to report status back to the Service
control manager.
I have two choices.
So from B.exe if I make a call to SErvice_Main (or equivalent) for
A.exe then A.exe will think that is started by a service and then
report status like STARTED, PENDING. Will these reach the Service
Control Manager since A.exe is the child of process it(SCM) launched.

OR

if i directly do a createprocess in B.exe (to create A.exe) to launch
it as an application. What all do I need to do in B.exe to correctly
monitor A's status?

What will happen if B fails but A is still hanging? What status will
be reported back to SCM(Service control manager)?

Thanks
 
Is A.exe a service by any chance? If not, just how will it report its
status back to the SCM? Or do you mean that the application is designed to
report its status to its parent or to whomever is interested in A's status?

If A is a service, then the answer is simple: either make your service
dependant on A (so that A will start before your service and if it fails,
then your service will stop), or start A from your service using
StartService(). If you start a service via StartService(), then yes, the
newly started service will post its status to the SCM correctly. It's not
really a matter of who starts the service (your service vs. SCM vs. anybody
else), but if your service application -=behaves=- correctly, by calling the
requisite service registration function on startup, passing a handler
function. Also, the service must be registered via the appropriate registry
entries; statii reporting to the SCM for unregistered services will fall on
deaf ears.

What to do to monitor A from B? Well, that depends on what you want to do.
If A is a service, then you can periodically check its status with
QueryServiceStatus(). Otherwise, you can use one of the WaitForxxxObjects()
functions to wait on A's process handle - when A terminates, the handle
becomes signalled, and WaitFor...() will succeed.
 
Thanks John. Here are some more details/questions. Please see below.


John Phillips said:
Is A.exe a service by any chance? If not, just how will it report its
status back to the SCM? Or do you mean that the application is designed to
report its status to its parent or to whomever is interested in A's status?
Click to expand...

A.exe is an executable which is launched via a Service. For eg. the
Clib book service launches C:\WINNT\system32\clipsrv.exe.

similary "serviceA" launches A.exe . So it is a service.
If A is a service, then the answer is simple: either make your service
dependant on A (so that A will start before your service and if it fails,
then your service will stop), or start A from your service using
StartService(). If you start a service via StartService(), then yes, the
newly started service will post its status to the SCM correctly. It's not
really a matter of who starts the service (your service vs. SCM vs. anybody
else), but if your service application -=behaves=- correctly, by calling the
requisite service registration function on startup, passing a handler
function. Also, the service must be registered via the appropriate registry
entries; statii reporting to the SCM for unregistered services will fall on
deaf ears.
Click to expand...

This is a good way but well thats not what I intend to do. I will now
make "SErviceA" to point to B.exe with some custom settings (like
setting env. variables) and then within B.exe I want to call (launch)
A.exe.

Now when I started "ServiceA" from SCM b.exe gets launched followed by
A.exe.

ServiceA should show as failed even if b.exe or A.exe fails to run.
If B.exe fails then ServiceA might show as failed even though A.exe is
still running. So if B.exe fails A.exe should quit/fail and vice
versa.

I know this is complicated !!!
Thanks



What to do to monitor A from B? Well, that depends on what you want to do.
If A is a service, then you can periodically check its status with
QueryServiceStatus(). Otherwise, you can use one of the WaitForxxxObjects()
functions to wait on A's process handle - when A terminates, the handle
becomes signalled, and WaitFor...() will succeed.
Click to expand...



John Phillips said:
Is A.exe a service by any chance? If not, just how will it report its
status back to the SCM? Or do you mean that the application is designed to
report its status to its parent or to whomever is interested in A's status?

If A is a service, then the answer is simple: either make your service
dependant on A (so that A will start before your service and if it fails,
then your service will stop), or start A from your service using
StartService(). If you start a service via StartService(), then yes, the
newly started service will post its status to the SCM correctly. It's not
really a matter of who starts the service (your service vs. SCM vs. anybody
else), but if your service application -=behaves=- correctly, by calling the
requisite service registration function on startup, passing a handler
function. Also, the service must be registered via the appropriate registry
entries; statii reporting to the SCM for unregistered services will fall on
deaf ears.

What to do to monitor A from B? Well, that depends on what you want to do.
If A is a service, then you can periodically check its status with
QueryServiceStatus(). Otherwise, you can use one of the WaitForxxxObjects()
functions to wait on A's process handle - when A terminates, the handle
becomes signalled, and WaitFor...() will succeed.
Click to expand...
8
t; based
68f
on the content of the message.
 
Okay, I think I know what you're getting at now. My only suggestion in this
case is to (depending on how you want to make one application dependant on
the other's running state) wait on each other's process handles. For
example, if B.exe launches A.exe, then B.exe can pass it's process handle to
A.exe in the CreateProcess() call, and then A can use a wait function on B's
process handle, and B can use a wait function on A's process handle.

If B notices that A's handle is signalled, then it sets its status to to
SERVICE_STOP_PENDING, and goes through its shutdown routine. If A notices
that B's handle is signalled, it simply terminates.
 
Back
Top