Windows Services Frequently Asked Questions (FAQ)

A Windows Service is an advanced component/feature of Microsoft Windows that supports the management of long running, background processes and applications.

Unlike regular programs that are started by a user and run only while that user is logged on, a Windows Service can start before any user logs on and can continue to run even after all users have logged off.

Windows Services are ideal for software that must start automatically when the computer boots.

A Windows Service is conceptually similar to a UNIX daemon.

You can manage Windows Services using the Windows Services control panel applet. To start the applet, either:

• Choose Start > Control Panel > Administrative Tools > Services; or
• Run "services.msc" from Start > Run...

The applet lists the Windows Services installed on your computer:

Double-click an entry to reveal its specific properties. Here's the "Schedule" service (which operates the Windows Task Scheduler):

You can start, stop, pause or resume the service as appropriate. You can also change the settings, such as the startup type (Automatic or Manual) or the log on account (on the Log On tab), etc.

Services are stored in the Windows Registry — a hierarchical key-value database that's an integral part of the operating system. You can access the registry using the Registry Editor (started by running the regedit command).

In the Registry Editor, you will find services under this key:

\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services

And each service will reside in a sub-key with its name.

For example, here are the settings for the Print Spooler service (which is named "Spooler"):

This 50-second video shows how to find the name of a Windows Service:

You can find the name of your service using the Windows Services control panel applet. To start the applet, either:

• Choose Start > Control Panel > Administrative Tools > Services; or
• Run "services.msc" from Start > Run...

The window that comes up lists all the Windows Services installed on your PC:

Find the service you're interested in and double-click the entry to open its specific properties. The service's name will be shown near the top of the Properties window. Here we can see that the name of the Print Spooler Windows Service is actually "Spooler":

Much like a regular application, a Windows Service can write its logs anywhere. Or it can choose not to write logs at all!

However, the convention is for services is to report errors, warnings and pertinent information to the Windows Event Logs. You can inspect those entries using the Windows Event Viewer.

To find the messages reported by a particular service:

1. Start the Event Viewer (from the Control Panel, or by running eventvwr.msc)

2. Navigate to the Windows Logs > Application section (on the left)

3. In the center panel, look for entries where the Source is the name of your service

For example, here is a message from the Volume Shadow Copy (VSS) service:

You can use the NET command to start and stop any Windows Service from a DOS prompt.

To start a service named "MyService", you would execute:

NET START MyService

To stop the same service, run:

NET STOP MyService

Be sure to enclose the service name in quotes if it contains spaces.

Note that only users with administrative privileges will be able to run the NET command.

To disable a service, use the SC command.

Run it like this:

SC config <Service-Name> start= disabled

where <Service-Name> is the name of the service. Be sure to enclose the name in quotes if it contains a space!

For example, to disable the Bluetooth Support Service (whose name is "bthserv"), run:

SC config bthserv start= disabled

Note that space after the "start=" is important. The command will fail if you omit it.

Also note that disabling a service will not stop it. Issue a NET STOP, either before or after disabling, to shut down the service.

Note: If you're not comfortable working from the command prompt, this short video shows how to disable a Windows Service using the Services GUI application:

You can delete a service with the SC command. Use it like this to remove a service called "MyService":

SC delete MyService

Enclose the service name in quotes if it contains spaces.

Beware: You can do serious damage to your operating system if you delete a critical service. Proceed with caution!

Most services are set to start automatically when Windows boots. These will show up with a Startup type of Automatic (or Automatic (Delayed Start)) in the Services application:

If starting at boot is not acceptable, you can change the Startup type to one of the following:

• Manual — The service should only start on demand, when explicitly requested to do so by a user (or by an application). This is the appropriate choice when you want to start and stop the service yourself.
• Disabled — The service cannot be started by any user or program. Choose this option to totally disallow the service from running. But be sure not to disable any important Windows Services!

Of course, deleting a service is another way to prevent it from running. But that's only recommended if you know what you're doing and can take full responsibility for the consequences!

Use the Windows Task Scheduler to create a scheduled task running the NET command to start/stop the service at a time of your choosing.

For example, suppose you have a backup that runs every Saturday from 8-10 PM and you wish to stop your service during that period. You would create two scheduled tasks — one to stop the service at 8 and another to start it at 10.

The task to stop the service would run this command:

NET STOP "service-name"

The task to start it up again would execute:

