Windows Insider

Get Under the GUI

Windows NT is essentially a collection of interrelated services. Here’s how to explore the higher-level services to demonstrate their relationships to each other.

• By Michael Chacon
• 11/01/1998

Last month I discussed low-level system process components and some of the tools in the NT Server Resource Kit that help you understand these operating system services. In this column we’ll continue with the discussion.

These low-level system components—the messenger, browser, alerter, and so on—lay the foundation for the operating system to provide services that most administrators understand and know how to support. First, the low-level processes are initialized, and then the Winlogon process authenticates the user and launches the USERINIT.EXE process. In turn, the Userinit process reads the registry configuration for that user and launches the default graphical shell process called the Explorer. The Explorer provides the context for the users to interact with the operating system.

You can see this relationship in the Winlogon registry key shown in Figure 1. Userinit launches the Explorer process and then closes down. Any process subsequently created through the shell (in most cases this process is the Explorer) is within the context of the interactive user. Consequently, it has that user’s token associated with it. This determines which system resources the process will be able to access and which system operations it can perform. The hierarchy in the TLIST displayed in Figure 2 is misleading because it shows the Explorer at the same level in the hierarchy as the System process (which I also discussed last month). This hierarchy is displayed as such because the service that calls the Explorer has closed down.

The processes listed below Explorer are user-mode applications that run under the interactive token context, such as the Windows NT Task Manager, Microsoft Word (which I’m using to write this), and the command prompt that ran TLIST. The Explorer process should reside two levels below Winlogon as the child of Userinit, which is sibling to Services, LSASS, and NDDEAGNT. NDDEAGNT handles users’ dynamic data exchange requests across the network during client/server communication. LSASS is used for the security authentication procedure that I discussed last month.

The Services process is the foundation for higher-level Windows NT services, such as Workstation, Browser, and Dynamic Host Configuration Protocol (DHCP). The DHCP service automatically distributes IP addresses so administrators don’t have to manually edit the configuration files in each machine. Before looking further at SERVICES.EXE, however, let’s examine what a service is and how it differs from an application.

Service Defined

A Windows NT service consists of three main components. The first component is the service itself. A service is a special Win32 program that provides specific functionality that extends the scope of the operating system. A program becomes a service when it’s able to be managed by and report its status to the Service Control Manager (SCM). Another characteristic of a service is that they usually run in a detached mode and don’t interact with the desktop. This means that although they often run in user mode, they don’t need an interactive logon. Instead, they can use the context of the System Account to run behind the scenes regardless of whether a user is logged onto the system or not. When a user logs on, the services are already running and ready to provide a benefit to the interactive account or even to a user across the network.

Even though services can run in the System Account context, this can create problems if the service needs to access resources across the network. Although services can provide benefits to processes running remotely, the System Account only has privileges on the local machine. This is why many services, particularly those providing functions for BackOffice applications such as SMS and Exchange, use a standard user account that has the privilege to log on as a service. Using a regular authenticated token-bearing account allows a service to access resources such as shares and disk drives across the network. This is useful for services such as the Message Transfer Agent found in e-mail systems.

Figure 1. The Winlogon process in the Windows NT Registry Editor obtains initialization information for the registry key.

The second component of an NT service is the SCM, which is built into every NT system and runs automatically when the system boots. The SCM is an RPC server process that runs with System Account privileges. It provides a central and secure method for controlling NT services. The SCM communicates with all of the Windows NT services on the system, directing them to start, stop, pause, or continue, and supplying them with configuration information.

The third component is a Service Control Program (SCP). An SCP provides a user interface to the SCM. Because most services interact only with the SCM and not the user, there needs to be a way to configure how the services will be controlled by the SCM.

Figure 2. Running TLIST gives you a display of the system process hierarchies.

The most obvious SCP is the Services Control applet. Most administrators use this applet to tell the SCM to run a particular service automatically at startup, disable it, or leave it in manual mode for another process to initialize when needed. Many BackOffice application services function in this manner. This is also where a seperate account can be assigned to a particular service.

Another SCP tool is the NET.EXE command that can be used to list, start, and stop services on a local machine. The Windows NT Server Manager is an SCP that lets administrators control services on remote machines using the RPC client/server architecture of SCM.

Starting Services

Services are started by the SCM. The information that the SCM needs in order to control a service is located in the SCM database in the registry under the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services key. Under normal circumstances, neither applications nor users should make changes to this key. Instead, the services setup program acts as an SCP that communicates with the SCM to make the entries into its database. Although it may sound inefficient, this method ensures that the SCM maintains the integrity of the database, particularly with regard to dependencies. Most services will create an SCP applet for communicating with the SCM. This applet is stored either in the Control Panel or within the Network applet.

As with all applications, a service is a process that runs in its own memory space. While this is great for an application that consumes vast amounts of dynamic resources, many services are simple and won’t need the extra space. To maintain operating system efficiencies, some services share the same process by being included in the same program file image. This is the case with the SERVICES.EXE program. In addition to being the home of the SCM, SERVICES.EXE also includes such fundamental Windows NT services as Alerter, Browser, DHCP Client, Event Log, Messenger, NTLM Security Support Provider, Plug and Play, Server, TCP/IP NetBIOS Helper, and Workstation.

Figure 3. This Registry Editor entry shows that the executable for the Workstation service is SERVICES.EXE.

You can see what the executable is for a particular service by looking in the SCM database in the registry, as described earlier. For example, Figure 3 shows the entry for the Workstation service.

As you can see in Figure 3, the program image for the Workstation service is SERVICES.EXE, but it’ll be displayed as Workstation when the SCM is queried.

You can also view these relationships using an SCP tool provided in the Windows NT 4.0 Resource Kit. The tool, called SC.EXE, lets you communicate with the SCM directly. SC.EXE is a command-line program that displays its options when you enter the SC command by itself, as shown in Figure 4.

Figure 4. SC.EXE lets you communicate directly with the SCM. When you enter the SC command by itself, SC.EXE displays its options.

You have much more flexibility with SC.EXE than with the Control Panel or NET.EXE. Using this SCP tool you can determine the program image that contains each respective service instead of looking for each service in the registry. As shown in Figure 5, the Event Log, Browser, and Alerter all share the same Services executable.

Also notice that SC.EXE displays the services that it depends upon to run, or its dependencies. These relationships are useful for troubleshooting because they illustrate the position each service holds within the operating system.

Sharing one process may be efficient for the operating system. When it comes to troubleshooting, however, this cozy relationship can mask an individual service that may be causing problems. For example, if the Task Manager shows that CPU utilization is very high and a significant portion of that activity is the Services process, how do you know which service may be causing the problem?

Figure 5. SC.EXE lets you find the program image that contains a particular service. This eliminates the need for you to look for each service in the registry. Here it shows some of the services that share the same executable.

One solution is to use some of the tools I discussed last month. Use the Windows NT Performance Monitor to identify the instances of each thread within the services process by monitoring Thread: %Processor Time and Thread: ID thread. Once you have the thread ID, run TLIST SERVICES to display all the threads running and their thread ID and starting addresses. Then correlate the starting address of the threads with the starting addresses of the .DLLs, which are also displayed. Once you associate a .DLL with a thread, you can monitor the CPU activity for the errant thread and determine which service within SERVICES.EXE is running rampant.

You can then use SC.EXE to stop and start the service. If you really want to get dangerous, you can send commands to the SCM and try to reel it in. These maneuvers may not be the best or most practical way to administer your system, but they do show you how the various services are related. They also help remove the GUI cover to demonstrate that NT isn’t a monolithic application. Rather, it’s a large set of interrelated services that come together to create a robust environment for user applications.