Out-of-Process Server Implementation Helpers

Four helper functions that can be called by out-of-process servers are available to simplify the job of writing server code. COM clients and COM in-process servers typically would not call them. These functions are designed to help prevent race conditions in server activation when the servers have multiple apartments or multiple class objects. They can also, however, as easily be used for single-threaded and single class object servers. The functions are as follows:

To shut down properly, a COM server must keep track of how many object instances it has instantiated and how many times its IClassFactory::LockServer method has been called. Only when both of these counts reach zero can a server shut down. In single-threaded COM servers, the decision to shut down was coordinated with incoming activation requests, which were serialized by the message queue. The server, upon receiving a release on its final object instance and deciding to shut down, would revoke its class objects before any more activation requests were dispatched. If an activation request did come in after this point, COM would recognize that the class objects were revoked and would return an error to the Service Control Manager (SCM), which would then cause a new instance of the local server process to be run.

However, in an apartment model server, in which different class objects are registered on different apartments, and in all free-threaded servers, this decision to shut down must be coordinated with activation requests across multiple threads so that one thread of the server does not decide to shut down while another thread of the server is busy handing out class objects or object instances. One classical but cumbersome approach to solving this is to have the server, after it has revoked its class objects, recheck its instance count and stay alive until all instances have been released.

To make it easier for server writers to handle these types of race conditions, COM provides two reference counting functions:

When the global per-process reference count reaches zero, COM automatically calls CoSuspendClassObjects, which prevents any new activation requests from coming in. The server can then deregister its various class objects from its various threads at leisure without worry that another activation request may come in. All new activation requests are henceforth handled by the SCM launching a new instance of the local server process.

The simplest way for a local server application to make use of these functions is to call CoAddRefServerProcess in the constructor for each of its instance objects and in each of its IClassFactory::LockServer methods when the fLock parameter is TRUE. The server application should also call CoReleaseServerProcess in the destructor of each of its instance objects and in each of its IClassFactory::LockServer methods when the fLock parameter is FALSE.

Finally, the server application should pay attention to the return code from CoReleaseServerProcess, and if it returns 0, the server application should initiate its cleanup, which, for a server with multiple threads, typically means that it should signal its various threads to exit their message loops and call CoAddRefServerProcess and CoReleaseServerProcess. If the server process lifetime management functions are used, they must be used in both the object instances and the LockServer method; otherwise, the server application may be shut down prematurely.

When a CoGetClassObject request is made, COM contacts the server, marshals the IClassFactory interface of the class object, returns to the client process, unmarshals the IClassFactory interface, and returns this to the client. At this point, clients typically call LockServer with TRUE to prevent the server process from shutting down. However, there is a window of time between when the class object is marshaled and when the client calls LockServer in which another client could connect to the same server, get an instance, and release that instance, thus causing the server to shut down and leaving the first client high and dry with a disconnected IClassFactory pointer. To prevent this race condition, COM adds an implicit call to LockServer with TRUE to the class object when it marshals the IClassFactory interface and an implicit call to LockServer with FALSE when the client releases the IClassFactory interface. Therefore, it is not necessary to remote LockServer calls back to the server, and the proxy for LockServer simply returns S_OK without actually remoting the call.

There is another activation-related race condition during initialization of an out-of-process server process. A COM server that registers multiple classes typically calls CoRegisterClassObject with REGCLS_LOCAL_SERVER for each CLSID it supports. After it has done this for all classes, the server enters its message loop. For a single-threaded COM server, all activation requests are blocked until the server enters the message loop. However, for an apartment model server that registers different class objects in different apartments and for all free-threaded servers, activation requests can arrive earlier than this. In the case of apartment model servers, activation requests could arrive as soon as any one thread has entered its message loop. In the case of free-threaded servers, an activation request could arrive as soon as the first class object is registered. Since an activation can happen this early, it is also possible for the final release to occur (and therefore cause the server to begin shutting down) before the rest of the server has had a chance to finish initializing.

To eliminate these race conditions and simplify the job of the server writer, any server that wants to register multiple class objects with COM should call CoRegisterClassObject with REGCLS_LOCAL_SERVER | REGCLS_SUSPENDED for each different CLSID the server supports. After all classes have been registered and the server process is ready to accept incoming activation requests, the server should make one call to CoResumeClassObjects. This function tells COM to inform the SCM about all the registered classes, and it begins letting activation requests into the server process. Using these functions provides the following advantages:

• Only one call is made to the SCM, regardless of how many CLSIDs are registered, thus reducing the overall registration time (and hence startup time of the server application).
• If the server has multiple apartments and different CLSIDs are registered in different apartments, or if the server is a free-threaded server, no activation requests will come in until the server calls CoResumeClassObjects, giving the server a chance to register all of its CLSIDs and get properly set up before having to deal with activation requests and possible shut down requests.

Process Explorer v16.32

By Mark Russinovich

Published: April 28, 2020

Download Process Explorer (2.5 MB)
Run now from Sysinternals Live.

Introduction

Ever wondered which program has a particular file or directory open? Now you can find out. Process Explorer shows you information about which handles and DLLs processes have opened or loaded.

The Process Explorer display consists of two sub-windows. The top window always shows a list of the currently active processes, including the names of their owning accounts, whereas the information displayed in the bottom window depends on the mode that Process Explorer is in: if it is in handle mode you’ll see the handles that the process selected in the top window has opened; if Process Explorer is in DLL mode you’ll see the DLLs and memory-mapped files that the process has loaded. Process Explorer also has a powerful search capability that will quickly show you which processes have particular handles opened or DLLs loaded.

The unique capabilities of Process Explorer make it useful for tracking down DLL-version problems or handle leaks, and provide insight into the way Windows and applications work.

Related Links

• Windows Internals Book The official updates and errata page for the definitive book on Windows internals, by Mark Russinovich and David Solomon.
• Windows Sysinternals Administrator’s Reference The official guide to the Sysinternals utilities by Mark Russinovich and Aaron Margosis, including descriptions of all the tools, their features, how to use them for troubleshooting, and example real-world cases of their use.

Download

Download Process Explorer (2.5 MB)
Run now from Sysinternals Live.

Runs on:

• Client: Windows Vista and higher (Including IA64).
• Server: Windows Server 2008 and higher (Including IA64).

Installation

Simply run Process Explorer (procexp.exe).

The help file describes Process Explorer operation and usage. If you have problems or questions please visit the Process Explorer forum on Technet.

Note on use of symbols

When you configure the path to DBGHELP.DLL and the symbol path uses the symbol server, the location of DBGHELP.DLL also has to contain the SYMSRV.DLL supporting the server paths used. See SymSrv documentation or more information on how to use symbol servers.

Learn More

Here are some other handle and DLL viewing tools and information available at Sysinternals:

• The case of the Unexplained. In this video, Mark describes how he has solved seemingly unsolvable system and application problems on Windows.
• Handle — a command-line handle viewer
• ListDLLs — a command-line DLL viewer
• PsList — local/remote command-line process lister
• PsKill — local/remote command-line process killer
• Defrag Tools: #2 — Process Explorer In this episode of Defrag Tools, Andrew Richards and Larry Larsen show how to use Process Explorer to view the details of processes, both at a point in time and historically.
• Windows Sysinternals Primer: Process Explorer, Process Monitor and More Process Explorer gets a lot of attention in the first Sysinternals Primer delivered by Aaron Margosis and Tim Reckmeyer at TechEd 2010.

—>

Windows System Resource Manager Overview

Applies To: Windows Server 2012

You can use Windows System Resource Manager to allocate processor and memory resources to applications, users, Remote Desktop Services sessions, and Internet Information Services (IIS) application pools.

With Windows System Resource Manager for the Windows ServerВ® 2012 operating system, you can manage server processor and memory usage with standard or custom resource policies. Managing your resources can help ensure that all the services provided by a single server are available on an equal basis or that your resources will always be available to high-priority applications, services, or users.

Windows System Resource Manager only manages processor resources when the combined processor load is greater than 70 percent. This means that it does not actively limit the resources that can be used by each consumer when processor load is low. When there is contention for processor resources, resource allocation policies help ensure minimum resource availability based on the management profile that you define.

Role/Feature description

You can use Windows System Resource Manager to:

Manage system resources (processor and memory) with preconfigured policies, or create custom policies that allocate resources per process, per user, per Remote Desktop Services session, or per Internet Information Services (IIS) application pool.

Use calendar rules to apply different policies at different times without manual intervention or reconfiguration.

Automatically select resource policies that are based on server properties and events (such as cluster events or conditions) or changes to installed physical memory or number of processors.

Collect resource usage data locally or in a custom SQL database. Resource usage data from multiple servers can be consolidated on a single computer running Windows System Resource Manager.

Create a computer group to help organize Remote Desktop Session Host servers that you want to manage. Policies can easily be exported or modified for an entire computer group.

Practical applications

Because Windows ServerВ 2008В R2 is designed to give as many resources as possible to non-operating system tasks, a server running a single role usually does not require resource management. However, when multiple applications and services are installed on a single server, they are not aware of competing processes. An unmanaged application or service will typically use all available resources to complete a task. Thus, it is important to use a tool such as Windows System Resource Manager to manage system resources on multipurpose servers. Using Windows System Resource Manager provides two key benefits:

More services can run on a single server because service availability can be improved through dynamically managed resources.

High-priority users or system administrators can access the system even during times of maximum resource load.

Methods of resource management

Windows System Resource Manager includes five built-in resource management policies that you can use to quickly implement management. In addition, you can create custom resource management policies to meet your specific needs.

Built-in resource management policies

You can enable built-in resource management policies by selecting the type of policy to use. No further configuration is required.

Equal per process

When the Equal_Per_Process resource allocation policy is managing the system, each running process is given equal treatment. For example, if a server that is running ten processes reaches 70 percent processor utilization, Windows System Resource Manager will limit each process to using 10 percent of the processor resources while they are in contention. Note that resources not used by low utilization processes will be allocated to other processes.

When the Equal_Per_User resource allocation policy is managing the system, processes are grouped according to the user account that is running them, and each of these process groups is given equal treatment. For example, if four users are running processes on the server, each user will be allocated 25 percent of the system resources to complete those processes. A user running a single application is allocated the same resources as a user running several applications. This policy is especially useful for application servers.

Equal per session

When the Equal_Per_Session resource allocation policy is managing the system, resources are allocated on an equal basis for each session connected to the system. This policy is for use with RD Session Host servers.

Equal per IIS application pool

When the Equal_Per_IISAppPool resource allocation policy is managing the system, each running IIS application pool is given equal treatment, and applications that are not in an IIS application pool can only use resources that are not being consumed by IIS application pools.

Weighted Remote Sessions

When the Weighted_Remote_Sessions resource allocation policy is managing the system, the processes are grouped according to the priority assigned with the user account. For example, if three users are remotely connected, the user assigned Premium priority will receive highest priority access to the CPU, the user assigned Standard priority will receive second priority to the CPU, and the user assigned Basic priority will receive lowest priority to the CPU. This policy is for use with RD Session Host servers.

When Weighted_Remote_Sessions is set as the managing policy, system management is delegated to the Windows Server 2012 scheduler, and Windows System Resource Manager only profiles the system. Setting or removing Weighted_Remote_Sessions as the managing policy requires a restart of the computer imposed by the kernel.

Custom resource management

You can use custom resource management methods to identify resource users and allocate resources to them based on your own criteria.

Process matching criteria

Enable you to select services or applications to be managed by resource allocation policy rules. You can choose by file name or command, or you can specify users or groups. For example, you could create a process matching criterion that applies management to the application iexplore.exe when it is run by the user Administrator.

Resource allocation policies

Allocate processor and memory resources to processes that are specified by the process matching criteria that you create.

Exclude applications, services, users, or groups from management by Windows System Resource Manager.

Note

You can also use command-line path matching in a resource allocation policy to exclude an application from management by only that policy.

Use a calendar interface to control one-time events or recurring changes to resource allocation. Different resource allocation policies can be active at different times of day, on different days of the week, or according to other scheduling paradigms.

Conditional policy application

Automatically switch resource allocation policies in response to certain system events (such as installing new memory or additional processors, starting or stopping a node, or changing the availability of a resource group in a cluster).

Removed or deprecated functionality

Windows System Resource Manager (WSRM) is deprecated beginning with Windows ServerВ® 2012. You should begin planning now to use alternate methods for any applications, code, or scenarios that depend on this feature. Windows System Resource ManagerВ is an administrative tool that controls how CPU and memory resources are allocated. For more information, see. Deprecated Features for Windows 7 and Windows Server 2008 R2

Note