The Core Technologies Blog
Our Software // Windows Services // 24×7 Operation
Windows Services are special applications designed to run unattended on your PC. A service an do virtually anything its programmer demands, such as reading files, sending email, checking for viruses — whatever.
Yet in the midst of that tremendous diversity, the vast majority of services have a lot in common. With inspiration from Professional NT Services, it is our observation that the majority of windows services can be placed in one of four categories: Server, Agent, Processor or Canary.
Server: Accept and fulfill requests for services and/or resources
The majority of Windows services implement the Server pattern. They typically act as the proxy/gatekeeper to a well-defined area of the operating system, fulfilling requests as they come in.
Spooler implements the Print Spooler API. It accepts print requests from desktop applications and negotiates with printers to ensure that they all documents are (eventually) printed.
User Profile Service is responsible for loading and unloading user information on behalf of all applications.
Windows Event Log records application, system and security events through the Event Log API.
Agent: Perform a task regularly on behalf of a person
Many services implement the Agent pattern. They run in the background, performing requested tasks at pre-defined times.
Google Update Service keeps your Google software up to date, applying security patches and other improvements as they become available.
The Schedule service works in conjunction with the Windows Task Scheduler, launching each scheduled task at its appointed date and time.
Windows Update automatically detects, downloads, and installs of updates for Windows and other Microsoft programs.
Processor: Watches for important events then takes action
A Processor springs to life in response to a triggering event. It has the autonomy to take action and resolve the issue at hand.
Windows Time ensures that your PC’s clock is correct, synchronizing it with clients and servers in the network.
Background Intelligent Transfer Service opportunistically transfers files in the background when network traffic is low.
Bluetooth Support Service supports the discovery and pairing of nearby Bluetooth devices.
Canary: Notify a person (or application) when something important happens
A Canary is a special kind of Processor. It too watches for important events, but its primary task is to shout loudly instead of taking definitive action.
Windows Defender Advanced Threat Protection Service helps protect against advanced threats by monitoring and reporting security events that happen on the computer.
System Event Notification Service monitors system events and notifies subscribers to COM+ Event System of these events.
Connected User Experiences and Telemetry enables features that support in-application and connected user experiences. The service manages the event driven collection and transmission of diagnostic and usage information (used to improve the experience and quality of the Windows Platform) when the diagnostics and usage privacy option settings are enabled under Feedback and Diagnostics.
Many desktop applications follow a Windows Service pattern too!
Those four patterns apply to regular desktop applications as well. Most notably:
iTunes enables your Apple devices to play any track from your media library. iTunes is a Server.
SyncToy will synchronize two file systems on demand. SyncToy is an Agent.
Dropbox watches your file system and copies updated files to the server. Dropbox is a Processor.
SpeedFan monitors your computer’s voltage, fan speeds and temperatures and lets you know when something is wrong. SpeedFan is a Canary.
If you are responsible for a legacy/desktop application that aligns with one of the four service patterns, you should consider installing it as a Windows Service. It probably should have been built as a service in the first place!
I have installed Service Security Editor
and accidentally DENY one particular service for all users, including local administrator on my laptop. Now I am not able to start the service although I have tried to open from Service Security Editor.
Is there a way to grant the permission again in order to allow me to start the service again? I’m on Windows Server 2012 R2, if that matters.
Hi Charles, sorry to hear that!
You won’t be able to access the service from any account or group where you applied the Deny permission. As Microsoft mentions in the confirmation window, the Deny directive is at the “top of the heap” and always takes precedence over Allow:
Here are a couple of ways to fix your problem:
Solution #1: Restore your Windows Service permissions from a new Administrator account
Did you deny access to the Administrators group?
If not, you can restore your permissions from a new administrator account in a few steps:
Create a new user account — best done from the Control Panel:
Change the account type to Administrator:
Login as the new user.
Start Service Security Editor and open your service. Select the account in the top panel, remove all the Deny entries and replace with Allow rights.
After applying those changes, you should be able to access the service when you next log into your regular account.
Don’t forget to delete the new administrator account you created for this purpose!
Solution #2: Restore your Windows Service permissions from the SYSTEM account
The first solution will not work if you denied access to all administrators. No admin will be able to open the service.
Fortunately the all-powerful SYSTEM account will still be able to manipulate the service. But since you can’t simply sign in as the SYSTEM user and update the service’s permissions, you must take a less than direct approach using our popular AlwaysUp application:
Download and install AlwaysUp.
Even though the software costs $49.99, you can use it for completely free for 30 days — more than enough time for you to restore the rights to your Windows Service.
Setup the command prompt to run as the SYSTEM user in AlwaysUp. To do so:
Select Application > Add to open the “Add Application” window.
In the Application field, enter the full path to the Windows command prompt executable, cmd.exe. On Windows Server 2012 R2 (and almost all other versions of Windows), this is:
Click the Save button to record your settings. An entry for Cmd should appear in the AlwaysUp window:
Select Application > Start “Cmd” in this session. In a second or two, a black command prompt window will appear on your desktop. It will be running in the context of the SYSTEM user.
From the command prompt window, type the full path to the Service Security Editor executable and hit enter. This will start a new instance of Service Security Editor on your desktop:
Open your service in Service Security Editor. Select the Administrators group in the top panel, remove all the Deny entries and add Allow rights.
How about giving full control to all administrators?
Click the OK button to save the updated access rights.
And finally, now that your service is once again accessible, clean up:
Close Service Security Editor.
Switch to AlwaysUp and select Application > Stop”Cmd” to shut down the command prompt.
Hopefully one of these methods will get you back on your feet Charles. If not, please don’t hesitate to get in touch again. There may be another trick or two up our sleeves.
And please be safe!
What is the Power service?
The Power service implements your computer’s power schemes, policies and notifications as configured in the Control Panel:
The service’s name (and display name) is Power and it runs inside the shared services host process, svchost.exe:
Is it safe to disable the Power service?
In their guidance on disabling system services on Windows Server 2016, Microsoft does not indicate that it is OK to disable the Power service. Indeed, they punt on specific guidance altogether, commenting that “the impact of disabling the service has not been fully evaluated”.
Their ultimate recommendation is to stick with the default configuration — automatic start at boot.
The “Stop” button is disabled. How can I stop the Power service?
If you examine the , you will notice that the Stop button is disabled — indicating that the service cannot be stopped.
And even the versatile NET STOP command run as an administrator will fail, complaining that the service isn’t in the right “state”:
This is different from the typical permission/rights problem seen when attempting to stop other important services. Here, the Power service is actively refusing to be stopped under any condition and there is no way around it.
What will happen if I kill the Power service’s process?
Your computer will shut down, immediately.
This is because the Power service is hosted by an instance of the shared service host process (svchost.exe) also running these core services:
Background Tasks Infrastructure Service / BrokerInfrastructure: Responsible for background tasks.
DCOM Server Process Launcher / DcomLaunch: Launches COM & DCOM servers.
Local Session Manager / LSM: Manages local user sessions.
Task Manager will confirm that all four services have the same PID (process identifier):
So killing that svchost process will stop all four services.
If you choose to press on and try to end the process, Task Manager will warn you of the dire consequences:
And that is no idle threat! We were greeted with this delightful blue screen of death after terminating the process on our Windows Server 2019 machine:
The Power service isn’t starting. Help!
We suggest the following:
Reboot your computer. Hopefully you have fallen victim to a temporary glitch and sanity will be restored when the operating system next starts.
Manually run Windows Update. If you’re lucky, the Microsoft Windows engineers have already found and fixed the problem with their software.
Seek expert help. Start with a google search for a quick fix; move on to your local administrator if no resolution is forthcoming.
Reinstall Windows. You may have to start over from scratch if nothing else works…
If you would like to know more about the Windows Power service, or you have a specific problem, please feel free to get in touch. We will do our best to help you!
I’m wanting to know what permissions a user is required to have in order to stop and start AlwaysUp
services. Is there a way to grant access to specific users
as I don’t want to have to give them full Admin rights? I’ve created shortcuts but getting the “access denied” message. Thanks in advance.
— Bryant, Wide Bay Water
Typically, only administrators have the power to control Windows Services. That is an appropriate stance, as most services are administrative in nature.
Indeed, it would be a huge mistake to allow non-privileged persons to stop any of the important tasks servicing the computer in the background. Think of the chaos it could cause!
But there are always exceptions. And the good news is that Microsoft provides the ability to set granular permissions on each Windows Service. You can leverage that API/functionality from command-line tools like Microsoft’s SubInACL but your best option is to work directly with AlwaysUp (which is much easier to use).
How to adjust the rights of an AlwaysUp Windows Service
Follow these steps to grant a non-admin user the ability to start and/or stop your service:
Highlight/select the application you wish to grant access to. Stop it if necessary.
Select Application > Advanced > Service Security Settings from the menu.
In the Service Security Settings window that comes up, select the user in the top pane. You will have to add the account if it’s not there.
In lower pane, choose the permissions you wish the user to have.
Here you see us permitting user “Mike Jones” to read/access and start (but not stop) the Plex Media Server service:
Save your changes.
Afterwards, the user will be able to use the Services Control Panel application, the NET command or the SC utility to manipulate the service created by AlwaysUp.
Remember: The user must work with the full, quoted name of the service, with the “managed by AlwaysUp” suffix. For example, if your application entry is named “VirtualBox” in AlwaysUp, the service will be named:
“VirtualBox (managed by AlwaysUp)”
Easily adjust the rights of non-AlwaysUp Windows Services too!
The instructions above will work for AlwaysUp services, but our free Service Security Editor tool can adjust the permissions of any service. Check it out if you need a general, portable solution for all your Windows Services.
I’ve download the trial version of AlwaysUp and installed it on a Server 2016 standard machine. I’ve created a Windows service for Plex Media Server
and all is working well except for shutting the service down (or restarting).
Every time I restart or shut down the service I’m getting this error:
The application has failed to stop gracefully and may be forcibly terminated. The following processes may be terminated: Plex Media Server.exe, PlexScriptHost.exe, conhost.exe, PlexScriptHost.exe, conhost.exe, Plex Tuner Service.exe, conhost.exe
Can you please let me know what’s wrong?
Hi Panja. We can fix this
But first, a brief explanation of what is going on…
Plex Media Server (PMS) launches several processes
When you start PMS (either normally on your desktop or as a service from AlwaysUp), the main executable (Plex Media Server.exe) spawns a family of processes. Those processes work together, invisibly in the background, to share your files with hungry devices.
You can see the “tree” of up to 8 processes with Microsoft’s Process Explorer:
Exiting PMS from the tray icon closes all the processes
When Plex is running normally on your desktop, you close it by selecting “Exit” from the tray icon menu. The main process receives the signal and quietly closes the other 7 processes. You never witness the behind-the-scenes coordination.
AlwaysUp tries several methods to exit PMS and close all its processes
When you are running Plex Media Server as a background service, there is no tray icon. You must rely on AlwaysUp to shut down PMS and its family of processes.
AlwaysUp tries up to four methods to close the media server properly. The error message you see is reported because the first two methods are unsuccessful and AlwaysUp must move on to the last two, more “aggressive” tactics.
However, looking at the logs, the third stop-method works for Plex. The server isn’t actually being “forcibly terminated”. So though annoying, you can safely ignore the error — it is a false alarm.
But who likes to see a useless error message, right? Here are a couple of ways to eliminate it entirely. Choose one or the other; no need to do both:
Solution #1: Remove the “nointeractive” flag from the arguments passed to Plex
In our step-by-step tutorial, we recommend running Plex Media Server.exe with the -nointeractive flag. This tells Plex that it should not create a tray icon because we cannot access it when PMS is running in the background (in Session 0).
However, when the flag is specified, Plex doesn’t create a main window either. And without a main window, AlwaysUp cannot send Plex the “default” signal to close.
Without the flag, AlwaysUp is able to close Plex smoothly — sans error messages.
To remove the nointeractive flag, edit your PMS entry in AlwaysUp and clear the Arguments field:
There is only one (minor) downside to this solution. Without the flag, Plex will print a warning to its log file every few seconds. This won’t be a problem — unless you are a techie digging into the Plex internals — but it deserves to be mentioned.
Solution #2: Stop Plex with taskkill
The second alternative is to plug in a separate program to close PMS. Several folks on the Plex forums recommend using the Windows taskkill command.
To configure AlwaysUp to shut down Plex with taskkill:
Create a batch file with this line:
taskkill /t /f /im “Plex Media Server.exe”
As you can see from the taskkill documentation, this command will terminate PMS and all its child processes.
Start AlwaysUp and edit your Plex Media Server entry
Switch to the Extras tab.
Enter the full path to the batch file you created in step 1 in the Use this special command to stop the application field. And you might as well give taskkill up to 30 seconds to do its work by completing the field below that:
Save your settings
With this solution in place, the next time you stop PMS from AlwaysUp:
AlwaysUp will run the batch file
The batch file will run taskkill
taskkill will close all the PMS processes
AlwaysUp will see that PMS has closed and will set the state of the Plex Media Server entry to “Stopped”.
No error messages!
One of our file ingestion services can take a while to finish all pending database updates and exit cleanly. Sometimes when we reboot the server, Windows doesn’t wait for the service to finish, and we end up with database corruption, which is a huge pain.
How do I get Windows to wait until my service is done and not kill it while it’s still working?
Hi Jeff, sorry to hear of the database corruption!
For obvious reasons, Windows tries to shut itself down as quickly as possible. The goal is to complete the process in 20 seconds or less.
Applications and services that don’t respond within that time frame are classified as hung and are promptly terminated. As you have seen, this can lead to undesirable results.
Clearly this bias towards a quick shutdown makes sense for a desktop computer because a person is likely waiting patiently at the keyboard and mouse. However, it not ideal for servers running important background processes. In the server scenario, where interactive user experience is less of an issue, a safe shutdown should take precedence over a speedy one!
Fortunately there are a couple of ways to swing the balance of power to your Windows Service:
1. Extend the “Shutdown Timeout” for all Windows Services
As far as services are concerned, Windows follows this procedure when shutting down:
Windows informs each service that it should shut down
- Windows waits until either:
- all services have stopped, or
- a fixed period has elapsed.
Windows forcibly terminates any services still running
By default, that “fixed period” is only 5 seconds — insufficient time for your busy service to wind down gracefully.
Fortunately we can extend that period by modifying this registry value:
How long does your service need to exit gracefully? Will 60 seconds be enough?
To change the timeout:
Start the registry editor (“regedit”)
In the tree on the left, navigate to:
In the right panel, find the WaitToKillServiceTimeout value. If you don’t see it, create it by:
Selecting Control on the left
Choosing Edit > New > String Value (not DWORD) from the menu
Naming the new value WaitToKillServiceTimeout.
Double-click the WaitToKillServiceTimeout entry to bring up the Edit String window. Enter 60000 in the Value data field (it’s in milliseconds) and click OK to save your change.
Reboot your computer. You don’t have to do that right now, but the new timeout setting will not take effect until Windows restarts.
Note that this modification will not make Windows wait indefinitely for your service to finish. If your service takes longer than 60 seconds, it will still be terminated. Be sure to choose a timeout value that is long enough to cover your scenario, but not too long to make shutdown intolerable.
2. Update your Windows Service to accept Preshutdown Notifications
Changing the WaitToKillServiceTimeout setting is a quick fix but the delay you specify will apply to all services. If another, non-critical service is hung, Windows will wait the full duration before terminating it.
To make sure that Windows waits for your specific service, you should update the code to accept preshutdown notifications.
Specifically, your service must:
Call the SetServiceStatus function, passing the SERVICE_ACCEPT_PRESHUTDOWN flag in the SERVICE_STATUS structure;
Clean up and exit when it receives the SERVICE_CONTROL_SHUTDOWN notification.
This article reviews the code to be added in C# projects.
How preshutdown works
The preshutdown process was introduced in Windows Vista (circa 2007). As the name suggests, it runs before the regular shutdown process. Its purpose is to give mission-critical services an early start on exiting, ahead of less important modules.
The preshutdown process looks like this:
Windows notifies all services that have registered for preshutdown notifications to exit
- For each of those services, Windows waits until either:
- the service has stopped, or
- a fixed period has elapsed.
Windows proceeds with the regular shutdown procedure (see above)
By default, that fixed period is 180 seconds (3 minutes) — more than enough time for most Windows Services to tidy up and exit gracefully.
But what if you need more than three minutes? Fortunately Microsoft has provided a solution there as well…
How to extend the preshutdown timeout beyond 3 minutes
With a simple code change, a preshutdown service can instruct Windows to wait more than the default 3 minutes for the service to end in the preshutdown phase.
You must add code to call the ChangeServiceConfig2 function with the SERVICE_CONFIG_PRESHUTDOWN_INFO level, and the timeout value in the SERVICE_PRESHUTDOWN_INFO structure set to an appropriate value.
Here is what the addition looks like in C++ (error checking omitted for brevity):
SC_HANDLE hService = OpenService(...);
info.dwPreshutdownTimeout = 5 * 60 * 1000; // 5 minutes
ChangeServiceConfig2(hService, SERVICE_CONFIG_PRESHUTDOWN_INFO, &info);
The new code is best called once when you install/setup your service, but it can be invoked during normal operation as well. Whichever works better in your situation.
Hopefully one of these two solutions will delay shutdown long enough to eliminate the database corruption. Please try them, and be sure to get in touch if you have any questions!
AlwaysUp version 11.8 is out!
Here are some highlights of this new release:
Automatically restart your application every 2, 4, 6, 8 or 12 hours
Are you running a legacy application that leaks memory or other resources? Does restarting it cure all ills?
If a daily restart is not enough, you can now recycle your program more frequently — as often as every 2 hours.
The new periods are available in the Every setting on the Monitor tab. Expand the drop-down to select the desired time frame:
Of course, please use this new power with caution. Very few applications need to be restarted 12 times a day! Be sure to consider the impact on your customers, who may be interrupted as your software goes up and down during working hours.
View relevant file information in the “Running” tooltip
When your application is running as a Windows Service in AlwaysUp, you can click the green “Running” circle () to show details of the running process.
That popup now includes additional information. It highlights key “metadata” of the executable file being run:
File description: A free-form description of the file — usually the name of the product or a component (e.g. “Dropbox” or “iTunes”).
File version: The version number of the file. Usually 4 digits in dotted notation (e.g. “184.108.40.2062″) but can also contain a build/version identifier.
File date: The date and time when the file was last modified.
Company: The name of the company that produced the file.
Here is what the new tooltip looks like (when running Plex Media Server as a service):
We added this information to help customers manage change. For example, if an automatic update installed new software and your setup isn’t working as expected, the version number and the date will alert you that the executable file was recently updated.
By the way, you can see most of these values in the executable file’s properties. In Windows File Explorer, right-click the file and select “Properties” to summon an informative popup. The metadata will be available on the “Details” tab:
Receive email alerts whenever the service stops
AlwaysUp can be configured to send you an email alert whenever your application stops. That option is available on the Email tab.
However, prior to this version, AlwaysUp would not send a message when the application was stopped because the underlying Windows Service exited. This was fine when the service was stopped from the AlwaysUp console, but not when the service was being closed by Windows (e.g. as part of a system shutdown). The behavior has been updated and email will now always be sent.
One note from our development team though: Emailing when the system is shutting down may not be 100% reliable. At shutdown, Windows may abruptly close AlwaysUp before it has had a chance to send the email. Furthermore, some supporting systems (which have been signaled to close) may not be available to deliver an email.
Other fixes & improvements
If your application is running and you change the startup type to “Disabled”, AlwaysUp will no longer stop the application. This new behavior is in line with Services.msc.
If an application/service marked as “Disabled” is running, it can now be stopped from AlwaysUp.
Command-line operations to start, stop or restart the application/service were ignoring the “silent” parameter and always showing the progress window. This has been fixed.
errors/popups are now classified as fatal. If your application encounters one of these errors, and the “stop when the most serious are encountered” box on the Extras tab is checked, your application will be stopped and restarted as specified.
Several small under-the-hood tweaks for the March 2019 preview of Windows 10 are included in this release. (There were no significant changes to Windows Services in that iteration of the OS.)
As usual, please review the release notes for the full list of features, fixes and improvements included in this release.
Upgrading to AlwaysUp Version 11.8
If you purchased AlwaysUp version 10 (after January 2017) you can upgrade to version 11.8 at no additional charge. Simply download and install “over the top” to preserve your existing applications and all settings. Your registration code will continue to work.
If you bought AlwaysUp version 9 or earlier (before January 2017), you will need to upgrade to use version 11.8. Please purchase upgrades here — at a 50% discount.
See the full upgrade policy for additional details.
I am evaluating AlwaysUp
. I have a legacy application which must run as a local user. I can get it to run as a service using AlwaysUp.
The application works with parameters. These point to a domain folder (eg. \\MyServer\Data1\). There is an obvious contradiction on one hand, running an application as a local machine user, and on the other hand, trying to access a domain folder. Wondering if there is any way AlwaysUp can accommodate this?
I have mapped a drive from the local user to the network folder and cached credentials. This works. Only problem is cached credentials sometimes expire.
Since your application must run as a local user, you should specify the account on AlwaysUp’s Logon tab:
Please enter the username and password for a user that has logged in and run your application successfully — likely the account you are logged into now.
With that account in place, AlwaysUp will run your legacy application in the context of that user. Your program will be able to read from and write to any files that the account has permission to access.
However, as you point out, using drive letters can be tricky. Beyond cached/saved credentials, drive mappings may not be automatically applied when you login as a service. For example, that “P” drive you see in Windows Explorer may not be available to your program running as a Windows Service.
Fortunately, AlwaysUp can usually re-create your drive mappings. Check the Attempt to automatically reconnect all network drives option on the Extras tab to enable that feature:
But as the text implies, automatically reconnecting doesn’t work in all situations. Sometimes a password is required.
To totally sidestep the issues of drive letters when running as a service, we recommend using UNC paths instead of mapped drives whenever possible. Since your account has permissions to the underlying resource, that shouldn’t pose a problem.
Will your application accept a UNC path? Please test to find out.
Troubleshooting network/mapped drives (and other issues)
By the way, launching the command line interactively as a Windows Service through AlwaysUp will give you the opportunity to experiment with your application as a service.
For example, you can try to:
Change the directory (CD) to the UNC path and confirm that the files are accessible
Run the full command to launch your legacy application with UNC path parameters. If it fails, you may have a permissions issue. Look to your application’s log files for clues.
Best of luck with your legacy program/service! Please get in touch if you have any other questions.
My company is interested in your AlwaysUp software
. We would like to implement it in computers which are not connected to the Internet. These computers can’t be connected to the Internet, not even for a few minutes.
Is it possible to activate the license without the Internet?
The machine running AlwaysUp does not need to be connected to the Internet to register the software. Your situation is perfectly fine, and we have many customers running AlwaysUp on isolated computers.
However you will need to access the Internet from another machine, to complete the online registration process. Here is an overview of the procedure.
How to activate AlwaysUp on your offline computer
To register your installation of AlwaysUp, you will:
Get the AlwaysUp-generated serial number from the isolated machine running your application/Windows Service.
Switch over to a computer connected to the Internet. Find the email we sent thanking you for your purchase and click the Manage your order button to visit your order page in your web browser:
Click the Assign a license to a computer button. Enter the serial number you collected in step 1 (along with a brief description of your installation/machine):
Click the Go to Step 2 button to proceed and generate your registration code. Copy that code.
Return to your AlwaysUp machine and type in the registration code:
AlwaysUp will confirm that it is registered and you will be good to go!
And once registered, AlwaysUp will not use the Internet — unless you have configured email alerts, or you manually invoke the “check for updates” functionality.
Hope this makes sense! Please get in touch if you have any other questions.
I followed your NET article
on how to stop a service but when I run NET STOP
it fails with “System error 5 has occurred Access is denied”.
It looks like a permissioning issue but do you have any way to get it to work? Did I do something wrong?
Yes, this is definitely a problem with permissions. You can see that it happens on our Windows 10 system too:
But you may be able to get around it! Here are our recommendations:
1. Ensure that you are running NET from an elevated command prompt
Are you running NET STOP from a command prompt window? The access denied error will be raised if the prompt does not have sufficient rights to stop the service.
You see, Windows typically starts the command prompt (and other applications) without administrative rights — even if you are an administrator on your computer. This policy — called User Account Control (UAC) — is an important security measure that protects your computer from viruses and other malicious activity.
Because of UAC, you must explicitly indicate whenever you want to run an elevated command prompt — one with enough administrative rights to stop a Windows Service.
To start an elevated command prompt (instructions for Windows 10):
Type cmd in the taskbar search box.
An entry for the “Command Prompt” desktop app should appear in the list of results. Right-click that entry and choose Run as administrator:
You may be prompted to confirm that you want to run as an administrator. Click Yes to proceed:
The elevated command prompt will appear on your desktop. The window’s caption should contain the word “Administrator” (which indicates that it is running with full admin rights).
Try stopping your service with NET.EXE from there. Move on to the next recommendation if the problem persists.
2. Grant yourself permission to stop/start the service
Does the error still occur when you run NET from an elevated prompt? If so, it means that your Windows account does not have permission to stop the service. An administrator must grant you that right.
Are you an administrator? Maybe you can give yourself the right to stop the service! Our free Service Security Editor should be able to help.
To grant yourself stop-service rights:
Download Service Security Editor and save it to a known location
Start Service Security Editor
Select your service from the list and click Open
In the Service Security Settings window, select (or add) your account in the top pane and grant yourself the appropriate rights in the lower pane:
Click OK to record your settings and Done to exit Service Security Editor
If that doesn’t work, then you don’t have permission to grant yourself rights to the service. You have one final option remaining…
3. Ask your system administrator to grant you rights to the service
If an elevated prompt isn’t successful and you can’t give yourself the right to stop the service, you are stuck. You simply do not have the authority to stop the service on your own.
Please consult a system administrator. Explain what you are trying to do with the NET.EXE command and ask them to authorize you to stop the service.
And be sure to let them know about Service Security Editor, which will help them to complete their task without fuss.
All the best!