stopping service via WMI
-
I'm working on an app that, among other things, stops the print spooler and clear the print queue. The "ManagementObject.InvokeMethod("StopService", null)" call works with most services, but not the print spooler. When I go into the Management Console and stop the Print Spooler manually a dialog comes up and tells me "When Print Spooler stops, these other services will also stop" (TCP/IP Print Server). I assume that my method call is running into this same thing and doesn't know what to do, so it doesn't stop the service. I know there is a way for me to pass arguments into that method call, but I'm not exactly sure how to pass the command through to say "yes" if it encounters a situation like I mentioned above. Anyone know how to do this? Thanks, Seth
-
I'm working on an app that, among other things, stops the print spooler and clear the print queue. The "ManagementObject.InvokeMethod("StopService", null)" call works with most services, but not the print spooler. When I go into the Management Console and stop the Print Spooler manually a dialog comes up and tells me "When Print Spooler stops, these other services will also stop" (TCP/IP Print Server). I assume that my method call is running into this same thing and doesn't know what to do, so it doesn't stop the service. I know there is a way for me to pass arguments into that method call, but I'm not exactly sure how to pass the command through to say "yes" if it encounters a situation like I mentioned above. Anyone know how to do this? Thanks, Seth
The service control manager (SCM) handles querying for dependent services and stopping them. What you see in the user interface is different than what happens. When you stop a service the
SERVICE_CONTROL_STOPmessage is sent to the service'sHandlerorHandlerExcontrol handlers (this is true with theServiceBaseclass, which encapsulates the native functionality). So, you're right, the code when the service is stopped is the same. But the code that stops a service is different. The Services snap-in for MMC queries the service for dependent services first, then - if you click "Yes" - stops each one, querying those for dependent services. Finally, the select service is stopped. You would need to do the same in your code. See http://msdn.microsoft.com/library/en-us/wmisdk/wmi/wmi_tasks__services.asp[^] for examples of how to determine the dependent services (at the bottom). You'll find some other useful examples of queries to use with theObjectQueryclass. This posting is provided "AS IS" with no warranties, and confers no rights. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles] [My Blog] -
The service control manager (SCM) handles querying for dependent services and stopping them. What you see in the user interface is different than what happens. When you stop a service the
SERVICE_CONTROL_STOPmessage is sent to the service'sHandlerorHandlerExcontrol handlers (this is true with theServiceBaseclass, which encapsulates the native functionality). So, you're right, the code when the service is stopped is the same. But the code that stops a service is different. The Services snap-in for MMC queries the service for dependent services first, then - if you click "Yes" - stops each one, querying those for dependent services. Finally, the select service is stopped. You would need to do the same in your code. See http://msdn.microsoft.com/library/en-us/wmisdk/wmi/wmi_tasks__services.asp[^] for examples of how to determine the dependent services (at the bottom). You'll find some other useful examples of queries to use with theObjectQueryclass. This posting is provided "AS IS" with no warranties, and confers no rights. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles] [My Blog] -
Awesome. That's exactly what I needed. Now I need to decide whether my code should also start any dependent services when it starts a service or if I should leave that to the user... Maybe I'll just notify them. Thanks very much!
It's often better to not do too much automatically that isn't required. Services that depend on yours would have to be stopped, while they don't necessarily have to be started. As a compromise between you and your users, I recommend prompting them - as you should when shutting down your service - to start services that depend on your service. When shutting down a service, you can do a simple Yes/No dialog (using
MessageBox.ShowwithMessageBoxButtons.YesNo). If they choose No you can't stop your service. Simple. When starting it back up, however, it's more difficult than that. You could develop your ownFormderivative with, perhaps, aCheckBoxthat states something like "Also start services that depend on this service". Have it unchecked by default. The tricky thing is that they might've set such a service to Manual and don't want it started. You should check for that, too. In such an event, though, how do you know they don't want it started? To get around this - if possible - record which services you stop and only re-start those if the user has opted to start such services. Or just don't start them like the Services snap-in does. This posting is provided "AS IS" with no warranties, and confers no rights. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles] [My Blog] -
It's often better to not do too much automatically that isn't required. Services that depend on yours would have to be stopped, while they don't necessarily have to be started. As a compromise between you and your users, I recommend prompting them - as you should when shutting down your service - to start services that depend on your service. When shutting down a service, you can do a simple Yes/No dialog (using
MessageBox.ShowwithMessageBoxButtons.YesNo). If they choose No you can't stop your service. Simple. When starting it back up, however, it's more difficult than that. You could develop your ownFormderivative with, perhaps, aCheckBoxthat states something like "Also start services that depend on this service". Have it unchecked by default. The tricky thing is that they might've set such a service to Manual and don't want it started. You should check for that, too. In such an event, though, how do you know they don't want it started? To get around this - if possible - record which services you stop and only re-start those if the user has opted to start such services. Or just don't start them like the Services snap-in does. This posting is provided "AS IS" with no warranties, and confers no rights. Software Design Engineer Developer Division Sustained Engineering Microsoft [My Articles] [My Blog]Right. I implemented a message box that informs them that other dependent services stopped (and the names of those services), just so they know. The people who will be using this will know what services they want running, and it's simple enough for them to restart dependent services themselves if they so desire. They can handle doing that thinking on their own. Interestingly enough, I've found that (in at least some cases) when you start a service that depends on another service that is stopped, it will start that other service first. The TCP/IP Print Server will start the Print Spooler if it's stopped when you pass it the "StartService" method, for example.