Descriptions of some best practices when you create Windows Services

This article describes some common mistakes that you must avoid when you write a service. The article also suggests best practices to follow when you create Microsoft Windows Services. A Windows Service is a program, a routine, or a process that performs a specific system function to support other programs, particularly at a low (close to the hardware) level. Examples of Windows Services include server products, such as Microsoft Exchange and Microsoft SQL Server, and other client applications, such as Windows Timer that sets the computer clock. Windows Services are automatically started when you start the computer and do not have a user interface.

The following guidelines may be useful when you write a Windows Service:

• Design your service for use without a user interface. Service applications run outside any particular user context and should not require any user intervention. These applications typically perform tasks in the background. Design your service to run without any user intervention.
• Do not build interactive services. Run the service as an isolated service without user intervention.
  
  When the interactive user is logged into the same instance of Windows Services, window message attacks may occur. The interactive user may inject and run the arbitrary code in an interactive services process.
  
  If the interactive user sends a WM_COPYDATA message, copies malicious code into the address space of a highly privileged interactive service process, and then sends a WM_TIMER message, the service process runs the malicious code. This elevation of privilege attack may be carried out either by a user who has physical access to the computer or by a user who logs on the computer by using Microsoft Terminal Services.
• Remove all Assert statements before you ship your service. Microsoft does not recommend that you use the Assert method. The Assert method displays a dialog box that shows the line of code that failed, and then gives you the option to debug the code. Therefore, remove all the Assert statements before you ship your service.
• Run the service in a specific security context. To help secure your system from attacks, run the service with minimal user rights. If you require more user rights than those that are granted to the minimal user accounts, do not run the service as a user with administrative credentials.
  
  Also, do not change the security policy to elevate the user rights of the built-in logons (SYSTEM, Anonymous Logon, Local Service, and Network Service). Instead, create a custom account, and then grant the account the user rights that your service may require. If you require network credentials, use a domain account. If you do not require network credentials, use a local account. You may spend more time creating a custom account with limited user rights, but this is more secure than if you either run the service with too many user rights or when you add user rights to an account that is included with the operating system.
• Avoid using both printing and mapped drives in Windows Services. Printing and mapped drives are typically available to a particular user or a group of users. If you are using printing or mapped drives, make sure that your service runs under an account with the user rights that they must have to access printing or mapped drives. Typically, mapped drives disconnect when you log off and then reconnect when you log on to the computer.
• Avoid relying on user profile settings when you write Windows Services.

For more information about Windows Services, visit the following Microsoft Developer Network Web sites: