Figure 1.
This filter definition instructs the collector to report Module instances only for the dllhost.exe and svchost.exe processes. In addition, only the specific Module instances named will be collected, which is the information needed to identify the application running inside these container processes.

On a typical Windows XP or Windows Server machine, you will several instances of the svchost container processor executing. svchost is a container process that hosts various system services. Different services run in different copies of svchost depending on their security requirements. You will see them identified with different Used Names in Task Manager, for example. For instance, services that do not need network access with execute inside a copy of svchost that executes under the security profile associated with local service. Other copies of svchost run under the SYSTEM or NETWORK SERVICE. In order to figure out which services are running inside which copy of svchost, use this Module filter definition to identify modules that are unique to a specific instance of svchost.
With this filter definition active, we expect to report:

1. one instance of the Module Object for browser.dll associated with a specific svchost.exe parent process and
2. another instance of the Module Object for rpcss.dll associated with a different svchost.exe parent
3. another instance of the Module Object for regsvc.dll associated with a different svchost.exe parent
4. another instance of the Module Object for winspool.drv associated with a different svchost.exe parent

Using the SAS Merge function, you could then report process level statistics for the svchost container process by application.

Similarly, for dllhost.exe, filtering on wam.dll will allow you to identify specific instances of dllhost that are executing ASP script code. COM programs executing inside the mtx.exe container process and COM+ programs executing inside the dllhost.exe container process can be identified, too, if you build a filter list of component application DLLs. To populate the Module filter list, use the “Browse for Modules” function to point to a folder where these component application DLLs reside in your installation. You should wind up up with something that looks like the Module Filter definition in Figure 2:

Figure 2.
The effect of this filter is to report a Module instance associated with each process instance of dllhost.exe where the COM+ components dasserver.dll or gam.dll are loaded.

To populate the Module filter list that is illustrated in Figure 2 for either dllhost.exe or mtx.exe, use the “Browse for Modules” function to point to a folder where these component application DLLs reside in your installation. If necessary, use the Component Services Explorer (CSE) applet, illustrated in Figure 3, to locate the names of the COM+ modules that want to resolve. (CSE is available under Administrative Tools.)

Figure 3.
Using CSE, drill down to Component Services, My Computer,  and determine what COM+ Server applications are installed. COM+ Server applications are identified by an icon that shows the component residing inside a box, which represents the dllhost.exe (or mtx.exe) container process (e.g., IIS Out-of-Process Pooled Applications). The icon for COM+ Library applications shows the component being loaded into the calling process (e.g., IIS In-Process Applications).  If you are not sure if the COM+ component is a Library or Service application, right-click to access the Component Properties and check the Activation tab, as illustrated in Figure 4.

Figure 4.
Only COM+ Server applications that are activated in a dedicated local server container process (dllhost.exe or mtx.exe), as shown, need Module name resolution.

Finally, find out the COM+ component module name so that you can prepared the Module Filter definition. Drill down to the COM+ Components and right-click to access Component properties. Under the General tab, illustrated in Figure 5, the fully qualified DLL module name is shown. Enter the Module name shown, without any elements of the path, in the dllhost.exe or mtx.exe Filter definition.

Figure 5.
In this example, the GAM.dll, a COM+ component associated with the Microsoft sample FMStocks application, is defined as a Server application. When the FMStocks application calls this component, it executes inside an instance of dllhost.exe. When the NTSMF collection services finds an instance of dllhost.exe with gam.dll running inside it (the module name is not case-sensitive), it generates a Module Object instance associated with gam.dll, that shows a parent instance of dllhost.exe. Since there are likely to be multiple copies of dllhost.exe executing, the Module instance record contains an ID Process Counter that identifies the unique instance of the dllhost container process where the Module is loaded and executing. In reporting on COM+ components, we suggest you Merge the Module name with its associated Process records, based on ID Process, and report the Module name, rather than the uninformative name of the dllhost container process.

The Module data is for identification purposes. The only Counters available for each Module are the process ID, which is used to identify the parent process uniquely, and the Load Address of the Module within the parent process virtual address space.

The Module data is intended to assist in identifying the application being executed within a container process, which is something we notice occurring more and more frequently in Windows Server. There are three specific container processes that you are likely to collect Module Object information about: mtx.exe in Windows NT 4.0, dllhost.exe and svchost.exe in Windows Server and XP. The function of these container processes is described below:

mtx.exe is a container processes used by the Microsoft Transaction Server (mts) to execute COM components (which are DLLs). When COM program DLLs are loaded as server components and execute out-of-process, the component is executed inside the mtx.exe container process.

dllhost.exe is the Windows Server version of mtx.exe that executes COM+ components. When COM+ program DLLs are loaded as server components and execute out-of-process, the component is executed inside the dllhost.exe container process. dllhost.exe is also used to execute Active Server Pages application scripts in IIS in separate container processes, when Medium or High Application Protection is specified. Medium Application Protection, a runtime option introduced with IIS and is the default setting, leads to all ASP script running inside a single copy of dllhost.exe. When a High level of Application Protection is chosen, each ASP script executes in an isolated instance of dllhost.exe. ASP scripts can be identified inside dllhost.exe by looking for the presence of wam.dll.
svchost.exe is used in Windows XP to host system services like Browser, Redirector, and Server. In Windows XP, those system services that used to execute within the services.exe container process in earlier versions of Windows NT, are arrayed across multiple instances of the svchost process, each executing under a different security profile, either SYSTEM, LOCAL SERVICE, or NETWORK SERVICE.

