not have to be close). However, my previous posting about WinMain must
Hi Ivan/Kerem,
Thank you for your postings. I have done much testing after your
suggestions, and attached is the test source code, which is a simple do
nothing service program.
I am using Sleep here to simplify the synchonization between ServiceMain
and WinMain. I have done experiments with using thread handle and event
to achieve the synchonization, and the result is the same, that WinMain
must end before ServiceMain.
In the code, you will notice 2 Sleeps (1 at the end of ServiceMain, and
another at WinMain), both commented out. Now, if I were to add a short
delay at the end of WinMain, say 20 milisecond, the service is likely to
crash when it is stopped. If I were to put the delay longer, say 1
second, it crash for sure. This is just a simulation for a short delay
for WinMain to exit, because I do have some C++ objects at file scope
that is clean up when WinMain exits.
The question I have is whether my conclusion about WinMain must end
before ServiceMain is correct.
Now, another observation is, if I add another delay in ServiceMain, as
long as this delay is longer that the WinMain delay, the crash is
prevented. You can even try some outrages number for the delay, like 3
seconds for ServceMain and 3.5 seconds for WinMain, then, as crash
happens 3 seconds. Then, you switch it around, 3 seconds for WinMain, and
3.5 seconds for ServiceMain, no crash.
With regards,
Cheng Wu
"Ivan Brugiolo [MSFT]" <ivanbrug@online.microsoft.com> wrote in message
news:emRR%23YXxHHA.5028@TK2MSFTNGP06.phx.gbl...
Any synchronization based on Sleeps is indication of lack of
understanding
of the original problem.
Can you post the output of the [cdb|ntsd|windbg] command `r;~*kb` with
good symbols ?
The recomendation in MSDN to use RegisterWaitForSingleObject is there
only not to waste a thread when you are running in a
process with 20 co-hosted services.
It is there to avoid 20 threads sitting there in their SeviceMain
waiting
for the
termination event to be signaled by the code-path the reports
the status as SERVICE_STOPPED.
In general, doing cleanup after SERVICE_STOPPED has been reported
is root cause of evil race conditions.
From the point of view of the Service Control manager, anything that
happens
after SERVICE_STOPPED is irrelevant, and, the Service Control Manager
if free to create one more thread that starts fresh with a new call to
ServiceMain.
Logically, you can assume that the Genration-N of your service is done
after
SERVICE_STOPPED has been reported, and, Generation N+1 is ready to
begin.
Any state shared between the two generation should be avoided
(no global variables, etc, etc).
--
--
This posting is provided "AS IS" with no warranties, and confers no
rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Cheng Wu" <chengwuchew@yahoo.com> wrote in message
news:Oy4CRQ1wHHA.4228@TK2MSFTNGP06.phx.gbl...
Hi gurus,
I need some advise on the ServiceMain exit strategy.
I have a service program when occassionally crash when the service is
stopped. After some testing, I found that the thread that crash is
ServiceMain thread when it returns to advapi32.dll.
My ServiceMain waits upon a stop event from my
ServiceControllerHandler,
when this event is triggered, the ServiceMain performs clean up,
SetServiceStatus to SERVICE_STOPPED then exit (as in end of function).
I
notice as soon as SetServiceStatus is called, the application main
thread
will continue, which will quit WinMain and have all the CRT clean up
(this
means at this point of time, ServiceMain thread and application main
thread are running at the same time)
My guess is that the crash has something to do with the timing of
ServiceMain thread returning. So, I added a short delay using Sleep in
the application main (right before WinMain returns, so that,
ServiceMain
thread will return before WinMain), and this, makes the service crash
everytime it is stopped).
Then, I added a short delay in ServiceMain, so that WinMain returns
before
ServiceMain returns. This actually solve the crash. However, now I
notice that upon WinMain returns and CRT cleanup, the ServiceMain
thread
is somehow stopped (i.e., it did not run the debug print statement
after
the Sleep). I am happy that this solve the crash, but I would like to
know if this strategy is good for the system health, knowing the fact
that
I use Sleep to prevent ServiceMain from returning naturally and let the
system end the ServiceMain thread.
Note that I could not use RegisterWaitForSingleObject as suggested in
the
ServiceMain documentation because I want my software to be compatible
on
NT.
Any comment is greatly appreciated.
With regards,
Cheng Wu