NET START "service-name"

In both cases, "service-name" is the name of your service as shown in the Control Panel Services application.

Follow this tutorial to create a scheduled task.

September 2022: Our new (and completely free) Service Scheduler utility will help you start, stop or restart your service whenever you like.

Simply choose your service, select the operation and set your time — that's it:

If you want to run a Windows Service in a user account — by specifying the account on the service's Log on tab — you should make sure that the account has the "Log on as a service" right. If not, the service will fail to start with a cryptic error like this:

To ensure that your user/account has the "Log on as a service" security policy enabled:

1. Run "secpol.msc" to start the Local Security Policy application.

2. In the left panel, navigate to Local Policies > User Rights Assignment.

3. You'll see the list of policies on the right sorted by name. Scroll down to find Log on as a service and double-click the entry to open its properties:

   

4. In the Log on as a service Properties window, click the Add User or Group button and enter your user account.

   We added Mike, who's an administrator on our machine:

   

5. Click OK to save your changes. You can close the Local Security Policy application as well.

For domain accounts, update the Group Policy too

Do you want your service to run in a domain account? Then you should grant the "Log on as a service" right in the Group Policy application as well. If not, you'll encounter the login failed error sometime in the future — after the group policy overwrites the local policy.

Follow the step-by-step instructions in this article to update the group policy.

Every Windows Service has an Access Control List (ACL) recording who's allowed to start, stop or restart it. Here are three ways to manipulate a service's ACL to grant or deny specific rights:

1. Use Service Security Editor a free point-and-click GUI tool for adjusting any service's rights. Simply select the service, identify the user, and specify the operations that he is allowed to perform.

2. Use the SC command line tool, as described in this tutorial. However working with SC can be very complicated, involving the composition of lengthy, hand-crafted command lines. It's not recommended for the faint-hearted!

3. Use the SubInACL command line utility, available for download from Microsoft and documented in Method 3 on this Windows Support page. It's easier to use than SC but still requires careful attention.

   For example, if you have a user called "MikeJones" in the "SANFRAN" domain that you want to start and stop the "Print Spooler" service, you would run:

   SubInACL.exe /service Spooler /GRANT=SANFRAN\MikeJones=TO

The SC command can set the dependencies on a given service. Use it like this:

SC CONFIG <service-name> depend= <service-1>[/<service-2>/.../<service-N>]

where <service-name> is the name of the service you wish to change, and <service-1> to <service-N> are the names of the dependent services. Note: The space after "depend=" is required, so don't forget it.

