{
	"id": "124456ac-1d3b-4ed4-b4af-65ec3bdefb35",
	"created_at": "2026-04-06T00:18:02.87738Z",
	"updated_at": "2026-04-10T03:20:32.158392Z",
	"deleted_at": null,
	"sha1_hash": "e166f7a9b81f91ea6609c3ca1f42d050d169f172",
	"title": "Introduction to Windows Service Applications - .NET Framework",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 63230,
	"plain_text": "Introduction to Windows Service Applications - .NET Framework\r\nBy gewarren\r\nArchived: 2026-04-02 10:58:35 UTC\r\nMicrosoft Windows services, formerly known as NT services, enable you to create long-running executable\r\napplications that run in their own Windows sessions. These services can be automatically started when the\r\ncomputer boots, can be paused and restarted, and do not show any user interface. These features make services\r\nideal for use on a server or whenever you need long-running functionality that does not interfere with other users\r\nwho are working on the same computer. You can also run services in the security context of a specific user\r\naccount that is different from the logged-on user or the default computer account. For more information about\r\nservices and Windows sessions, see the Windows SDK documentation.\r\nYou can easily create services by creating an application that is installed as a service. For example, suppose you\r\nwant to monitor performance counter data and react to threshold values. You could write a Windows Service\r\napplication that listens to the performance counter data, deploy the application, and begin collecting and analyzing\r\ndata.\r\nYou create your service as a Microsoft Visual Studio project, defining code within it that controls what commands\r\ncan be sent to the service and what actions should be taken when those commands are received. Commands that\r\ncan be sent to a service include starting, pausing, resuming, and stopping the service; you can also execute custom\r\ncommands.\r\nAfter you create and build the application, you can install it by running the command-line utility InstallUtil.exe\r\nand passing the path to the service's executable file. You can then use the Services Control Manager to start,\r\nstop, pause, resume, and configure your service. You can also accomplish many of these same tasks in the\r\nServices node in Server Explorer or by using the ServiceController class.\r\nService Applications vs. Other Visual Studio Applications\r\nService applications function differently from many other project types in several ways:\r\nThe compiled executable file that a service application project creates must be installed on the server\r\nbefore the project can function in a meaningful way. You cannot debug or run a service application by\r\npressing F5 or F11; you cannot immediately run a service or step into its code. Instead, you must install\r\nand start your service, and then attach a debugger to the service's process. For more information, see How\r\nto: Debug Windows Service Applications.\r\nUnlike some types of projects, you must create installation components for service applications. The\r\ninstallation components install and register the service on the server and create an entry for your service\r\nwith the Windows Services Control Manager. For more information, see How to: Add Installers to Your\r\nService Application.\r\nhttps://docs.microsoft.com/en-us/dotnet/framework/windows-services/introduction-to-windows-service-applications\r\nPage 1 of 4\n\nThe Main method for your service application must issue the Run command for the services your project\r\ncontains. The Run method loads the services into the Services Control Manager on the appropriate\r\nserver. If you use the Windows Services project template, this method is written for you automatically.\r\nNote that loading a service is not the same thing as starting the service. See \"Service Lifetime\" below for\r\nmore information.\r\nWindows Service applications run in a different window station than the interactive station of the logged-on user. A window station is a secure object that contains a Clipboard, a set of global atoms, and a group of\r\ndesktop objects. Because the station of the Windows service is not an interactive station, dialog boxes\r\nraised from within a Windows service application will not be seen and may cause your program to stop\r\nresponding. Similarly, error messages should be logged in the Windows event log rather than raised in the\r\nuser interface.\r\nThe Windows service classes supported by the .NET Framework do not support interaction with interactive\r\nstations, that is, the logged-on user. The .NET Framework also does not include classes that represent\r\nstations and desktops. If your Windows service must interact with other stations, you will need to access\r\nthe unmanaged Windows API. For more information, see the Windows SDK documentation.\r\nThe interaction of the Windows service with the user or other stations must be carefully designed to include\r\nscenarios such as there being no logged on user, or the user having an unexpected set of desktop objects. In\r\nsome cases, it may be more appropriate to write a Windows application that runs under the control of the\r\nuser.\r\nWindows service applications run in their own security context and are started before the user logs into the\r\nWindows computer on which they are installed. You should plan carefully what user account to run the\r\nservice within; a service running under the system account has more permissions and privileges than a user\r\naccount.\r\nService Lifetime\r\nA service goes through several internal states in its lifetime. First, the service is installed onto the system on which\r\nit will run. This process executes the installers for the service project and loads the service into the Services\r\nControl Manager for that computer. The Services Control Manager is the central utility provided by Windows\r\nto administer services.\r\nAfter the service has been loaded, it must be started. Starting the service allows it to begin functioning. You can\r\nstart a service from the Services Control Manager, from Server Explorer, or from code by calling the Start\r\nmethod. The Start method passes processing to the application's OnStart method and processes any code you have\r\ndefined there.\r\nA running service can exist in this state indefinitely until it is either stopped or paused or until the computer shuts\r\ndown. A service can exist in one of three basic states: Running, Paused, or Stopped. The service can also report the\r\nstate of a pending command: ContinuePending, PausePending, StartPending, or StopPending. These statuses\r\nindicate that a command has been issued, such as a command to pause a running service, but has not been carried\r\nhttps://docs.microsoft.com/en-us/dotnet/framework/windows-services/introduction-to-windows-service-applications\r\nPage 2 of 4\n\nout yet. You can query the Status to determine what state a service is in, or use the WaitForStatus to carry out an\r\naction when any of these states occurs.\r\nYou can pause, stop, or resume a service from the Services Control Manager, from Server Explorer, or by\r\ncalling methods in code. Each of these actions can call an associated procedure in the service (OnStop, OnPause,\r\nor OnContinue), in which you can define additional processing to be performed when the service changes state.\r\nTypes of Services\r\nThere are two types of services you can create in Visual Studio using the .NET Framework. Services that are the\r\nonly service in a process are assigned the type Win32OwnProcess. Services that share a process with another\r\nservice are assigned the type Win32ShareProcess. You can retrieve the service type by querying the ServiceType\r\nproperty.\r\nYou might occasionally see other service types if you query existing services that were not created in Visual\r\nStudio. For more information on these, see the ServiceType.\r\nServices and the ServiceController Component\r\nThe ServiceController component is used to connect to an installed service and manipulate its state; using a\r\nServiceController component, you can start and stop a service, pause and continue its functioning, and send\r\ncustom commands to a service. However, you do not need to use a ServiceController component when you create\r\na service application. In fact, in most cases your ServiceController component should exist in a separate\r\napplication from the Windows service application that defines your service.\r\nFor more information, see ServiceController.\r\nRequirements\r\nServices must be created in a Windows Service application project or another .NET Framework–enabled\r\nproject that creates an .exe file when built and inherits from the ServiceBase class.\r\nProjects containing Windows services must have installation components for the project and its services.\r\nThis can be easily accomplished from the Properties window. For more information, see How to: Add\r\nInstallers to Your Service Application.\r\nSee also\r\nWindows Service Applications\r\nService Application Programming Architecture\r\nHow to: Create Windows Services\r\nHow to: Install and Uninstall Services\r\nHow to: Start Services\r\nHow to: Debug Windows Service Applications\r\nWalkthrough: Creating a Windows Service Application in the Component Designer\r\nhttps://docs.microsoft.com/en-us/dotnet/framework/windows-services/introduction-to-windows-service-applications\r\nPage 3 of 4\n\nHow to: Add Installers to Your Service Application\r\nSource: https://docs.microsoft.com/en-us/dotnet/framework/windows-services/introduction-to-windows-service-applications\r\nhttps://docs.microsoft.com/en-us/dotnet/framework/windows-services/introduction-to-windows-service-applications\r\nPage 4 of 4",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://docs.microsoft.com/en-us/dotnet/framework/windows-services/introduction-to-windows-service-applications"
	],
	"report_names": [
		"introduction-to-windows-service-applications"
	],
	"threat_actors": [],
	"ts_created_at": 1775434682,
	"ts_updated_at": 1775791232,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/e166f7a9b81f91ea6609c3ca1f42d050d169f172.pdf",
		"text": "https://archive.orkl.eu/e166f7a9b81f91ea6609c3ca1f42d050d169f172.txt",
		"img": "https://archive.orkl.eu/e166f7a9b81f91ea6609c3ca1f42d050d169f172.jpg"
	}
}