The Core Technologies Blog

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

Support for Windows 7 and Windows Server 2008 Ending in January 2020

Windows Server 2008 R2 End of Life

After more than a decade in the trenches, Windows 7 and Windows Server 2008 R2 will no longer be supported. Microsoft will stop issuing updates for those operating systems on Tuesday January 14, 2020.

I’m still running Windows 7/Server 2008: What does this mean for me?

After the deadline, your computer will no longer receive Windows updates/patches. This is probably fine for new features and capabilities (who needs those anyway?), but it is potentially lethal for safety and security.

This is because any serious security flaw discovered after January 2020 will not be fixed. Attackers will have all the time they need to break into your computer.

We recommend upgrading ASAP — especially if you are working in a commercial environment. Why put you and your company at risk for a ransomware or other cyber-attack?

Will your software (AlwaysUp, Service Protector, etc.) continue to work on Windows 7/2008?

Yes. For now, all our current software will continue to work with the soon-to-be-retired versions of Windows. We will not be disabling those operating systems in any versions of our Windows Services software that you can download today.

However, at some point we will drop support for 7/2008. For example, AlwaysUp version 13 (expected in 2021) may no longer run on 7/2008. Of course, you will be able to stick with version 12 (or earlier) for as long as you like.

Will you provide support if I’m running Windows 7/2008?

Yes — up to a point. We’ll happily investigate problems on those systems, but realize that our hands will be tied if the flaw is due to a problem in the underlying (now obsolete) operating system.

Additional information/resources

As usual, please get in touch if you have any questions or need help working with our software after the deadline has passed.

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

Q&A: How Do I See the Output/Traceback From my Python Windows Service?

Q&A - Python Output
  We’re using AlwaysUp to run a Python program as a service. Do you have any recommendations about logging?

Ideally I would see the output of the python program as if it were run in command line, to see the traceback if there is an error. For example:

    Traceback (most recent call last):
    File "", line 1, in 
    NameError: name 'r' is not defined

— Liam

Hi Liam. I see your problem. It’s important to know when Python runs into a problem, but errors can be difficult to spot when the service’s console — alive and well in the isolated Session 0 — isn’t visible on your desktop.

You have a couple of options:

1. Capture the output of your Python program in a text file

AlwaysUp can capture Python’s command line output to a file of your choosing. That option is available on the Extras tab:

Capture Output from the Extras tab

Check the Capture output to this log file box and enter the full path to a (new) text file.

If your script generates lots of text, you may want to prevent the file from growing too large. Check the Automatically trim box and specify the maximum size in megabytes. When the file grows to the maximum size, the oldest 10% will be discarded to make room for new entries. Be sure to tune the max size so that you don’t lose useful data.

With those settings in place, your Python service will write all console/traceback output to the file. Both the standard output and standard error streams will be captured.

Open the file to see what’s going on with your script. Or even better, use the free WinTail to “track” the file. New lines will appear in real-time — just if you were looking at the Python console.

To confirm our advice, we ran a Python script with a deliberate error (borrowed from this page) and captured the output. Here is the result (with WinTail monitoring the output file):

Python script: Traceback output

It works!

2. Run your Python script in the current session, where you will see the console

If you don’t want to configure logging — or you just want to see the console temporarily while debugging a problem — you can instruct AlwaysUp to run the Python console on your desktop.

Simply select Application > Restart in this session and AlwaysUp will temporarily stop Python and “re-parent” it onto your screen:

Restart Python program in this session

Your program will run visibly while you are logged in. When you logout, AlwaysUp will automatically return your application to the background (i.e. Session 0).

One final bit of advice…

We recommend that you do your best to thoroughly debug your Python script before running it as a set-it-and-forget-it Windows Service. Dynamic languages like Python need extra attention in that area.

The fewer surprises in production the better, right?

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

Q&A: How do I Rename my Application/Service in AlwaysUp?

Q & A - Rename AlwaysUp Application/Service
  I’m a long-time user of AlwaysUp. Can I rename a service?

— Bonnie

Hi Bonnie.

Unfortunately you can’t rename an application in AlwaysUp. This is because the underlying Windows Services API (which AlwaysUp employs to work its magic) simply does not support that operation. You can change many properties of a service — such as the login account, the startup type and the path to the executable — but not its name.

But all is not lost! You can use AlwaysUp’s “Add Copy” feature to implement a poor-man’s rename…

How to use “Add Copy” to rename your application/service

The basic idea is to duplicate your existing application, give it a different name and remove the original.

To do so:

  1. Highlight the entry you wish to rename in AlwaysUp. (We’ll work with Plex Media Server in this guide.)

  2. From the menu, select Application > Add Copy:

    AlwaysUp: Add Copy

    The familiar Add Application window will appear — containing a clone of the entry you highlighted.

  3. In the Name field, remove the default value (“Copy of…”) and enter the name you desire.

    We simply added a “NEW” prefix but your change will be more meaningful:

    AlwaysUp: Change Application Name
  4. Are you running your application in a specific user account? If so, switch to the Logon tab and enter the password for that Windows account:

    AlwaysUp: Set the Login Password

    You must do this because the “Add Copy” feature does not propagate any passwords — an important security precaution.

  5. And if you are using the email notification feature and have configured an email account with a password, you must re-enter that password as well.

    Switch to the Email tab, click the Configure button and type in your password:

    AlwaysUp: Set the Email Password
  6. We’re done making changes so click the Save button to record your new application. Here you can see our old and new entries, side-by-side:

    AlwaysUp: Copy Created
  7. And finally, delete the original application from AlwaysUp. You no longer need it since you have a new version with the correct name.

    Highlight the original, choose Application > Remove and confirm the prompt to complete the process:

    AlwaysUp: Remove the Original Application

That’s it! Apologies for the multiple steps, but that is the best we can do until Microsoft explicitly supports renaming a Windows Service.

As usual, please get in touch if you have any questions about the process.

Posted in AlwaysUp | Tagged , | Leave a comment

Q&A: Why Doesn’t AlwaysUp Catch my Endless Loop?

Q & A - Detect Infinite Loops
  Following your AlwaysUp documentation, I am using the “Monitor the application and stop it whenever it hangs” option. When I set its value to 1 minute, this feature does not work as I expect.

I wrote a simple application that goes into an endless loop after one minute of execution time. But the application is not restarted by AlwaysUp. Why not?

— Beatrix

Hi Beatrix. Not all infinite loops can be detected by AlwaysUp. Let me explain…

AlwaysUp catches non-responsive GUI applications

AlwaysUp’s hang detection feature is designed to identify a specific situation — where a Windows GUI application is not responding to the operating system.

We have all encountered this type of hang before. It happens when Firefox suddenly locks up, or when Excel goes gray and the cursor turns into a spinning wheel. The application is frozen and all input is ignored.

If you are lucky, the disruption only lasts a few seconds; if not, you may have to forcibly terminate the application from the Task Manager. Very annoying!

Beyond the gray window and spinning cursor, there are a couple of telltale signs when an application is hung/non-responsive:

  1. You will see “Not responding” in the application’s title bar.

    Outlook Not Responding
  2. The application’s process will be marked as “Not responding” in the Task Manager:

    Task Manager Process Not Responding

Furthermore, Windows may throw up a warning outlining your very limited options:

Excel Process Not Responding

The good news is that AlwaysUp has you covered in all of those situations!

How AlwaysUp checks if your application is hung

When you enable hang-checking, the AlwaysUp Windows Service component executes the following procedure every few seconds:

  1. Scans the desktop to identify all top-level windows belonging to the application being monitored.

  2. Sends each of those top-level windows a WM_NULL (no-op) message.

  3. Waits a few seconds for each of the windows to acknowledge the message.

  4. Declares the application a hang if no windows respond.

An application that remains hung over the user-supplied duration (1 minute, in your case) will be terminated and restarted.

Not all endless loops result in a frozen/non-responsive application

There are a couple of consequences stemming from the way that AlwaysUp checks for a hang.

First, an application without a top-level window can never be classified as a hang.

For example, this simple, non-GUI C# program that loops forever will escape detection:

using System;
namespace InfiniteLoop {
   class Program {
      static void Main(string[] args) {
         while (true) {

Second, if an application creates multiple windows, all windows must be non-responsive for AlwaysUp to declare a hang. If even a single window processes the WM_NULL message, the application will be classified as responsive.

My guess is that your endless loop test fits into one of the scenarios above. Unfortunately AlwaysUp’s hang detection feature will not be able to help there. Sorry about that!

But all is not lost…

Use the Sanity Check feature to detect endless loops and other failures

There can be many indications that a program is stuck. For example, an application might:

  • stop responding to requests over the network;

  • stop writing entries to a status file;

  • report an “I have failed” message to a log file;

  • or leave files collecting dust in a specific “inbox” folder

In situations like these — where the failure is detectable by a script or simple utility — you should look to AlwaysUp’s powerful Sanity Check feature. It allows you to extend failure detection to encompass anything you like, including the issues listed above.

The Sanity Check page digs into the technical details, which we will not repeat here. Please review the documentation and get in touch if you need help to use that flexible functionality.

Posted in AlwaysUp | Tagged , , , , | Comments Off on Q&A: Why Doesn’t AlwaysUp Catch my Endless Loop?

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_PRESHUTDOWN 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 , , , , , , | 2 Comments