For example, to add the Windows Firewall as a dependency of the Google Update Service (so that the firewall is always running when updating Google's software), you would:

1. Open services.msc and find the service name of the Google Update Service. It's "gupdate".

   

2. Switch to the Dependencies tab and make a note of the services already there. Find their names. There is only one, the Remote Procedure Call service, named "RpcLocator". This is necessary because we don't want to lose the existing dependencies.

   

3. Find the name of the Windows Firewall service. It's "MpsSvc".

   

4. Use the SC command to update the dependencies of the Google Update Service to include the Windows Firewall service. The command line is:

   SC CONFIG gupdate depend= RpcLocator/MpsSvc

   Be sure to run it from an elevated command prompt:

   

5. Open the Google Update Service in services.msc and confirm that the dependencies have been updated:

   

You can change a service's description using the SC command. Call it like this:

SC DESCRIPTION [service-name] [new-description]

For example, to update the description of the Apache Windows Service (named "Apache2.4"), run:

SC DESCRIPTION Apache2.4 "An excellent open-source HTTP web server"

Administrative privileges are required to make this change so be sure to run the command from an elevated prompt.

While it may be tempting to fire up regedit.exe and directly modify the registry keys recording the service under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services, it's safer to use the SC command to change the executable invoked by the service.

To set the executable for a service named "MyService", you would run:

SC CONFIG MyService binPath= "<The full path to your executable>"

Note that the oddly placed space separating binPath= from the executable's path is actually required. Don't eliminate it!

And be sure to enclose the path in quotes if it contains a space.

There are a couple of options for exporting your services:

Option #1: Export to Text or CSV from the Services application

1. Start the services application (from the Control Panel or by running "services.msc");

2. Select Export List from the Action menu;

3. Specify a file name (and choose Text or CSV format) for the exported services.

The report will include the following values for each service: Name, Description, Status, Startup Type, Log On As. Here's what a CSV export looks like in Excel:

Option #2: Export to XML with Windows Service Auditor

1. Download Windows Service Auditor (it's free);

2. Start Windows Service Auditor;

3. Select Export (XML) from the All Services menu;

4. Specify a file name for the exported services.

The file will be in XML format, with a detailed record per service (including dependencies, recovery/failure options, triggers and more):

Yes, but not without employing the proper configuration and doing some extra work.

A mapped drive exists only in the account in which the mapping was created. Thus the LocalSystem account, the default for all window services, will not "see" any drives mapped into a regular, interactive user account.

Configuring your service to run in a specific user's account (via the Log On setting) has the potential to overcome the problem, but unfortunately persistent network connections are not restored by the service's non-interactive login. To access the drive by letter, your service must explicitly map the network drive by either:

1. Running the NET USE command (something like "NET USE W: \\server\folder" — no password should be necessary), or

2. Calling the WNetAddConnection2 API function if you can modify the code.

Note that a service can access the drive's underlying UNC path ("\\server\folder") without having to perform the steps above. Consider having your service work with the UNC path instead of the drive letter if you can.

Using a scheduled task to run your application or batch file may be superior to a Windows Service when:

1. You want to run at a few, fixed times each day, week or month.

   For example, a batch file that periodically deletes the contents of a temporary folder would be perfect as a scheduled task. Services are better suited for running 24/7.

2. You want to run whenever a user logs in, potentially bypassing the UAC prompt.

   A Windows Service doesn't provide that capability.

3. You don't need error reporting when your application or batch file fails to start.

   Errors from a Windows Service are reported to the Windows Event Log. Scheduled tasks aren't as good at capturing and reporting errors.

4. You don't need to start or stop your application manually.

   Services are easily started and stopped from the services control panel (or from the command line), but there is no such "console" to manage the ad-hoc execution of a scheduled task.

5. You don't need to start or stop your task from a remote machine.

   There is no equivalent of "SC \\Server START" and "SC \\Server START STOP" for a scheduled task.

6. You don't care about automatically restarting (or taking more elaborate actions) when your application crashes.

   The Task Scheduler doesn't offer any of the recovery options available to Windows Services.

In summary, a scheduled task is often better for periodic, maintenance-type chores that don't demand sophisticated control.

Yes, SC will happily install any exe file as a service. However, the executable will only start if it is a "true" Windows Service — one explicitly constructed to interface with the Windows Service Control Manager (SCM).

Regular, non-service executables will fail with error 1053 when you try to start them from the Services Control Panel.

If you want your service to access a user-specific ODBC data source (a "user DSN"), set the user's account on the service's Log On tab:

No. Windows Services can only exist on Windows operating systems.

UNIX implements long running daemons in a very different way.

The command prompt is a Windows application that accepts textual commands to control your computer. It's typically used by administrators and other technical users who are comfortable typing instructions instead of manipulating graphical applications.

You can start the command prompt by running CMD.EXE. Its distinctive window looks like this:

An elevated command prompt is a command prompt started with administrative rights.

With full rights, an elevated command prompt can run many administrative tasks, such as installing software, updating system files and manipulating Windows Services. A normal ("unelevated") command prompt cannot perform those privileged operations.

How to start an elevated command prompt

1. Click the Start button.

2. Type cmd.

3. After a few seconds, an entry for the command prompt (or cmd) should appear in the list of results. Right-click that entry and select Run as administrator:

   

4. Windows may prompt you to confirm that you want to run as an administrator. Click Yes to proceed:

   

The elevated command prompt window will appear on your desktop.

This short video shows you how to forcibly stop a stuck service:

A pending state usually means one of two things. Either:

• the service is working normally and is just taking a long time to complete a necessary operation, or
• the service has hung and is not interacting normally with the Windows Services Control Manager.

If you've waited long enough to rule out the first situation, then we have the second, and the only way to stop the service is to reboot the machine or end its underlying process. To terminate the process:

1. Find the process identifier (PID) of the Service's process using the SC command. For a Service named MyService, run:

   sc queryex MyService

   (Be sure to enclose the service name in quotes if it contains spaces.)

   Here's the result for the UI0Detect Service:

   

   Make a note of the number on the PID line (4388 in the screenshot above).

2. Run the taskkill command to forcibly terminate the process. For PID 4338, use:

   taskkill /F /T /PID 4388

   You should see a SUCCESS message if all went well:

   

   If you get "Access Denied", please ensure that you have the necessary administrative privileges by running the Command Prompt as an Administrator. (Darn UAC!)

Most Windows Services report information, warnings and errors to the Windows Event Logs, so start there. You can review those messages using the Windows Event Viewer Control panel application.

Windows Services will place their messages in the Windows Logs > Application section (on the left hand side). The Source column in the central window contains the name of the service reporting the event. Here's an information event reported by the Avira AntiVir service:

When a Service encounters a problem and cannot create a log entry, the Service Control Manager (SCM) will write an entry in the Windows Logs > System section. For example, here is the SCM telling us why the ActiveBooks service failed to start:

Hopefully the Event Log messages will shed some light on what is going wrong.

You probably need to specify an account that can run the application normally on the service's Log On tab:

By default, Windows runs your service in the LocalSystem account which may be very different from the account that you log in to. Your application will encounter trouble if it:

• Uses a printer or a network drive and LocalSystem doesn't have sufficient rights to use those devices;
• Has never been installed in the LocalSystem account and so cannot find its settings there;
• Needs to access registry values or environment variables in your "normal" account.

Specifying your normal account on the Log On tab should solve those kind of problems.

There can be many reasons why a service doesn't start automatically as expected. Check the Windows Event Log to see if you can find out what happened as the OS booted up.

The most common problems include:

1. The service has the wrong password. Update the password on the service's Log On tab and you should be good to go.

2. A dependent service fails to start. Determine why the dependent service is failing and resolve the issue. Or if that doesn't work, try to remove the dependency — as long that won't compromise your system.

3. The service logs on as a domain user and it's starting before Active Directory is ready. Set your service's Startup type to Automatic (Delayed Start) to give AD time to spin up and log you into the account you've specified.

4. A required resource is unavailable at boot. For example, if your service uses a database but the database is not yet fully initialized when your service starts, the service may quickly shut down. Check your service's log files for errors and add dependencies on any other critical services that are needed for support. Setting your service to start Automatic (Delayed Start) to give other components more time to start up in advance may also resolve the issue.

5. The service is missing its executable or important DLLs. Check that the service's executable is present and that all necessary DLLs and other files are in place. Use the excellent Dependency Walker utility to identify missing components, and keep mind that re-running your service's installer may help by restoring missing files.

The Stop button is unavailable when the service is busy and unable to accept a request to stop. If the service is off doing its work, simply waiting some time for it to complete its pending tasks may resolve the situation. As they say, patience is a virtue.

However, if you've waited a while and the problem persists, your service may be stuck. You can try to forcibly terminate the service's underlying executable using TASKKILL (or via the Task Manager), but this may not be a viable option when the process is hosting many services (like Microsoft's svchost). In that second situation a reboot may be your only recourse.

You cannot start a disabled service. Not with NET START, SC START or even via the Services application.

To start the service, you must "un-disable" it first. That is, you must set its Startup type to Manual, Automatic or Automatic (Delayed). That is best done via the Services application (services.msc):

You should be able to start the service once you've made that change.

Note that you can also re-enable your service from the command line using the SC command. Run:

SC config <Service-Name> start= demand

where <Service-Name> is the name of the service.

Replace "demand" with "auto" to have Windows start the service automatically at boot (instead of manually, on demand).

Nothing. No new features were introduced in the original release of Windows Server 2008. There were a few changes for Server 2008 R2 though.

Microsoft made significant adjustments to Windows Services in Vista. The main changes are:

• Session 0 is now "isolated" and no user can log in there to interact with the GUI from a Service. This change — effected primarily for security concerns — makes it much more difficult to work with GUI-based Windows Services. The situation is discussed in the "Can a Windows Service have a GUI?" entry below.

• In an attempt to reduce resource contention as the computer boots, services that should be started at boot now have the option of being delayed and starting shortly after boot. In practice, this means delaying service startup by 1-2 minutes — quite appropriate for some services.

  The new setting is available in the Startup type field — Automatic (Delayed Start):

  

The complete technical details are available in this article from Microsoft Developer's Network.

The adjustments made in 2009 were highly technical and not very visible to end users. Only the following is of note:

• Services can be automatically started or stopped in response to one or more Trigger events. Trigger events include:

  • A specific device (e.g. memory stick) arrives or is present when the system starts
  • A given port is opened or closed
  • A machine or user policy changes
  • The first IP address becomes available or the last IP address becomes unavailable
  Microsoft doesn't provide a GUI for managing triggers so you must use the SC command (or the free Service Trigger Editor).

The complete technical details are available in this article from Microsoft Developer's Network.

Not much. The few, highly technical adjustments were entirely "under the hood":

• A service can retrieve information on how it was started
• Services can be notified when a user initiates a reboot
• Three new service triggers were introduced, but they are merely placeholders awaiting definition from Microsoft

There were no user interface changes.

A Session (also known as a Logon Session) is created whenever a user logs in to Windows. Each session has a numeric identifier, called a Session ID.

Windows creates a single session when your PC boots and all the Windows Services (and many other administrative processes) will run in that session. Since the ID of that session is 0, it's been nicknamed Session 0.

On legacy versions of Windows (NT, 2000, XP and Server 2003), the first user to log into the physical PC is automatically placed into the already created Session 0. An RDP/Terminal Services user can log in to Session 0 by specifying a special flag when opening the connection (/admin). And once in Session 0, a user can see and interact with the graphical elements of any program running there, including those created by Windows Services. In this way, Microsoft (perhaps inadvertently?) allowed users to freely interact with Windows Services that choose to display a user interface.

Ultimately, Microsoft realized that allowing users to interact with Windows Services could lead to security problems. Indeed, a virus installing itself as a service running from a high privilege account could easily wreak havoc on a user's desktop.

Microsoft's solution is to prohibit users from logging in to Session 0. Now, the first user creates Session 1, the second Session 2, etc., and there is simply no way to access Session 0 via login. This policy — introduced in Windows Vista in 2006 — is known as Session 0 Isolation. It's described in great detail in this technical document from Microsoft.

Session 0 Isolation is enforced in all current versions of Windows.

In earlier versions of Windows, you can switch to Session 0 from the command line by running:

rundll32.exe winsta.dll,WinStationSwitchToServicesSession

Save one of these files to your desktop to easily access Session 0 on demand:

• Batch file to switch to session 0
• Shortcut to switch to session 0

Note that the Interactive Services Detection service (UI0Detect) must be running for switching to work.

In older versions of Windows (NT, 2000, XP and Server 2003), services are allowed to show their windows and tray icons on the desktop of the user logged on to the PC. This ability was enabled by checking the Allow service to interact with desktop option in the service's Log On properties:

Although that setting still exists on Windows 11/10 or Server 2022/2019/2016, it no longer has the desired effect. That's because Microsoft's security-centric Session 0 Isolation modifications ensure that no user can log on to Session 0 — the desktop where the windows created by a service are displayed.

So while checking the Allow service to interact with desktop box still enables the service's windows to be displayed in Session 0, since no one can log in to Session 0 to see the service's windows, the setting has been effectively marginalized.

Sometimes it makes sense to launch an application on the isolated Session 0. For example, does the application work properly when launched in the context of a Windows Service?

Microsoft's advanced "process-launcher" utility, PsExec, will start any program in Session 0. Use it like this:

psexec -i 0 -s <executable>

where:

<executable> is the full path to the program to run,
-i 0 indicates to start the process interactively in Session 0, and
-s runs the process in the system account. (Optional — omit it to run the process with your own credentials.)

For example, this line will start the command prompt in the system account in Session 0:

psexec -i 0 -s C:\Windows\System32\cmd.exe

Services configured to start Automatic will be immediately kicked off by Windows as the machine boots up. In contrast, those set to Automatic (Delayed Start) will be held back from that first wave and will start 2 minutes after the last Automatic service is launched.

The setting is most useful in two respects:

1. It can alleviate the "mad rush" at boot, when all services try to start simultaneously. By designating non-critical services for a delayed start, the really important services can secure a larger slice of the machine's precious resources and become available sooner.

2. It can delay a service from starting until other critical supporting services are operational. For example, without the delay it's possible for a service to start before the network is fully initialized, leading to very strange problems.

By default, services designated as "Automatic (Delayed start)" start 2 minutes after the last "Automatic" service is launched. That delay can be adjusted for all services by changing (or adding) the AutoStartDelay (DWORD/REG_DWORD) value in the registry:

HKLM\SYSTEM\CurrentControlSet\Control\AutoStartDelay

The value is in milliseconds.

For example, this screenshot shows us setting a 10 minute (600000 millisecond) delay:

Please keep in mind that this setting applies to all delay-start services. Use it with caution!

Instead of starting automatically at boot or manually (on demand), a service can be configured to start (or stop) in response to specific operating system events. A service starting from an event is called a Trigger Start Service.

Trigger Start Services were introduced in Windows 7 and Server 2008 R2 (in 2009). They were created to improve efficiency and speed up the boot process after Microsoft realized that many of the 100+ services set to start automatically at boot and run 24/7 in the background didn't really need to be active all the time. The trigger mechanism was put in place to encourage services to remain dormant until needed.

Looking at the Services application on our Windows Server 2019 machine, there are more than 60 Trigger Start Services installed. Each says Automatic (Trigger Start) or Manual (Trigger Start) in the Startup Type column. Here are a few:

Strangely, you won't see any mention of a trigger when you examine a Trigger Start Service's properties. The Startup type simply says "Automatic" or "Manual" and there are no trigger settings to be found anywhere (as seen with the DNS Client service):

Use Service Trigger Editor to examine and manage Trigger Start Services. Our free utility shows you what events start or stop the service, allow you to add other triggering events, and much more.

Here's Service Trigger Editor working with the DNS Client service:

Error 5 denotes a lack of permissions. Your Windows account doesn't have the rights necessary to work with the service.

Windows will usually inform you where your account falls short. For example, you may not be able to start the service:

Or you may not be able to open the service:

In any case, your only recourse is to seek extra rights for your account. Your systems administrator (or our free Service Security Editor utility) should be able to help.

This error comes up about 30 seconds after an attempt to start the service, because the service fails to report to the Windows Service Control Manager (SCM) that it's started. You're probably facing one of the following problems:

1. The application being launched by the service is not a true Windows Service. Only an executable specifically constructed to interact with the SCM can signal that it's started and is running properly. A non-service application — such as a batch file or program you normally launch from a desktop icon — will not send the required signal and eventually the SCM will give up waiting and declare that the service failed to start.

   If you're unable (or unwilling) to modify your application's code to make it a true Windows Service, you can use a "wrapper" to start your application as a service. Microsoft's Srvany will do the basic job for free but more robust commercial alternatives are also available.

2. Your Windows Service application is taking too long to start and report back to the SCM. If you have access to the code, restructure the application logic to move expensive operations (such as accessing a database, web site or other remote resource) outside of the startup sequence (OnStart() in C# programs).

3. Your Windows Service application is getting hung during startup and never tells the SCM that it's started. If this is your own code, it's time to debug! Either attach the debugger, or sprinkle your startup code with print statements to see where your application is going astray. Watch out for calls to MessageBox() and other blocking functions!

This mysterious message comes up when a service is unable to perform the operation you attempted. Essentially, your request arrived at a "bad time", when the service is unable to fulfill it.

At any given time, the operations a service can perform depend on its current state — what it's doing. For example, a running service may accept the Stop command but not the Pause or Resume commands.

To determine what is allowed, Windows asks a service the following question: What operations can you currently perform? The service responds with a list of what it can do.

You encounter Error 1061 when you try to perform an action that's not on the list of allowed operations.

This error occurs when the process created by the service exits quickly, without notifying the Windows Service Control Manager (SCM). It can happen for a variety of reasons, including:

1. There is a configuration problem preventing the service application from starting properly. Check that configuration files are in the expected locations with valid contents, and that startup options reflect reality.

2. The process being launched by the service is missing a required component (DLL, library, or other file). Re-installing the service may help here, but watch for dependencies as well. For example, a C# service will fail with 1067 when the underlying .NET installation is corrupt and should be re-installed.

If you remain in the dark after considering the above, examine the Windows Event Logs. Sometimes a failing service will leave an important clue there before it dies.

Apparently your service relies on other services to support its work, and one of those services is unable to start properly. You can identify the dependent services in the Services Control panel:

Rule out the ones already running; try to start each of the others in turn and identify the culprit.

This error happens when your service is configured to run in a specific user account but that account's password was recently changed. The fix is simple; edit your service in services.msc and specify the new password on the service's Log On tab:

This error happens when your service has been uninstalled but Windows was unable to remove all its associated files because of a conflict.

Usually it's caused by having the service open in a service-aware program, like the Services Control Panel, the Windows Event Viewer, or even the Windows Task Manager. Closing all those applications may be enough to have the service fully removed, but if that doesn't work a reboot should do the trick.

Srvany is a utility developed by Microsoft that can start almost any regular, non-service application as a Windows Service.

Since a Windows Service must be specially constructed to interface with the operating system (to allow Windows to start, stop or pause it on demand), a regular application without this interface will not function properly as a Service. To solve the problem, Microsoft developed Srvany — an "adapter" (or "wrapper") that can accept the Windows Service commands and translate those into actions that a regular executable can understand.

Like any good adapter, Srvany is installed between Windows and the application and handles all interaction between them. For example, when Windows says "Start the service", Srvany intercepts the request and starts the application as if you had double-clicked on it yourself.

Srvany was developed in the late 1990's for Windows NT and remains mostly unchanged to this day. It's available as part of the Windows Server 2003 Resource Kit Tools package.

Instsrv is a Microsoft-developed utility used to install a Srvany Service. It doesn't take part in the actual running of an application as a service — it just helps with the installation.

The most recent version of Srvany and Instsrv are freely available as part of the Windows Server 2003 Resource Kit Tools package.

Microsoft's How To Create a User-Defined Service article describes how to install an application as a Windows Service.

No. Srvany and Instsrv were last released with Windows Server 2003 and no modifications have been made for Windows 7, Vista, Server 2008 or Server 2008 R2.

Note that these tools will work fine on Windows 2008 and Windows 7, but their lack of knowledge of recent developments in Windows Services (Session Zero isolation, Service Triggers, etc.) can sometimes present problems. Please be cautions in a production environment!

No. While Srvany.exe runs fine on Windows Server 2008/R2, Srvany (and the rest of the Windows Server 2003 Resource Kit Tools) are only supported on Windows Server 2003 and Windows XP. And even then, the official documentation accompanying the resource kit cautions:

The SOFTWARE supplied in the Windows Resource Kit Tools is not supported under any Microsoft standard support program or service.

No. While Srvany.exe runs fine on Windows Server 2012 (and its R2 variant), Srvany (and the rest of the Windows Server 2003 Resource Kit Tools) are only supported on Windows Server 2003 and Windows XP. And even then, the official documentation accompanying the resource kit cautions:

The SOFTWARE supplied in the Windows Resource Kit Tools is not supported under any Microsoft standard support program or service.

No. While Srvany.exe runs fine on Windows 10 and Server 2019, Srvany (and the rest of the Windows Server 2003 Resource Kit Tools) are only supported on Windows Server 2003 and Windows XP. And even then, the official documentation accompanying the resource kit cautions:

The SOFTWARE supplied in the Windows Resource Kit Tools is not supported under any Microsoft standard support program or service.

No. Even though the 32-bit executable runs fine on 64-bit versions of Windows, Srvany (and the rest of the Windows Server 2003 Resource Kit Tools) are not officially supported on 64-bit platforms. There is no 64-bit version of Srvany.exe.

Yes, but somewhat abruptly.

Instead of sending the usual WM_CLOSE or WM_QUIT messages to gracefully shut down the application, Srvany will forcibly terminate it. This can be quite disruptive, as highlighted in the old Srvany documentation (Srvany.wri, included with the original Windows NT 4.0 resource kit):

"WARNING: When the service is stopped, it terminates the application via the WIN32 TerminateProcess() API: this is a drastic way to end an application. For example, it would not allow the application to prompt the user to save changes. Therefore, it's recommended to close the application BEFORE stopping the service."

A service created with Srvany is much like any other and you can remove it using the SC command.

The service can also be removed using the Instsrv utility. Run it like this:

Instsrv MyService remove

Unfortunately, no. Srvany doesn't monitor your application in any way and will not run a new copy if it fails.

Indeed, Srvany may continue to run even after your application exits! You can't rely on the service's status to tell you if your application is up or not.

Yes, you can install as many Srvany-created services as you like — each with its own unique name of course! Even though each service will reference the same Srvany.exe file, each service will run entirely independently and can be managed as such.

That's not a "Srvany thing" — by default, Windows Services do not have access to mapped drive letters. UNC paths (which look like "\\Server\Path") should be fully accessible, but if using them is not an option this answer discusses some ways to make mapped drives available in the context of a Windows Service.

Can it? Yes.

Should it? No.

But things are never that black and white...

First, realize that the Windows Services architecture doesn't impose any GUI-related restrictions on a service. Services are free to create windows, tray icons, alert boxes or any other GUI elements, just like conventional windows applications can. The key question is this: When a service creates a window, where will it be shown?

By default, the GUI elements from a Service appear in Session 0 — the session/desktop created by Windows when your PC boots. A user logging in to Session 0 can see the windows from a Service and interact with them normally. Interactive services "just work" there.

On Windows 2000, XP and Server 2003, the first non-remote user to log in to the PC was placed in Session 0. If you walked up to the keyboard and mouse and logged in, you would almost surely end up in Session 0. Remote users could log in to Session 0 by starting the Remote Desktop application with the "/admin" flag. For those users, interactive services worked as expected and many Windows programs were architected to take advantage of that.

However, Microsoft changed the playing field for interactive services in Windows Vista (2007). Session 0 has been "isolated", and no user can log in there. (This was done mainly for security concerns — a virus infecting a service could force itself onto any user's desktop, which the folks at Redmond recognized as a security risk.) The upshot is that the windows from a Service will no longer show up on any user's desktop, effectively dealing a death blow the entire notion of interactive services.

Realizing that it would be difficult to do away with interactive services by decree however, Microsoft made several concessions to keep interactive services on life support. The Interactive Services Detection Service (ISDS) was introduced to alert a user whenever a service shows a window or message box on Session 0. After flashing a few times on the task bar, the window it displays looks like this:

Clicking on the View the message button initiates a gut wrenching transition from the normal desktop to the very strange looking world of Session 0 where the Service's windows are running (Notepad.exe in this case):

Despite the austere appearance, you can interact normally with your service's windows in Session 0. And when you're done, clicking on the Return now button will magically transport you back you to your regular desktop.

It's easy to see that most users would be inconvenienced by always having to perform such an awkward switch to Session 0 to interact with an application. This effectively limits the attractiveness of an interactive service and any sane computer professional will certainly recommend against constructing one today.

Yes, a service can definitely launch a GUI application.

However, that application will run in Session 0 — the background desktop where services reside. You will not see the application on your desktop.

Attempting to start the Interactive Service Detection (UI0Detect) service on Windows 8 and Windows Server 2012 can fail with the incomprehensible "Error 1: Incorrect function" message:

This is because Microsoft has disabled interactive services in these new operating systems!

Fortunately, it's easy to re-enable interactive services by editing the registry:

1. Start the registry editor ("regedit.exe")
2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Windows on the left side
3. On the right, double-click the NoInteractiveServices entry and change its value from 1 to 0
4. Click OK to record your change
5. Close the registry editor

The Interactive Service Detection service should start properly after this change.

There are three ways to prevent the Interactive Services Detection Dialog from alerting you of a GUI application running in Session 0. All involve stopping the Interactive Services Detection (ISD) service, which runs in the background and summons the ISD dialog whenever it detects activity in Session 0:

1. Stop the Interactive Services Detection Service

   Simply stopping the service will cause the dialog to disappear. This may not be a permanent fix though; the dialog may return if someone else (or another application) restarts the service.

   To stop the service, run "services.msc", right-click on the Interactive Services Detection entry in the list and select Stop from the menu:

   

2. Disable the Interactive Services Detection Service

   By changing the service's startup type to Disabled, you will ensure that no person (or application) can start the service. The dialog will never be shown.

   To disable the service, run "services.msc", double-click on the Interactive Services Detection entry in the list and change the Startup type to Disabled:

   

3. Set the NoInteractiveServices registry key

   When it starts, The ISD service checks the NoInteractiveServices registry key. If the value is 1, the service will refuse to start, and you will never see the ISD dialog.

   Follow these instructions to set the NoInteractiveServices registry key — just set the DWORD value to 1 instead of 0.

Note that the Interactive Services Detection service also provides the ability to switch to Session 0 to view your Session 0 desktop. Switching to Session 0 will not be available when the ISD service is not running!

Unfortunately access to Session 0 has been removed in Windows 10 and Server 2019. And it's not coming back!

Note that services and applications continue to run as normal in Session 0 — you just can't see them.

This article digs into the technical details.

Of course! Please contact us via email or phone and we will get back to you ASAP.