How does the Module filter work?

Unless you are prepared to deal with much larger Performance Sentry data files than usual, you should use appropriate filter settings when you collect Module data. Collecting the Module information is costly, and the average Windows Server executable routinely loads 50-100 assorted DLLs. Please be careful with this new function and implement a Module filter for all container processes that you need to resolve.
A screen shot that illustrates how the Module filter works is shown below in Figure 1:

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.