The Core Technologies Blog

Our Software // Windows Services // 24×7 Operation

Windows Service Patterns

Windows Service Patterns

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.

  1. 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.

    For example:

    • 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.

  2. 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.

    For example:

    • 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.

  3. 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.

    For example:

    • 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.

  4. 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.

    For example:

    • 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!

Posted in Windows Services | Tagged , | Leave a comment

Essential Windows Services: Power

Windows Power Service

What is the Power service?

The Power service implements your computer’s power schemes, policies and notifications as configured in the Control Panel:

Control Panel Power Options

The service’s name (and display name) is Power and it runs inside the shared services host process, svchost.exe:

Power Windows Service

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 service’s screenshot, 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”:

Net stop Power fails

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):

The Power Service in Task Manager

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:

Kill Power Service warning

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:

Blue screen of Death: A critical process died

Be careful!

The Power service isn’t starting. Help!

We suggest the following:

  1. Reboot your computer. Hopefully you have fallen victim to a temporary glitch and sanity will be restored when the operating system next starts.

  2. Manually run Windows Update. If you’re lucky, the Microsoft Windows engineers have already found and fixed the problem with their software.

  3. Seek expert help. Start with a google search for a quick fix; move on to your local administrator if no resolution is forthcoming.

  4. Reinstall Windows. You may have to start over from scratch if nothing else works… :(

Questions? Problems?

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!

Posted in Windows Services | Tagged , , | Leave a comment

Q&A: How do I allow Non-Admins to Start/Stop/Restart my AlwaysUp Windows Services?

Q & A - Windows Service security
  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

Hi Bryant.

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:

  1. Start AlwaysUp.

  2. Highlight/select the application you wish to grant access to. Stop it if necessary.

  3. Select Application > Advanced > Service Security Settings from the menu.

  4. 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.

  5. 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:

    Set Plex Service Security Settings
  6. 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.

Posted in AlwaysUp | Tagged , , , , , | Leave a comment

Q&A: How do I Avoid Errors when Stopping my Plex Windows Service?

Q & A - Shutdown Plex Windows Service
  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?

— Panja

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:

Plex Media Server Processes

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:

Clear PMS service arguments

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.

Plex Media Server Log File

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:

  1. 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.

  2. Start AlwaysUp and edit your Plex Media Server entry

  3. Switch to the Extras tab.

  4. 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:

    Stop Plex Media Server with taskkill
  5. 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!

Posted in AlwaysUp | Tagged , , , | Leave a comment

Q&A: How Do I Give my Windows Service More Time to Stop During Shutdown?

Q&A - Increase Service Timeout
  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?

— Jeff

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:

  1. Windows informs each service that it should shut down

  2. Windows waits until either:
    • all services have stopped, or
    • a fixed period has elapsed.
  3. 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:

  1. Start the registry editor (“regedit”)

  2. In the tree on the left, navigate to:


  3. In the right panel, find the WaitToKillServiceTimeout value. If you don’t see it, create it by:

    1. Selecting Control on the left

    2. Choosing Edit > New > String Value (not DWORD) from the menu

    3. Naming the new value WaitToKillServiceTimeout.

    WaitToKillServiceTimeout registry value
  4. 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.

    Change WaitToKillServiceTimeout
  5. 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:

  1. Call the SetServiceStatus function, passing the SERVICE_ACCEPT_PRESHUTDOWN flag in the SERVICE_STATUS structure;

  2. 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:

  1. Windows notifies all services that have registered for preshutdown notifications to exit

  2. For each of those services, Windows waits until either:
    • the service has stopped, or
    • a fixed period has elapsed.
  3. 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!

Posted in Windows Services | Tagged , , , , , , | Leave a comment

AlwaysUp 11.8: Hourly Restarts, Helpful Application Info, Improved Email Alerts + More

New Release

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:

Restart your application more frequently

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. “″) 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):

View file information

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:

View file information

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.

  • Microsoft Visual C++ Runtime Library 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.


Posted in AlwaysUp | Tagged , , , , | Leave a comment

Q&A: Can my Legacy Application Read Network Drives when Run as a Service?

Q & A - Accessing Network Shares from Windows Services
  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.

— David

Hi David.

Since your application must run as a local user, you should specify the account on AlwaysUp’s Logon tab:

Enter your Windows account on the 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:

Automatically reconnect network drives

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.

Posted in AlwaysUp | Tagged , , , | Leave a comment

Q&A: Can I Activate/Register AlwaysUp Without an Internet Connection?

Q & A - No Internet
  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?

— Florian

Hi Florian.

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:

  1. Get the AlwaysUp-generated serial number from the isolated machine running your application/Windows Service.

    AlwaysUp Serial Number
  2. 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:

    Your AlwaysUp Order Page
  3. 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):

    Assign your AlwaysUp License
  4. Click the Go to Step 2 button to proceed and generate your registration code. Copy that code.

    Assign your AlwaysUp License
  5. Return to your AlwaysUp machine and type in the registration code:

    Enter the Registration Code

    AlwaysUp will confirm that it is registered and you will be good to go!

    AlwaysUp successfully registered

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.

Posted in AlwaysUp | Tagged , , , | Leave a comment