Some services can't start or stop with Service Management Console.
ex) DcomLaunch, SamSs
These services's stop button is disabled on Service Management
Console.
So, we can't stop the services.(Even if we have a Administrator
account)
Is it possible?
How can I do that?
Thanks in advance.
Your service ultimately calls SetServiceStatus to specify its status. Part of this is what controls it accepts. If you don't specify SERVICE_ACCEPT_STOP, the service cannot be shutdown. For managed code, you can set the CanStop property on ServiceBase.
Another possibility that allows a bit more finegrained control is to change the ACL on your service. MSDN has a sample article here. This is usually used if you want to allow non-admin users to be able to control when your service is running.
Please think very carefully if your service shouldn't be stopped - users should be in control of their machine and allowed to stop services at will.
Related
I have some .NET code in a COM+/Enterprise Services serviced component. I communicate with this component from a WPF application and also from a legacy VBA application.
This arrangement works well when only one user is logged on to a machine. The component starts in its own process when either the .NET or the legacy application instantiates one of its COM objects.
The system also works for the first user to try to run it on a terminal server installation. However, when another user logs on, he/she is unable to use the application. I had hoped that each session would run in isolation, and that one host process would run per session. Am I wrong in this expectation?
In Component Services on the Activation tab my application is configured to run as a "Server application". On the Identity tab, "Interactive user" is selected. On the Security tab, "Enforce access checks for this application" is unchecked.
There isn't session isolation as you describe, instead process ownership limits what you have access to.
Your conclusion seems correct & you will need to determine a suitable mechanism to exchange data with the service.
I used WCF to create a service with a net named pipe listener https://learn.microsoft.com/en-us/dotnet/framework/wcf/index
The idea of using proxies to make rpc calls is attractive, but I found the proxy definitions and stubs to link it all together quite clumsy to use.
If you have events that may be triggered at either end then keeping client/service in sync becomes problematic.
AIUI you cannot invoke a rpc method that ends up invoking an rpc back at the originating end, although that could be a named pipe limitation.
If I was doing this again I would use a socket server in the service & the websocket protocol for biderectional data transfer, even though you might need to implement some thread handling to avoid the listener thread blocking whilst servicing requests.
Hard to find anything authoritative on this. For standard COM you can set the identity to 'Launching user'. The same is not available for COM+.
According to this archived post,
A COM+ application can be configured to run under the logged in account, or
a specified account. Under the application properties, see the Identity tab.
...
Once set however, it remains under that account until the application shuts
down, so you can't have multiple users using the same COM+ application under
different IDs.
That seems to match what is said in this knowledge base article too.
My conclusion is, I should probably accept that my component must run once per machine rather than once per session. It will need to be modified to accommodate this. Since it needs to start new processes in individual sessions, it will have to run as a Windows service under the Local System account (giving due attention to the security implications).
I am building a Windows service that will watch for specific occurrences of events and disk activity. When such an event occurs my plan is to alert the user to the event via a client app, and provide remediation if necessary. I have (mostly) completed both the client and service components, which work great... unless the client app isn't running.
In short, I am looking for a way to start up the client app from the Windows service via CreateProcess to provide information to the user. However, it appears the service can't even see the file/folder of the client app to execute it. I suspect this is due to the credentials under which the service is running, or maybe due to service level restrictions, but wanted to reach out for some advise before I get into this any deeper.
So, the obvious question first... am I thinking about this clearly? Is the architecture plan sound, or should I look at another method? I would prefer not to re-do any of the work I have already completed, but obviously want to make sure the plan and process is solid.
Question #2, what are the limitations I face with this model? Is there a service account that will allow this level of access?
I am obviously struggling with this right now, so any thoughts or assistance will be greatly appreciated!
Thanks,
Kris
As others have mentioned already, you can't (easily) launch an application directly from the service, so I think the easiest way around the problem is to create a process that starts on login and runs with the credentials of the logged in user, eg an app that sits in the system tray, and it opens up a named pipe or a network port to the service. If the service needs to alert the user, it sends a message down that channel and then the client process can either show its own UI or launch an application. Interprocess communication using pipes or ports are the simplest way to deal with the restrictions on session 0 processes.
A Windows service does not have access to the user session in Vista and above, so it is blocked from starting an executable on that session. You can download a white paper from Microsoft that goes into detail: Impact of Session 0 Isolation on Services and Drivers in Windows.
Since Vista, services run in session 0 and the user's desktop is always in a different session. Thus you need to work hard to start a service on the user's desktop.
It can be done but it is pretty tricky. Details can be found here: http://blogs.msdn.com/b/winsdk/archive/2009/07/14/launching-an-interactive-process-from-windows-service-in-windows-vista-and-later.aspx?wa=wsignin1.0
I created a service in Visual C++. Installed it using instsrv.exe and srvany.exe.
When I check at the Services applet in Control Panel, the service is registered. But when I want to start it, this message appears:
the service on Local Computer started and then stopped. Some service stop automatically if they have no work to do, for example the Performance logs and Alert Service.
I just have this code inside my OnStart function:
(void)system("C:\ReleaseExe\Example1Server.exe");
I my code correct? Or is there any other way to code it to make sure that the service can be in running state?
Assuming that exe you are starting up is actually your service, this is the wrong way to do it.
The Windows Service Control Manager (SCM) actually calls into your service's EXE via defined entry points - you need to provide the logic to do what your particular service needs in those entry points, including notifying the SCM of state changes in your service (STOPPED-> RUNNING, RUNNING->STOPPED, and so on).
Read the background info on MSDN, starting here, for clarification of what you must provide. Note that OnStart is specific to implementing Services in managed code, you won't be doing it that way in Visual C++. Perhaps C# would be an easier route?
Is there a way for an application to get notified that a specific service is set to disabled?
I have a NT service and I want to "catch" this event and keep that time for later use.
Any thoughts on how to do this?
Thanks
You ought to be able to do something in WMI to do with that. I think that you can subscribe to the __InstanceModificationEvent notification for the particular instance of Win32_Service that you're interested in.
On the other hand, if someone's going to stop and disable the service, they'll just stop and disable the process monitoring it. So you're not going to win, anyway.
Why don't you just secure the service ACL so that only Administrators can stop and disable it? This is, in fact, the default anyway. And if the user's got admin privileges, you've already lost.
other parts of my client app will poll and call RegNotifyChangeKeyValue to see if the service is disabled, it is I will make note of it...
When a machine reboots, do all the services which are run under the accounts (system/service/network service) get run before a user logs on?
JD.
Services have a "start type" defined per-service, those types are boot, system, auto, demand, disabled. Services also have dependencies on each other, defined in the registry.
Services with boot and system start type are started during the time period when only NT Native binaries can run (the Win32 API is not yet ready). For example, these services include such as csrss.exe which provides some of the Win32 API.
Once Win32 has been initialized, the services with start type automatic are started. During this time, the service which allows the user to log in runs -- this displays the login prompt and does allow the user to log in.
In every case, if the service being start depends on other services, then the other services will be started in advance.
So, yes, it is possible for users to log in prior to the execution of a service. However, if the login service were to depend on your service... Better, though, if you detect that your service has started. Considering using a named global event with CreateEvent() api. Your service creates the event, your application awaits the event before calling the service. Also, your app can use the ServiceControl API to start the service only when in use.
The windows "Services.msc" management plug-in hides the boot and system services. To learn more about these startup types, refer to this API documentation: MSDN: ChangeServiceConfig Function .
Yes, using (by default) a built-in Windows account. In Services (run services.msc) there is a "Log On As" column that tells you the user that the service logs in as.
I do not think so. This should be asynchronous. If you are fast enough to log on, some of the services will still be coming up. This does not include "system" services