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.
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
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.
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
|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.
If you need a good reference book on
NT services, check out Professional
NT Services by Kevin Miller (Wrox
Press, Inc., $59.99, ISBN 1-86100-130-4).
The book covers NT service development,
touching on such issues as security,
configuration, and implementation.
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
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
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
|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.