If you are experiencing application-related performance problems and notice lots of mtx.exe or dllhost.exe processes executing, use the Module function to identify which applications were running inside which container processes. During reporting Merge the Module instance with the parent process, using the ID Process field to uniquely identify specific processes, and replace the generic process name with the Module instance name.

To function correctly, the User Account that the Performance Sentry Collection Service runs under requires the following User Rights:

	Logon as a service
	Increase scheduling priority

with the following Registry Key Permissions (in Windows 2000 and above):

	Read access to the Registry key HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib
	Read access to the Registry key HKLM\\SYSTEM\CurrentControlSet\Services
	Control access to the Registry key HKLM\\SYSTEM\CurrentControlSet\Services\Dmperfss. Note that this Registry key is created by the system’s Service Control Manager when the Performance Sentry collection service (dmperfss.exe) is installed.

A sample installation script that installs the the Performance Sentry collection service under a User Account and grants these local Registry Key Permissions to the Account is shown below. The subinacl utility used here to grant Registry Key permissions is available in the Windows Server Resource Kit.

net stop “Performance Sentry”
dmperfss -remove
dmperfss -install -fdevncci.dcs -accountdomain\username -passwordpassword
subinacl /verbose /keyreg “SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib”  /grant=domain\username
subinacl /verbose /keyreg “SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib\009″  /grant=domain\username
subinacl /verbose /keyreg “SYSTEM\CurrentControlSet\Services\DMPerfss”  /grant=domain\username
subinacl /verbose /keyreg “SYSTEM\CurrentControlSet\Services\DMPerfss\Control” /grant=domain\username
subinacl /verbose /keyreg “SYSTEM\CurrentControlSet\Services\DMPerfss\Security” /grant=domain\username
net start “Performance Sentry”

and with the following Folder Permissions:

	Control access to the NTSMF \data\ Folder and subFolders where the .smf data file is written.
	Control access to any shared Network folders that the Cycle End Command or command script requires access to.

In addition, some Performance Library DLLs that the Performance SeNTry collection service will attempt to load and run may reside in secure folders. You will need to grant the User Account the collection service runs under Read access to the folders. During the Discovery phase of each collection cycle, when the collection service attempts to load the Perflib DLL modules, the Load will fail. You will see a Warning message similar to the following in the Application Event log or the local <computername>.ntsmf.log message file:

In this example, in order for the Performance Sentry collection service to load the SQLCTR80.dll Performance Library DLL that is responsible for gathering SQL Server 2000 performance Objects and Counters successfully, you must first grant Read Access to the C:\Program Files\Microsoft SQL Server\MSSQL\Binn Folder where SQLCTR80.dll resides to the Performance Sentry agent User Account.

The Performance Sentry Collection Service performs two sets of functions where security considerations may apply:

1. Control the Performance Sentry data and log files in the \data\ Folder. You can normally tell that the NTSMF \data\ Folder is protected from uncontrolled access by the LocalSystem account if the service terminates prematurely at start-up and no <computername>.ntsmf.logfile is generated in the NTSMF \data\ Folder. 
2. Execute the Cycle End command or command script. The Cycle End command or command script runs in a separate process that inherits its Authority from the Performance Sentry service process that creates it. If the Cycle End command or command script fails to complete successfully, but works fine when you execute it under your Logon Account, your Logon Account probably has Folder Permissions that are not granted to the LocalSystem account.

There are two ways to authorize the collection service to perform these secure functions:

1. If you have implemented Active Directory, it is possible to grant the LocalSystem (or SYSTEM) Account the Folder Permissions required to access secured network resources. The LocalSystem Account corresponds to the named Computer in Active Directory. However, some installations prefer not to grant the LocalSystem (or SYSTEM) Account any Folder Permissions.
2. You may assign a User Account with access to the appropriate network resources that  the collection service will impersonate whenever it performs one of the two secured functions discussed above.

Impersonation allows the collection service to adopt temporarily a different security identifier (SID) than the the one specified when the service is started. You assign the User Account and Password that the collection service will impersonate when you install the collection service. The User Account you assign will be used whenever the collection services performs any function that might need to done under a security context other than LocalSystem (or SYSTEM). If you assign a User Account and Password during installation of the collection service, the collection service will impersonate that User Account when it launches the Cycle End command. This allows the Cycle End command or script to execute under a User Account that is authorized to perform network file operations on a secure shared folder. In addition, if the NTSMF \data\ Folder is protected from uncontrolled access by the LocalSystem account, you may need to assign Performance Sentry a User Account to impersonate when it performs any function that accesses the \data\ Folder.

You assign the User Account to be impersonated during the Performance Sentry Collection Service installation using the -account and -password options, as illustrated below:
     dmperfss -install -f MyDCS.dcs -account DomainName\myAccount -password xxxxxxx

You may also assign the User Account by using the automation interface command dmcmd.exe found in the root NTSMF folder: 
     dmcmd.exe -account DomainName\myAccount -password xxxxxxx

For more details, see Chapter 2 of the User’s Manual.

More specifically, the Module collection function requires the PROCESS_QUERY_INFORMATION process-specific access right, which can only be granted programmatically by a process running with System level privileges to begin with. Unfortunately, there is no User Right that you can grant a User Account that allows the Performance Sentry collection service to execute the EnumProcessModules Win32 function call it makes to enumerate all the modules loaded in a process.

You can run the Performance Sentry collection service under a User Account by following the guidelines discussed in the other questions under this category. All collection service functions will execute normally, once you grant the User Account the appropriate User Rights and Permissions. However, the Module collection function, introduced in version 2.4.4 will not run under a User Account. In order to collect Module identification data, you must run under the built-in LocalSystem (or SYSTEM) Account.