Best Practices for Managing Applications with Process Control
Abstract
Microsoft Windows 2000 Datacenter Server provides Process Control, a powerful tool for experienced administrators who wish to fine-tune their control over system resources. Process Control is especially valuable for server consolidation scenarios, where multiple services and applications are deployed on a single server that has eight to 32 processors. As with any powerful tool, care must be exercised in how it is used. This paper provides best practices for getting the most from Process Control.
On This Page
Introduction
Taking a Closer Look at How Process Control Works
Best Practices
Appendix A: Step-by-Step Examples and Instructions
Appendix B: Troubleshooting
Appendix C: Registry Data
Introduction
The Microsoft Windows 2000 Datacenter Server operating system introduced Process Control, a powerful Microsoft Management Console (MMC) tool created for use by experienced administrators who must fine-tune their control over system resources. Process Control, which assigns CPU affinity and Job Object control, is especially valuable for server consolidation scenarios, where multiple services and applications are deployed on a single server that has eight to 32 processors.
Note: Readers can consult the Process Control help files for overview information and procedural instructions. |
Process Control was developed to allow administrators to closely control multiple applications and their execution with regard to CPU and memory utilization on large systems under time-varying loads and needs. While it is possible for an application to limit itself to a smaller set of processors, a particular dispatching priority, or other self-imposed constraints, this is not typically done. Most application vendors have no reason to voluntarily impose such restrictions, because they can limit, or appear to limit, performance, and most complex applications are simply expected to perform better and better with more and more processors. Even if applications support setting their own limits, this form of self-restriction or self-control does not easily offer an enterprise level of control.
Process Control, which is available as both a command line and as a graphical user interface (GUI) utility, and is able to interface with scripting tools, allows experienced administrators to control allocation of resources on an application and services basis. Process Control gives administrators more options for controlling the behavior of applications, in line with business needs. This can reduce contention and thrashing and boosts overall system throughput for managed applications. Process Control complements Task Manager and System Monitor, and provides persistent data between boots.
Process Control makes use of the Job Object, a new kernel object for Windows 2000. The Job Object allows the management of single processes or groups of processes. The Job Object can be used to restrict what these processes or groups of processes are allowed to do with regard to memory allocations and processor utilization, in addition to enabling the setting of affinity for these processes or groups of processes.
Using Process Control, you can:
Partition computer resources.
Group processes into process groups.
Assign processor affinity to processes and process groups.
Assign scheduling priority to processes and process groups.
Assign working set limits to processes and process groups.
Enforce user CPU time limits for process groups.
Enforce virtual memory limits for process groups.
Limit the number of active processes in a process group.
Display accumulated process group statistics.
Define the rules that Process Control applies.
Install Process Control on Windows 2000 Professional clients to remotely administer processes and process groups on Windows Datacenter Servers.
Process Control is a powerful administrative tool that is intended for use by experienced system administrators. As with any powerful tool, care must be exercised in how it is used. This paper provides best practices for getting the most from Process Control-while avoiding misuse of it. The paper also includes an appendix with example scripts.
Taking a Closer Look at How Process Control Works
To understand the concepts and controls that the Process Control tool uses, you must understand how code is executed in a computer running Windows 2000-based operating systems. Key elements involved include:
Processes
Threads
Fibers
Scheduling
A process provides the resources needed to execute an application or program, including a collection of allocated virtual memory space, executable code, data, threads, and system resources.
A thread is executable code that is to be serially executed within a process. A processor or CPU executes threads, not processes, so each 32-bit application must have at least one process and one thread.
A process always has at least one thread of execution, known as the primary thread, and can have multiple threads in addition to this. After a thread is scheduled to execute, it continues to run until it is complete, is ended by some event, or is interrupted by a thread with higher priority (by a user action or the kernel's thread scheduler). Each thread can run separate sections of code, or multiple threads can execute the same section of code. Threads that execute the same block of code maintain separate stacks.
All threads of a process share its virtual address space and system resources. In addition, each thread maintains a set of structures that the operating system uses to save the thread context until it is scheduled. The thread context includes the thread's set of machine registers, the kernel stack, a thread environment block, and a user stack in the address space of the thread's process.
A fiber is a unit of execution that must be scheduled by the application code. Fibers run in the context of the threads that create and schedule them. Each thread can schedule multiple fibers. By using fibers you can make it easier to port applications that were designed to schedule their own threads. From a system standpoint, a fiber assumes the identity of the thread that created it.
Process Control Architecture
The Process Control service conforms to all Windows 2000 service guidelines, and uses named pipes to communicate with users. The service owns its own database and is the only software that updates it. The service attempts to minimize resource consumption by having a tunable process-space sampling interval, by using the lowest overhead process discovery technique available, by minimizing registry access, and by using efficient scan and look-up algorithms.
A simplified description of service operation is as follows:
The service loads the Process Control database from the registry and builds internal structures, including a process alias lookup table and process/Job Object lookup table, which is similar to the system rules summary tables displayed by the snap-in. Management policy data is part of the table row data in the process/Job Object lookup table.
The service obtains a list of active Job Objects and processes (see Figure 1) via one or both of the collection mechanisms: process status API (PSAPI) and performance monitor data collection.
For each active process, perform the appropriate step(s):
Determine process name by applying the process name rules.
Determine if the process is to be managed by Process Control or by looking up the process name in the management rules. If it's not listed, ignore this process.
Determine Job Object membership based on process name.
If a member of the Job Object, then create the Job Object, if needed, and add the process to it.
If a new Job Object or stand-alone process or settings don’t match, set affinity, priority, and so on.
Open application programming interface (API) communication channel(s) and enter main process loop:
Determine process name by applying the process name rules.
Periodically check the process space and apply (new processes) or re-apply (processes out of conformance) settings as described above (in steps 2 and 3).
Handle API requests as they arrive on the communication channels.
Handle standard service state changes (pause, continue, and stop).
.gif "Job Objects provide a namable, securable, inheritable, sharable object that controls associated processes, limits possible adverse effects (leaks), manages groups of processes as a unit, and enforces limits on each process associated with a job.")
Figure 1. Job Objects provide a namable, securable, inheritable, sharable object that controls associated processes, limits possible adverse effects (leaks), manages groups of processes as a unit, and enforces limits on each process associated with a job.
Using Process Control
Using Process Control, either through the MMC interface or the command-line utility, you can view, manage, and control the processes running on your system. When applications run, they create processes that use system resources. On a computer managed by Process Control, each process has an alias assigned to it by a user-defined Process Alias rule or by the default rule that associates a process with its image name.
Process Control makes it easy to identify processes in a meaningful way by assigning each process an intuitive alias based on a list of Process Alias rules that you define. When Process Control detects a process, it goes through the following steps to assign the process a name:
Process Control examines the first rule in the Process Alias rule list and attempts to make a match as specified in that rule.
If the match is made, Process Control assigns the process the alias name specified by the rule.
If no match is made, Process Control goes on to the next rule in the list and attempts to make a match. If no match is made, it continues on to the next rule, and then the next, checking all subsequent rules in turn, attempting to make a match.
If none of the rules produces a match, Process Control uses the image name as the alias.
Because the order of the Process Alias rules is important, the rule list cannot be sorted alphanumerically. Instead, clicking Move Up and Move Down when you right-click a rule promotes or demotes the rule one level in the ordered list, accordingly.
Job Objects and Process Groups
Process Control uses Job Objects to construct and implement process groups. A process for which you have defined a Process Execution rule can be placed into a process group. Process groups contain one or more related or unrelated processes that can then be managed as a group using the Process Group Execution rules you define.
Process Execution Rules
Once a process has an associated process alias, you can define a Process Execution rule that controls how and where the process runs. Process Control matches a process alias name with a Process Execution rule that has the same name. When you view a list of processes in the Process Control snap-in, a green check mark indicates that a process has an associated Process Execution rule; a Managed status indicates that the rule modifies the behavior of the process in at least one set of conditions.
A Process Execution rule can specify the priority, affinity, and working set of an individual process, or it can assign the process to a process group that has its own Process Group Execution rule.
Note that Process Control uses standard Windows APIs and may be constrained by security restrictions that an application has placed on its processes or by other security policies put in place by the system administrator. As a result, some processes may not be visible to Process Control.
Job Objects prevent processes from changing their own limits. While a given process may be able to alter its own priority and affinity under normal circumstances, that same process cannot do so from within a Job Object.
Job Objects provide the means to enforce time and memory limits on system resources. Thus, you can create Process Control rules that prevent processes from consuming too much memory or CPU time.
Job Objects collect and retain statistics on those processes, even after the processes conclude. Therefore, you can view meaningful data about a group of processes, across a series of process executions, or both.
Process Group Execution Rules
A Process Group Execution rule manages and controls the execution of processes bound together in a process group by one or more Process Execution rules. When a process is running inside a process group, Windows 2000 ignores any attempts by the process to modify its own limits, using the group limits instead. Thus, you have more stringent management control over process groups than you do over individual processes.
When you view a list of process groups in the Process Control snap-in, a green check mark indicates a process group that has an associated Process Group Execution rule; a Managed status indicates that the rule modifies the behavior of the process group in at least one set of conditions.
Discovery of New Processes
Process Control uses a service called ProcConSvc.exe to manage processes and process groups. Although Process Control includes an MMC snap-in and a command-line utility to interact with the Process Control service, it is the service itself that does the actual work and which must be running on the managed server.
The Process Control service periodically checks the server for new processes. Depending on the scan interval and other factors local to the server, there is a delay between the time a process is created and the time Process Control discovers and manages that process. If a process executes faster than the process scan interval, it may go undetected and thus be unaffected by a given Process Control rule.
Memory Limits on Process Groups
With Process Control, you can define rules that impose memory limits on the working set for a process or process group, and the virtual memory used inside a process group or by a process group.
When these memory limits are exceeded, Process Control rejects requests for additional memory, but does not terminate the processes. How this affects a particular application depends upon the application itself. If the application does not test the results of a failed memory allocation, that application may fail. If a critical memory allocation fails, the application might be required to shut itself down or to skip some important steps. Some applications will react to failed allocations by scaling back their requests and operating using less memory.
Process Control automatically terminates processes that overrun the user-specified CPU time or process count limits. Before you impose memory limits, it is important that you know how much memory the application or group requires to run successfully. To determine how much memory the application or group requires, use Windows 2000 Performance Logs and Alerts to observe the peak memory requirement of a group or single process.
Test carefully to distinguish between applications that run correctly and those that do not. Applications that do not run correctly probably will fail on their own or must be closed (using time limits or manual intervention) once their memory limit is reached.
The Process Control Service
The Process Control Service, ProcConSvc.exe, is the central component of Process Control. The Process Control Service must be run on each computer running Windows 2000 Datacenter Server that you want to manage. The service monitors all processes starting and stopping on the system and applies the rules you have defined. In the case of process groups, the service passes your rules to Job Objects in the operating system, which then enforce those rules.
The Process Control Mediator
Process Control uses a separate process, a mediator (ProcConMD8.exe), to preserve process groups across all service start-and-stop events. The Process Control Mediator maintains a copy of the group and accounting information used to create a Job Object, and displays this information in the Process Control user interface (UI). As long as the mediator is running, you can stop, start, and restart the Process Control service without losing Process Control status.. As a best practice you should always run both the Process Control Mediator and the Process Control service on the server that you are administering.
Best Practices
Process Control is a powerful tool that should only be used by experienced administrators with a solid understanding of the product. As noted earlier, Process Control is intended for use in a server consolidation scenario, in which multiple services and applications are being deployed on a single server with multiple processors.
Use Only Where Needed
A good guideline is to use Process Control only where it’s useful, and not because it’s available. Process Control is a powerful tool for experienced administrators who must fine-tune their control over system resources. Give careful consideration to the rules you define; failing to do so can yield unexpected or undesirable results. For example, you shouldn’t use Process Control to administer critical system services (see following section). You don’t want to create unnecessary Job Objects, as Process Control settings are stored in the system registry (see Appendix C: Registry Data for more information). If the registry gets too large (from supporting hundreds of Process Control rules-rather than the handful that might actually be of value), the system may not be able to boot. (However, this would be an unusual operating condition, unlikely to be encountered in common practice.)
Don’t Administer Critical System Services
Don’t attempt to manage critical system services. Setting system resources lower than the default priority setting for system services could keep a server from running efficiently, and in some cases (such as setting Lsass.exe to a priority of zero) could halt the server. Remember that there is no need to try to manage everything, because the system scheduler does a good job of managing things on its own. The Process Control Service (ProcConSvc.exe.) is another example of a service that should not be managed via Process Control. Setting the priority of this service too low can effectively disable Process Control.
Administrators Should Log On as a Domain Administrator
Security has an effect on what processes the administrator can view with Process Control. If the administrator is logged on as an ordinary user, a number of system and applications processes may not be visible through Process Control because of security restrictions. This is because you can't view processes you do not have rights to control. For this reason an administrator should be logged on as a domain administrator with local administrative rights on the server, or at a minimum be logged on as the local administrator of the system.
Preserve Processor Time for Other Applications
To ensure good server performance, don’t set application priorities so high that they “starve out” applications and services not managed by Process Control.
You Are Managing the Job Object, Not the Process
An important concept to keep in mind is that you are managing the Job Object, and the process that sits inside it. You aren’t directly managing the process. This is an important concept to keep in mind, especially for those used to an UNIX environment, where throttling actions are taken directly on the processes.
Job Objects Have Persistence
Job Objects show persistence, which is required to survive system, application, and service restarts. This persistence also means that a Job Object can’t be arbitrarily deleted, though it can be disabled and removed at the UI level.
Process Control uses Windows Job Objects to manage processes. This implementation places some restrictions on how processes can be managed by Process Control. After a process is associated with a Job Object, the association cannot be broken. In addition, a process cannot be placed in more than one Job Object at a time. From the perspective of Process Control this means that processes cannot be moved between process groups. Once a process is placed in a process group, that process cannot be moved to another group while it remains running. If you want to move a process from one process group to another, the following process is required:
Delete the current process group or change the definition so it no longer selects the process in question.
Create a new process group and place the process in the new group.
Stop and then restart the process.
When the process restarts, it will be managed by the new process group settings.
Note that Process Control Mediator ensures that Job Object settings persist across system, application, and service restarts. Process settings (and their associated Job Object settings) are maintained in the system registry. After a reboot the Process Control Mediator examines the registry and re-creates any Job Objects and the associated settings. When an application or service restarts, the mediator re-creates the association with the appropriate Job Object, maintaining any previously existing settings. In order to stop managing a process through Process Control, it is necessary to delete the current process group or change the definition of the current process group so it no longer selects the process in question. Subsequent stopping and restarting of the process will break the association with the underlying Job Object.
Note that Job Object attributes are dynamic and can be changed as you work, enabling you to manage the system resources used by the applications and services running over a long period of time without having to either stop the applications or services, or restart the operating system. The restrictions described in this section apply only when you are trying to move processes between process groups, or when you are trying to stop managing processes by using Process Control.
Process Control Not Recommended for Single or Dual CPU Systems
Process Control works best on large, multi-processor systems. Although Process Control will work on single-processor and dual-processor computers, you won’t see much benefit from such deployments.
Process Control Not Recommended for Network Load Balancing
Process Control isn’t recommended for use with Network Load Balancing deployments in which a number of front-end servers are linked to a middle tier of Component Object Model (COM) Load Balancing servers; the mid-tier COM objects appear and disappear too quickly for Job Objects to discover and effectively manage the related processes. Additionally, Process Control isn’t needed for managing these technologies, as they are designed to scale out, and already have cluster load balancing built in.
Process Control Protects Against Application Memory Leaks
Process Control can be used to limit the amount of memory that is available to a job. This can help prevent applications with memory leaks from causing complete failure for a server. With a Job Object restriction on virtual memory, the application might stop responding when it reaches the limit, but the server and the other applications on it will continue to run. Applications with memory leaks can be diagnosed with Task Manager or Performance Monitor.
Best Uses for Process Control
Partition computer resources.
Group processes into process groups.
Assign processor affinity to processes and process groups.
Assign scheduling priority to processes and process groups.
Assign working set limits to processes and process groups.
Enforce user CPU time limits for process groups.
Enforce virtual memory limits for process groups.
Limit the number of active processes in a process group.
Display accumulated process group statistics.
Define the rules that Process Control applies.
Install Process Control on Windows 2000 Professional clients to remotely administer processes and process groups on Windows 2000 Datacenter Server.
Avoid Setting Thread Affinity
Windows 2000 uses a symmetric multiprocessing (SMP) model to schedule threads on multiple processors. With this model, any thread can be assigned to any processor. Therefore, scheduling threads on a computer with multiple processors is similar to scheduling threads on a computer with a single processor. However, the scheduler has a pool of processors so that it can schedule threads to run concurrently. Scheduling is still determined by thread priority. However, on a multiprocessor computer, you can also affect scheduling by setting thread affinity.
Thread affinity forces a thread to run on a specific subset of processors. A mask function is used to specify thread affinity for all threads of the process.
Setting thread affinity should generally be avoided, because it can interfere with the scheduler's ability to schedule threads effectively across processors. This can decrease the performance gains produced by parallel processing. Note that some applications provide an affinity mechanism that can conflict with affinity settings established through Process Control. Microsoft SQL Server is an example of such an application. In these applications it is possible to set the process affinity mask through an application management UI. These settings will be overridden by any Process Control affinity settings. Where such a conflict is possible the administrator should use the application affinity mechanisms, and avoid using Process Control affinity for processes associated with the application.
Don’t Allocate Multiple Processors to Single-Threaded Applications
In general, avoid setting thread affinity. This is especially important when dealing with single-threaded applications. Many applications are single-threaded, and allocating more than a single processor is not useful, because such applications can run on only one processor at a time. You can determine the number of threads an application creates by using the Performance Monitor tool.
Don’t Use Process Control to Restrict Processors for SQL Server
Some applications, notably large database applications such as SQL Server, attempt to optimize the number of threads to the number of processors on the server. Attempting to restrict such applications to a smaller set of processors using the Process Control affinity mask will decrease the efficiency of the application. For this reason its is not recommended to use Process Control affinity restrictions on large database applications. (For more information on SQL Server, please visit the SQL Server Web site at https://www.microsoft.com/sql/default.asp.)
Use Process Control to Change the Relative Priority of Applications
Process Control can be used to raise or lower the relative priority of a job with respect to other jobs on the server. This can help achieve better performance if one application is under heavy load or requires more CPU time to meet response time goals than other applications. This is one of the more important uses for Process Control.
Process Control Doesn’t Manage AWE Memory
Process Control only understands virtual address space. It does not manage Address Windowing Extensions (AWE) memory space, which is physical memory mapped into the application’s virtual memory space.
Don’t Stop the Process Control Mediator and Service at the Same Time
The Process Control service, which runs on each computer running Windows 2000 Datacenter Server, monitors all processes starting and stopping on the system and applies the rules you have defined. The Process Control Mediator maintains a copy of the group and accounting information used to create a Job Object.
Don’t stop the Process Control Mediator and service at the same time. If you stop both the service and the mediator at the same time, you will lose information about running process groups; their names will be deleted, and the processes they contain will appear as if they are no longer in their groups.
Windows 2000 continues to control the processes according to the group's rules, but the processes cannot be reassigned to their properly named groups when Process Control restarts. In addition, system log notifications will be lost for those groups.
The best practice is to leave both the Process Control Mediator and the Process Control service running at the same time.
Consider the Process Scan Interval
You may want to reduce the Process Control scan interval when creating new Process Control rules-otherwise you will have to wait for the next scan interval before they take effect. The Process Control service periodically checks the server for new processes and for the status of currently managed processes. The process scan interval is the time between these periodic checks. Depending on the process scan interval and other factors local to the server, there is a delay between the time a new process is created and the time Process Control discovers and manages that process. If a process runs to completion faster than the process scan interval, it may go undetected, and so be unaffected by a given Process Control rule.
Consider the Request Time-Out Interval
The request time-out interval is the amount of time that the Process Control snap-in waits for confirmation of a change or request. If the Process Control service does not respond to the request for a change within the specified interval, the Process Control snap-in stops waiting for a response, and an entry is generated in the system event log.
On a very busy server, the Process Control service may not respond to the Process Control snap-in within the specified interval, but it may still complete the change or request.
Information displayed by the snap-in may be out-of-date, but you can continue to use the Process Control snap-in after a time-out error. When a time-out error occurs, you cannot tell whether the server received the request or whether it completed or rejected the request. You must look at the data in a refreshed view before deciding to resubmit the request.
If the server is very busy, do not set the time-out to the lowest setting (1).
Differentiate Identical Names
If you have two programs on your system that have identical names, or two versions of the same product, create Process Alias rules that match on a directory or a string and assign different alias names to the image files so that you can easily distinguish one from the other.
Use Caution Before Setting Limits on the Number of Processes
You can use Process Control to limit the number of processes that can be created in a process group. Limiting the number of processes in a group:
Prevents the unqualified generation of child processes.
Controls applications with complex process dependencies.
Processes within a group can create child processes freely up to the process count limit set. Process Control discovers processes that exceed this limit as it scans the groups. Process Control terminates these processes upon discovery.
However, before setting limits on the number of processes that can be created in a group, make sure that you understand the requirements of your application processes. Setting limits may prevent your application from working correctly.
Don’t Use Extreme Scheduling Class Values
A scheduling class applies to Job Objects. A scheduling class sets the length of the time slice (or quantum) for threads and processes in the job. This setting applies only on systems running with long, fixed quantums (the default for Datacenter Server).
Within each priority class (above normal, below normal, and so on), Windows 2000 uses the scheduling class to determine which processes within that priority receive the most processor scheduling time. The scheduling class ranges from 0 through 9, with 0 indicating the least importance and 9 the highest importance.
Every process running in a process group inherits the scheduling class setting for that particular process group. Processes within a group cannot set their own scheduling class.
The default scheduling class value is 5. In general, do not use values greater than 7 or less than 2. For example, selecting a scheduling class of 0 indicates that the group should not run at all unless the processor has no other work to do in that priority class; selecting a scheduling class of 9 indicates that the group should always run (until it becomes idle) when the processor performs work in that priority class.
Administrator Status Required for Security
Process Control uses standard Windows APIs and may be constrained by security restrictions that an application has placed on its processes, or by other security policies put in place by the system administrator. As a result, some processes may not be visible to Process Control.
Capacity Planning and Monitoring Queuing and Performance
No amount of resource management can provide more performance than is available in the system, nor can it avoid the reality that as the system becomes more loaded, response times increase simply due to queuing of work. Also, some applications may not respond linearly to simply having more resources with which to do work.
As loads increase toward the peak capacity of a system, latency rapidly climbs to unacceptable levels. Essentially, once any component of the system is saturated, any further work demands are queued and left waiting. This saturation point can only be determined by measuring actual workloads. Once that is determined, further investigation can pinpoint the bottleneck, preventing further performance problems. The bottleneck could be CPU cycles available, storage channel performance, the amount of memory available to the system for caching or processes, or something else entirely.
Once the bottleneck is identified, it may be possible to use Process Control to provide more resources for a critical application or service. If there are more processors or memory available, then Process Control can be used to dynamically allocate them. If the bottleneck is identified to be storage—for example, if the disk queue is large—then Process Control may not materially affect the overall system capability, and it will require hardware modifications, such as adding more storage and storage channels, to improve performance.
However, not all applications or services may be able to use more resources to achieve greater scalability due to the design of the application or service. If an application's or service's performance doesn’t improve after being given more resources, it is possible that it needs to be redesigned or implemented in some other fashion. One example of a different implementation is to use multiple instances of an application (most services do not allow multiple instances) instead of using one instance. This may be a more efficient of system resources, provide more scalability, and possibly be a more manageable arrangement as well. Process Control can function with multiple instances and individually parcel out the resources needed by each instance.
Appendix A: Step-by-Step Examples and Instructions
The following step-by-step examples and instructions for using Process Control provide information about:
Managing CPU Usage and Affinity of Single Processes
Managing Memory for Single Processes
Maintaining Nominal Performance for Single Processes
Managing Affinity for Process Groups
Managing Memory for Process Groups
Maintaining Nominal Performance for a Process Group
Managing CPU Usage and Affinity of Single Processes
Here's how you can create rules for the cpu* processes, without creating a Job Object, and maintain the CPU usage.
Use the only one and first in the row CPU for the processes and then dynamically add the second CPU if needed.
To create rules for the cpu* processes
In the following procedure , you will create two rules (the Process Alias rule and the Process Execution rule) that will allow you to change the affinity, priority, and memory usage for all the processes with name match cpu*.
To do create these rules by using the GUI, follow these steps:
Open Process Control.
To open Process Control, click Start, point to Programs, point to Administrative Tools, and then click Process Control.
In the console tree, double-click Process Control to expand the tree.
Double-click Rules.
Click Process Alias Rules.
In the details pane, right-click the list where you want to insert the new rule, then click Insert Rule.
Define the new Process Alias Rule.
In the Type match, select the Image Name check box.
In the Match String text box, type:
cpu*In the Process alias assigned on a match, type:
cpuProcessesClick OK.
In the Rules tree, right-click Process Execution Rules and click New Process Execution Rule.
Define the new Process Execution Rule.
In the Process alias text box, type:
cpuProcessesClick Next.
Caution: Do not select the Execute within a process group check box.
Click Next.
Select Apply Affinity check box. Check the first box in the group.
Click Next.
Click Next.
Click Finish.
To create these two rules with CLI, follow these steps:
Run cmd.
To run cmd, click the Start button and choose Run. Then type:
cmd
In the cmd window, type the following commands:
proccon -a -n 0 P cpu* cpuProcesses
proccon -a -pd cpuProcesses -f a -a 1
In the following procedure , you will change the affinity for the processes.
To do this by using the GUI, follow these steps:
Open Process Control.
To open Process Control, click Start, point to Programs, point to Administrative Tools, and then click Process Control.
In the console tree, double-click Process Control to expand the tree.
Double-click Rules to expand the tree.
Click Process Execution Rules.
In the details pane, double-click cpuProcesses.
Click the Affinity tab. Click the second check box in the Apply Affinity group.
To change the affinity for the processes with CLI, follow these steps:
Run cmd.
To run cmd, click the Start button and choose Run. Then type:
cmdIn the cmd window, type:
proccon -r -pd cpuProcesses -f a -a 3
Note: Now that the Job Object has been removed, so if you want to remove the process rule or add the processes to another process group, you can do it without stopping all the processes associated with the alias. |
Managing Memory for Single Processes
Here's how you can create rules for the mem* processes, without creating Job Object while still maintaining the memory usage.
In the following procedure , you will create two rules (the Process Alias rule and the Process Execution rule) that will allow you to change the affinity, priority, and memory usage for all the processes with name match mem*.
To create these rules by using the GUI, follow these steps:
Open Process Control.
To open Process Control, click Start, point to Programs, point to Administrative Tools, and then click Process Control.
In the console tree, double-click Process Control to expand the tree.
Double-click Rules.
Click Process Alias Rules.
In the details pane, right-click the list where you want to insert the new rule, then click Insert Rule.
Define the new Process Alias Rule.
In the Type match Tab, select the Image Name check box.
In the Match String text box, type:
mem*In the Process alias assigned on a match, type:
memProcessesClick OK.
In the Rules tree, right-click Process Execution Rules and click New Process Execution Rule.
Define the new Process Execution Rule.
In the Process alias text box, type:
memProcessesDo not select the Execute within a process group check box.
Click Next.
Click Next.
Click Next.
Select the Apply working set limits check box.
In the Minimum memory (Kilobytes) text box, type:
2000In the Maximum memory (Kilobytes) text box, type:
4000Click Finish.
To create these rules with CLI, follow these steps:
Run cmd.
To run cmd, click the Start button and choose Run. Then type:
cmd.In the cmd window, type the following commands:
proccon -a -n 0 P mem* memProcesses
proccon -a -pd memProcesses -f w -w 2000 3000
In the following procedure , you will change the memory set limits for the processes.
To do do this by using the GUI, follow these steps:
Open Process Control.
To open Process Control, click Start, point to Programs, point to Administrative Tools, and then click Process Control.
In the console tree, double-click Process Control to expand the tree.
Double-click Rules to expand the tree.
Click Process Execution Rules.
In the details pane, double-click memProcesses.
Click the Memory tab.
In the Minimum memory (Kilobytes) text box, type:
2000In the Maximum memory (Kilobytes) text box, type:
4000Click OK.
To change the memory set limits for the processes with CLI, follow these steps:
Run cmd.
To run cmd, click the Start button and choose Run. Then type:
cmd
In the cmd window, type the following commands:
To run cmd, click the Start button and choose Run. Then type:
proccon -r -pd memProcesses -f w -w 3000 5000
Note: The Job Object is not there, so if you want to remove the process rule or add the processes to another process group, you can do it without stopping all the processes associated with the alias. |
Maintaining Nominal Performance for Single Processes
Here's how you can create rules for the processes in directory \my_dir and maintain the minimal performance.
You can set up normal priority for the processes and then increase the priority if needed.
To create rules for the all processes in the \my_dir directory
In the following procedure , you will create two rules (the Process Alias rule and the Process Execution rule) that will allow you to control some properties of all the processes in the \my_dir directory.
To do create these rules by using the GUI, follow these steps:
Open Process Control.
To open Process Control, click Start, point to Programs, point to Administrative Tools, and then click Process Control.
In the console tree, double-click Process Control to expand the tree.
Double-click Rules.
Click Process Alias Rules.
In the details pane, right-click the list where you want to insert the new rule, then click Insert Rule.
Define the new Process Alias Rule.
In the Type match, select the Sub-Directory Name check box.
In the Match String text box, type:
my_dir
In the Process alias assigned on a match, type:
myProcesses
Click OK.
In the Rules tree, right-click Process Execution Rules and click New Process Execution Rule.
Define the new Process Execution Rule.
In the Process alias text box, type:
myProcesses
Do not select the Execute within a process group check box.
Click Next.
Click Next.
Select Apply Affinity check box.
Click Next.
Click Finish.
Now you can change affinity, priority, and memory usage settings for all the processes in the \my_dir directory by changing properties of the myProcesses process rule properties.
To create these two rules with CLI, follow these steps:
Run cmd.
To run cmd, click the Start button and choose Run. Then type:
cmd
In the cmd window, type the following commands:
proccon -a -n 0 D my_dir myProcesses
proccon -a -pd myProcesses -f p -p N
In the following procedure , you will change the priority for the processes.
To do this by using the GUI, follow these steps:
Open Process Control.
To open Process Control, click Start, point to Programs, point to Administrative Tools, and then click Process Control.
In the console tree, double-click Process Control to expand the tree.
Double-click Rules to expand the tree.
Click Process Execution Rules.
In the details pane, click the myProcesses rule.
Click the Priority tab. Select the Above Normal check box.
Click OK.
To change the priority for the processes with CLI, follow these steps:
Run cmd.
To run cmd, click the Start button and choose Run. Then type:
cmd
In the cmd window, type the following commands:
proccon -r -pd myProcesses -f p -p A
Note: There is no Job Object present, so if you want to remove the process rule or add the processes to another process group, you can do it without stopping all the processes associated with the alias. |
Managing Affinity for Process Groups
Here's how you can create rules for the cpu* processes, create a Job Object, and maintain the CPU usage.
To do this, you can use the only one and first in the row CPU for the processes and then dynamically add the second CPU if needed.
To create rules for the cpu* processes
In the following procedure , you will create three rules (the Process Alias rule, the Process Execution rule, and the Process Group Execution rule) that will allow you to control all the processes with name match cpu* by one Job Object.
To do create these rules by using the GUI, follow these steps:
Open Process Control.
To open Process Control, click Start, point to Programs, point to Administrative Tools, and then click Process Control.
In the console tree, double-click Process Control to expand the tree.
Double-click Rules.
Click Process Alias Rules.
In the details pane, right-click the list where you want to insert the new rule, then click Insert Rule.
Define the new Process Alias Rule.
In the Type match, select the Image Name check box.
In the Match String text box, type:
cpu*
In the Process alias assigned on a match, type:
cpuProcesses
Click OK
In the Rules tree, right-click Process Execution Rules and click New Process Execution Rule.
Define the new Process Execution Rule.
In the Type match, select the Image Name check box.
In the Process alias text box, type:
cpuProcesses
Click Next
Select the Execute within a process group check box
In the text box, type:
cpuGroup
Click Next
Click Next
Click Next
Click Finish
In the Rules tree, click Process Group Execution Rules.
In the details pane, double-click cpuGroup.
Change the affinity for the group.
Click the Affinity tab.
Select the Apply affinity box.
Check the first box in the group.
Click OK
Now all the cpu* processes will run under control of the cpuGroup process group. All the processes will run only on the first CPU.
To create these two rules with CLI, follow these steps:
Run cmd.
To run cmd, click the Start button and choose Run. Then type:
cmd
In the cmd window, type the following commands:
proccon -a -n 0 P cpu* cpuProcesses
proccon -a -pd cpuProcesses -f g -g cpuGroup
proccon -r -gd cpuGroup -f a -a 1
In the following procedure , you will change the affinity for the processes.
To do this by using the CLI, follow these steps:
Open Process Control.
To open Process Control, click Start, point to Programs, point to Administrative Tools, and then click Process Control.
In the console tree, double-click Process Control to expand the tree.
Double-click Process Groups to expand the tree.
Right-click cpuGroup, then click Properties.
Click the Affinity tab. Click the second box in the Apply Affinity group.
To change the affinity for the processes with CLI, follow these steps:
Run cmd.
To run cmd, click the Start button and choose Run. Then type:
cmd
In the cmd window, type the following commands:
proccon -r -gd cpuGroup -f a -a 3
Note: If you remove all the rules, the affinity still will be the same for the processes. You have to stop all the processes first, then remove the rules. And if you run any of cpu* again, the applied affinity would not be there. |
Managing Memory for Process Groups
To create rules for the mem* processes
In the following procedure , you will create three rules (the Process Alias rule, the Process Execution rule, and the Process Group Execution rule) that will allow you to control all the processes with name match mem* by one Job Object.
To create these rules by using the GUI, follow these steps:
Open Process Control.
To open Process Control, click Start, point to Programs, point to Administrative Tools, and then click Process Control.
In the console tree, double-click Process Control to expand the tree.
Double-click Rules.
Click Process Alias Rules.
In the details pane, right-click the list where you want to insert the new rule, then click Insert Rule.
Define the new Process Alias Rule.
In the Type match Tab, select the Image Name check box.
In the Match String text box, type:
mem*
In the Process alias assigned on a match, type:
memProcesses
Click OK.
In the Rules tree, right-click Process Execution Rules and click New Process Execution Rule.
Define the new Process Execution Rule.
In the Process alias text box, type:
memProcesses
Click Next.
Select the Execute within a process group check box.
In the text box, type:
memGroup
Click Next.
Click Next.
Click Next.
Click Finish.
In the Rules tree, click Process Group Execution Rules.
In the details pane, double-click memGroup
Change the memory usage for the group.
Click the Memory tab.
Select the Apply working set limits box.
In the Minimum memory (Kilobytes) text box, type:
2000
In the Maximum memory (Kilobytes) text box, type:
4000
Click OK.
Now all the mem* processes will run under control of the memGroup process group.
To create these rules with CLI, follow these steps:
Run cmd.
To run cmd, click the Start button and choose Run. Then type:
cmd.In the cmd window, type the following commands:
proccon -a -n 0 P mem* memProcesses
proccon -a -pd memProcesses -f g -g memGroup
proccon -r -gd memGroup -f w -w 2000 4000
In the following procedure , you will change the Memory set limits for the processes.
To do this by using the GUI, follow these steps:
Open Process Control.
To open Process Control, click Start, point to Programs, point to Administrative Tools, and then click Process Control.
In the console tree, double-click Process Control to expand the tree.
Double-click Process Groups to expand the tree.
Right-click memGroup, then click Properties
Click the Memory tab.
In the Minimum memory (Kilobytes) text box, type:
3000
In the Maximum memory (Kilobytes) text box, type:
5000
Click OK.
To change the Memory set limits with CLI, follow these steps:
Run cmd.
To run cmd, click the Start button and choose Run. Then type:
cmd
In the cmd window, type the following commands:
proccon -r -gd memGroup -f w -w 3000 5000
Note: If you remove all the rules, the memory set limits still will be the same for the processes. You have to stop all the processes first then remove the rules. And if you run any of mem* again, the memory set limits will be gone. |
Maintaining Nominal Performance for a Process Group
Here's how you can create rules for the processes in directory \my_dir while maintaining minimal performance.
You will need to set up normal priority for the processes and then increase the priority if needed.
To create rules for the all processes in the \my_dir directory
In the following procedure, you will create three rules (the Process Alias Rule, the Process Execution rule, and the Process Group execution rule) that will allow you to control all the processes in the \my_dir directory with one Job Object.
To do create these rules by using the GUI, follow these steps:
Open Process Control.
To open Process Control, click Start, point to Programs, point to Administrative Tools, and then click Process Control.
In the console tree, double-click Process Control to expand the tree.
Double-click Rules.
Click Process Alias Rules.
In the details pane, right-click the list where you want to insert the new rule, then click Insert Rule.
Define the new Process Alias Rule.
In the Type match, select the Sub-Directory Name check box.
In the Match String text box, type:
my_dir
In the Process alias assigned on a match, type:
myProcesses
Click OK.
In the Rules tree, right-click Process Execution Rules and click New Process Execution Rule.
Define the new Process Execution Rule.
In the Process alias text box, type:
myProcesses
Click Next.
Select the Execute within a process group check box.
In the text box, type:
myGroup
Click Next.
Click Next.
Click Next.
Click Finish.
In the Rules tree, click Process Group Execution Rules.
In the details pane, double-click myGroup.
Apply the Priority for the group.
Click the Priority tab.
Select the Apply priority box.
Click OK.
Now all the processes in the \my_dir directory will run under control of the myGroup process group.
To create these rules with CLI, follow these steps:
Run cmd.
To run cmd, click the Start button and choose Run. Then type:
cmd.
In the cmd window, type the following commands:
proccon -a -n 0 D my_dir myProcesses
proccon -a -pd myProcesses -f g -g myGroup
proccon -r -gd myGroup -f p -p N
In the following procedure , you will change the priority for the processes.
To do this by using the GUI, follow these steps:
Open Process Control.
To open Process Control, click Start, point to Programs, point to Administrative Tools, and then click Process Control.
In the console tree, double-click Process Control to expand the tree.
Double-click Process Groups to expand the tree.
Right-click myGroup, then click Properties.
Click the Priority tab. Click the Above Normal check box.
To change the priority of the processes with CLI, follow these steps:
Run cmd.
To run cmd, click the Start button and choose Run. Then type:
cmd
In the cmd window, type the following commands:
proccon -r -gd myGroup -f p -p A
Note: If you remove all the rules, the priority still will be the same for the processes. You have to stop all the processes first, then remove the rules. And if you run any /my_dir processes again, the applied priority will be gone. |
Appendix B: Troubleshooting
This section provides problem-solving guidelines for Process Control. Possible problems and their resolutions include:
Microsoft Management Console (MMC) reports "Snap-in failed to initialize. Name: Process Control."
Cause: MMC cannot find the Process Control snap-in (ProcCon.dll).
Solution: If the Process Control snap-in has been moved from its original location, it must be reinstalled (re-registered) or moved back to its original location. ProcCon.dll is usually installed in %SystemRoot%\System32. To register the dll, at a command prompt, type:
REGSVR32 ProcCon.dll
Then open the MMC. On the Console menu, click Add/Remove Snap-in and add the Process Control snap-in.
Process Control does not show up in Computer Management.
Cause: The Process Control service is not installed on the computer being managed.
Solution: Verify that the Process Control service is installed on the computer being managed. Process Control is a dynamic extension of Computer Management. If the Process Control service is not installed on the computer being managed, Process Control will not appear in the Services and Application folder in the console tree.
Process Control does not give the option to connect to another computer.
Cause: You are running the Process Control snap-in from the Computer Management console.
Solution: When you run Process Control from the Computer Management console, Process Control and Computer Management will manage the same computer. To manage another computer, in the console tree, click Computer Management, and then from the Action menu, click Connect to another computer.
Alternate Solution: Use the stand-alone version of Process Control. Choose Process Control from the Start menu, where your other administrative tools, such as Computer Management, are located. This way, you can direct Process Control at any computer, regardless of the Computer Management target.
The Service tab for Process Control properties does not always appear.
Cause: The Process Control snap-in cannot communicate with the Process Control service.
Solution: Make sure the Process Control service is running on the computer you are managing.
Changes or requests are reported to time out, but the change occurs.
Cause: The Process Control snap-in quit waiting for a response from the Process Control service. Although the Process Control service got the request and acted on it, the response to the snap-in took too long, and the snap-in stopped waiting for a reply.
Solution: If the problem occurs frequently, increase the request time-out interval. The message might be an indicator that the computer being managed is very busy. Note that no harm results from this. Displayed information may be out-of-date (use "refresh" to check this), but you can continue to use the snap-in after a time-out error.
Note: When a time-out error occurs, you cannot tell whether the server received the request, acted on it, or rejected it. Thus, you should look at the data on a refreshed view before deciding whether you should resubmit your request. |
Changes or updates fail because a database update occurred between the time you retrieved data and the time you attempted to update it.
Cause: The Process Control service has detected and prevented an attempt to update a rule that has just been updated.
Solution: This is not necessarily a problem. Process Control is careful not to allow two or more updates to a single rule at the same time. If multiple system administrators are updating Process Control rules, it may be necessary to coordinate the updates. You can also see this warning if you use multiple Process Control sessions or views from MMC to manage the same computer.
Requests take a long time or do not work.
Cause: The Process Control snap-in timed out trying to communicate with the Process Control service on the computer to be managed. The Process Control service did not get the request because the Process Control snap-in gave up or quit trying to communicate.
Solution: If the problem occurs frequently, increase the request time-out interval. The message may be an indicator that the computer being managed is very busy.
Note: When a time-out occurs, you cannot tell whether the server received, acted on, or rejected the request. Thus, you should look at the data on a refreshed view before deciding whether your request needs to be resubmitted. |
Processes are not being put in process groups, or are put in the wrong process groups.
Cause: If the process was started by another process (its parent), and the parent process is in a process group, the new process will typically be in the same group as its parent process. For example, if the command prompt process Cmd.exe is in a process group, any process, program, or application started at a command line will typically remain in the same process group as its parent process.
Solution: If you want processes to remain in the group where the parent is running, you need not include rules for the new process. Automatically running in the group of the parent process is normal process group behavior. If you want a process that starts other processes (such as Cmd.exe or Explorer.exe) to be included in a group, but either you do not want to include their launched processes in the group or you want them to be eligible for inclusion in other groups, use the silent breakaway feature. Once a process is placed in a process group, the process cannot leave the process group. Thus, it is important to ensure that any process you want to assign to a group is created free of any group association.
Process Control causes applications to run incorrectly.
Cause: When Process Control manages processes and applies certain rules, some applications will behave differently. In some cases, applications will not work within those rules or applied constraints. Memory limits for process groups are stringent; applications are not allowed to break those limits.
Solution 1: Memory Limit is in effect. An application can fail if Process Control limits the committed memory to a value below that which the application requires. You can solve this by turning off (or possibly increasing) the memory limit.
Solution 2: Process count limit is in effect. If the application that does not work properly creates other processes, and the group has a process count limit, other processes might be failing because the limit was exceeded. The processes that continue running might not work properly because other processes failed.
Solution 3: Breakaway OK is required. The process in question might be creating other processes and requesting that they break away from the group. If the group does not permit this because the Breakaway OK setting is off, the new process will fail, and the application will not run correctly.
Solution 4: Group-wide limits is in effect. Group memory and time limits are possible. Such limits are not applied to each process, but are applied to the group as a whole. Thus, if one process in a group acquires most of the allowed memory, another process might fail to acquire even the basic amount of memory needed to begin running. If a group's time limit is exceeded, a process that has used very little time may be terminated along with the process that used most of the time. Do not use group-wide limits unless it makes sense to do so for the mix of processes in the group.
Solution 5: Working set limit is mismatch. When a working set limit is in effect for a group, that limit is applied to each process in the group. A limit that is ample for one process could be inadequate for another process. Because this is a hard limit, the process that requires more memory will page against itself and appear to be performing poorly, even though the system as a whole and other processes in the group are performing well. Do not use group working set limits for a mix of processes that require widely different working sets.
Process Control causes other applications to fail or receive access violations.
Cause: Memory limits for process groups are stringent, and applications are not allowed to break those limits. Thus, if an application asks for memory and a process group has a memory limit in place, the application's request for memory will fail if the request would push memory past the limit. An application can get an access violation as a result of using nonexistent memory.
Solution: Each application should check that memory allocation requests are successful. If the application in question does not perform such checks, do not apply memory limits, or the application might fail when the limit is reached.
Process Control causes applications to run more slowly.
Cause: Process Control is applying rules that lower the priority, limit the number of processors to be used, or restrict the amount of memory the application is using.
Solution: Modify or remove Process Control rules that are slowing the process. Note, however, that in a busy system, rules that permit a particular process or group to consume more resources can slow other processes or groups.
Process Control does not allow processes to run.
Cause: Process Control is applying a rule that may be too restrictive.
Solution: In a busy system, processes or groups that belong to a lower priority or scheduling class can be deprived of memory. If there is not enough time for a lower-priority process to run, it will either have to compete on an equal footing by having its priority raised (or other priorities lowered), or processors will have to be apportioned so the lower-priority work gets some attention. For example, with eight processors, one processor might have to be set aside for low-priority groups, while the higher-priority groups will then compete to use the other seven processors. This way, the low-priority work will get some time and cannot be completely starved by the other work. If the starved process or group is run infrequently (or spends considerable time waiting), it might be desirable to place it at a higher priority than other work. That way, its work will be carried out sooner, other work will be minimally affected, and overall throughput will increase.
Task Manager and Process Control do not show the same list of processes.
Cause: The Process Control snap-in can be set to show only managed processes.
Solution: Set the snap-in to show all processes or all running processes. To do this, in the console tree, under Process Control, click Processes. On the View menu, click Show All Processes.
Alternate Cause: A Process Alias rule might be hiding processes.
Solution: Change or remove any Process Alias rules that are hiding processes.
Alternate Cause: Process Control uses standard APIs and might be constrained by security restrictions that an application has placed on its processes, or by other security policies put in place by the system administrator. Task Manager is part of the operating system and uses methods internal to Windows that are not restricted by the same constraints.
Solution: None.
Task Manager and Process Control do not show the same priority.
Cause: Windows uses 32 priority levels internally. Externally there are six levels. Thus, when a process is displayed with one of the six priority classes, the 32 possible values are mapped to six. In some cases, the mapping used by Process Control and the mapping used by Task Manager might not be identical.
Solution: None. This is not a problem. Any process in which the class appears with different values actually has a priority somewhere between the two values shown.
Processes remain in a group even after the rule is changed.
Cause: Once a process is placed in a process group, the process cannot leave the process group. This is behavior mandated by the underlying Job Object technology in Windows 2000.
Solution: If the group change must be performed immediately, the only solution is to end the process in question and then restart it. Otherwise, the next time the process starts, it will obey the rules as updated.
Processes do not exhibit the behavior specified in the Process Execution rule.
Cause: Unlike process groups, Process Execution rules can be overridden by a process. When the Process Control service recognizes a new process with a Process Execution rule, the service will apply the rule. The Process Control service will continuously try to keep enforcing the Process Execution rule, but between the time a process changes its own setting and the time the Process Control service checks these settings, the limit might not be set as desired.
Solution: If you do not want the process to be able to override a Process Execution rule, put the process in a process group, and create a Process Group Execution rule.
Process Control rules do not appear to be taking effect.
Cause: The Process Control service has not yet checked for new processes to manage.
Solution: Wait for the Process Control scan interval to expire, or set a shorter scan interval. Process Control only checks for new processes periodically. This interval is controlled by the scan rate set in the Process Control service. A shorter interval will cause Process Control to check for new processes more often at the expense of slightly increased Process Control overhead.
Alternate Cause: The computer being managed is very busy and the Process Control service is not getting enough time to perform its task.
Solution: It is recommended that the Process Control service be run at high- or above-normal priority. Process Control is not CPU-intensive, but giving it a higher priority ensures that on a busy server, Process Control will be given time to apply any newly defined rules. However, as a rule, Process Control should run at a higher priority than any of the processes or groups it manages.
Appendix C: Registry Data
The Process Control registry keys will all be in:
\HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Process Control
There will be one name at this level, NameRules, whose type is REG_MULTI_SZ and whose value is all the entries in the alias rules table, each in the form “{type,match,name}." If profiles are added in a future version, their definitions will also appear at this level.
Sub-keys at this level will be JobRules and ProcessRules. Under each of these sub-keys will be a sub-key for each process or job rule whose key name is the process alias or job name, respectively. Data under these sub-keys will consist of a default management entry (named "DfltMgmt") and a management entry for each profile (named with the profile name) whose value is a string of management parameters, each preceded by a character indicating which parameter it is. For process names there may also be a "MemberOf" data item whose value is a job name.
Sample Registry Database
Here is a sample registry database with three definitions to illustrate the preceding:
\HKLM\System\CurrentControlSet\Services\Process Control:
Data: NameRules : REG_MULTI_SZ : {A,%SystemRoot%,Win}
{D,mssql*,SQLServer}
{P,PK*,\ZipUtil\}
\ProcessRules\SQLServer:
Data: DfltMgmt : REG_SZ : {A0x000000ff, P8, …}
Data: MemberOf : REG_SZ : SQLServer
\ProcessRules\ZipUtil:
Data: DfltMgmt : REG_SZ : {A0x00000020, P24, …}
\JobRules\SQLServer:
Data: DfltMgmt : REG_SZ : {A0x0000000f, P8, …}
The name rules match three categories of process-anything running from the Windows subtree is identified as "Win," then anything running from a path including sub-directory mssql* is identified as "SQLServer," and then any program (exe) starting with "PK" is identified as "ZipUtil." Note that the first entry causes any program delivered as part of Windows to be placed in the Win group. This is a good way to avoid inadvertently matching one of the other rules with a critical system utility or program.
Although the name rules consist of multiple strings, some of which may need substitutions made to them, don’t use type REG_EXPAND_SZ. It is up to Process Control to detect substitutions without the presence of this type and to cause them to happen when loading the name rules from the registry.
Once the process name has been determined, the process management rules are looked up by name in the ProcessRules sub-key. If the process name sub-key does not exist, as is the case with "Win," then the process is considered to be unmanaged: No attempt to change the characteristics of the process will be made by Process Control. This is a good choice for most operating system components.
In the case of "SQLServer," there is a sub-key under ProcessRules. Furthermore, there is a name/type/value entry for "MemberOf" that indicates that the process is a member of a Job Object-here it's "SQLServer" (process name and Job Object names may be the same). So, by locating the Job Object name (under JobRules), you'll discover that there is a sub-key for "SQLServer." Its data/type/value entries give us the management parameters for the SQLServer Job Object.
Finally, the process ZipUtil, which perhaps represents a high-CPU, low-priority utility operation, is an example of a process that is managed without the use of a Job Object, because it has no "MemberOf" entry. The "DfltMgmt" entry in the ZipUtil sub-key will be used by Process Control to manage the process.
By having management parameters associated with a process like SQLServer in addition to its Job Object parameters, you can add or remove Job Object membership without losing process-level management behavior. You will also have management parameters to use when the Job Object doesn’t exist. This way you have a fallback position, and you don’t lose definitions when you associate a process with a Job Object and then undo it.