Why does ServiceBase.DeferredStop's catch() block call SetServiceStatus to revert the service-status to RUNNING when the process is doomed anyway? #106570
Unanswered
daiplusplus
asked this question in
Q&A
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
While doing research for my answer to this question on StackOverflow I noticed that in all versions of .NET (from .NET 8 going right back to .NET Framework 1.1), the
ServiceBase
class'sDeferredStop
method (or its equivalents in older versions) has acatch
block that logs the exception and then re-throws (which will lead to the CLR termianting the process becauseDeferredStop
runs in a CLR Thread Pool thread).Currently (in .NET 8) it looks like this:
try{}
block covering multiple statements (OnStop()
,WriteLogEntry()
, andSetServiceStatus()
) - thecatch
seems like it's only prepared to catch exceptions thrown fromOnStop
- methinks that should be tweaked.catch
block we see_status.currentState = previousState;
- in this situationpreviousState
will be eitherSTATE_RUNNING
orSTATE_PAUSED
.SetServiceStatus(_statusHandle, pStatus);
to inform SCM the service status has transitioned fromSTATE_STOP_PENDING
toSTATE_RUNNING
orSTATE_PAUSED
.STATE_RUNNING
toSTATE_STOP_PENDING
and then toSTATE_STOPPED
. Once inSTATE_STOP_PENDING
the status cannot transition to any other state exceptSTATE_STOPPED
.So... why does it do something that it shouldn't need to and is quite clearly an invalid operation? (and not even any code-comments around it?)
Should
DeferredStop()
be like this instead?Beta Was this translation helpful? Give feedback.
All reactions