Understanding which process to use for tracing or taking a dump can be difficult if you are not familiar with where to look.  This sections covers the where to look part.

 

Desktop Application:

Desktop applications will appear in their own process. 

 

COM+ Application:

If the COM+ service is running or hung, you can find the PID for the instance of “dllhost.exe” (used to run COM+ DLLs) by using the following command from a command prompt:

 

tasklist /svc /fi "imagename eq dllhost.exe"

 

You may need to have the calling program create an instance of the COM+ application so that it is actually executing and would thus have a process and process ID that can be attached to. The idea would be to instance the COM+ object, have something in the calling code which would pause while you attach the debugger and then have the calling code call the failing method of the COM+ component.

 

Windows Service:

Windows services can run under their own processes or under “svchost.exe”.  If they are running under their own process, you should be able to find them listed with normal desktop applications using Task Manager, etc.  However, if they are running under “svchost.exe”, then you will need to locate the appropriate process using something like tasklist – below is an example:

 

tasklist /svc /fi "imagename eq svchost.exe"

 

Exchange under IIS:

An application pool is a group is configured so that applications belonging to it can run under settings which will be isolated from other applications.  Each application pool runs in its own worker process.  By default Exchange Application pools run under the identity of the Local System account.  An identity is the service account running the pool of applications.  It’s important to not mess with the Identity of which any Exchange server application runs since it may cause problems which may not be immediately apparent.

 

Exchange 2007 Application Pools:

 

Virtual directory

Application pool

Identity

ASP.NET, .NET Web Services

Classic .NET AppPool

NetworkService

ASP/HTML

DefaultAppPool

NetworkService

/AutoDiscover

MSExchangeAutodiscoverAppPool

 

LocalSystem

 

Exchange Web Service

MSExchangeServicesAppPool

 

LocalSystem

 

Exchange ActiveSync

MSExchangeSyncAppPool

 

LocalSystem

 

OAB

DefaultAppPool

 

NetworkService

 

/Exadmin

/Exchange

/Exchweb

/owa

/public

MSExchangeOWAAppPool

 

LocalSystem

 

Unified Messaging

MSExchangeUMAppPool

 

LocalSystem

 

 

Exchange 2010 Application Pools:

 

Virtual directory

Application pool

Identity

ASP.NET, .NET Web Services

Classic .NET AppPool

NetworkService

ASP/HTML

DefaultAppPool

NetworkService

AutoDiscover

MSExchangeAutodiscoverAppPool

 

LocalSystem

 

Exchange Web Service

MSExchangeServicesAppPool

 

LocalSystem

 

Exchange ActiveSync

MSExchangeSyncAppPool

 

LocalSystem

 

OAB

DefaultAppPool

 

NetworkService

 

OWA

MSExchangeOWAAppPool

 

LocalSystem

 

Unified Messaging

MSExchangeUMAppPool

 

LocalSystem

 

 

Each of these application pools will run under an instance of w3wp.exe.  Use the Process ID (PID) of the w3wp.exe process hosting the IIS application pool used by your application.  

 

On an Exchange server, there will likely be three or more application pools running.  If you have multiple instances of w3wp.exe running, you will need the PID of the W3WP.exe running the application pool that your application is running in.  If you pick the PID of the wrong W3WP.exe, the trace log will not include your code execution.  You can list the PIDs for each W3WP process and its respective application pool using the following from the command line:

 

For IIS6, use: 

                C:\WINDOWS\System32\cscript.exe iisapp.vbs

 

For IIS7, use: 

                C:\Windows\System32\inetsrv>appcmd list wp

 

Note that the application pool needs to be running in order for the above commands to work.  If you are running a custom application under IIS and the application pool it runs under is not running, then you should run the application to get the application pool started.

 

The Exchange Server Analyzer Tool will check the application pool settings to be sure that they are correct.  If the application pools are not configured properly, Exchange may not function properly.

 

A virtual directory is running under an incorrect application pool

http://technet.microsoft.com/en-us/library/dd577064(EXCHG.80).aspx

 

Exchange 2007:

 

Auto discover:

PID of the “MSExchangeAutodiscoverAppPool” W3WP.exe application pool on the CAS server.

 

If the problem is in transport:

PID of  “MSExchangeTransport.exe” This would be on the Hub Transport or Edge Transport server.

 

If the problem is in a transport custom transport agent:

PID of  “MSExchangeTransport.exe” where the agent is registered.  This would be the Hub Transport or Edge Transport server.

 

If the problem is with EWS:

PID of the “MSExchangeServicesAppPool” W3WP.exe application pool on the CAS server.

 

If the problem is in XSO when EWS is used: 

PID of the “MSExchangeServicesAppPool W3WP.exe application pool on the CAS server.

 

If the problem in XSO when EWS is used repros in OWA and you want to see what OWA does:

 PID of the “MSExchangeServicesAppPool” W3WP.exe application pool on the CAS server.

 

WebDAV:

PID of “MSExchangeOWAAppPool” W3WP.exe application pool on the CAS server.

 

Custom ASPX or web service which calls a Microsoft API.

PID of the ”Classic .NET AppPool” W3WP.exe application pool.

 

Custom ASP or HTML page calling a Microsoft API.

PID of the “DefaultAppPool” W3WP.exe application pool.

 

Exchange 2010:

 

Auto Discover

PID of the MSExchangeAutodiscoverAppPool W3WP.exe application pool on the CAS server.

 

If the problem is in transport:

PID of  “MSExchangeTransport.exe” This would be the Hub Transport or Edge Transport server.

 

If the problem is in a transport custom transport agent:

PID of  “MSExchangeTransport.exe” where the agent is registered. This would be on the Hub Transport or Edge Transport server.

 

If the problem is with EWS:

PID of the “MSExchangeServicesAppPool” W3WP.exe application pool on the CAS server.

 

If the problem is in XSO when EWS is used:  

PID of the “MSExchangeServicesAppPool W3WP.exe application pool on the CAS server.

 

If the problem in XSO when EWS is used repros in OWA and you want to see what OWA does:

PID of the “MSExchangeServicesAppPool” W3WP.exe application pool on the CAS server.

 

EWS call connectivity error:

PID of the MSExchangeServicesAppPool W3WP.exe application pool on the CAS server.

 

WebDAV:

Exchange 2010 does not support WebDAV.

 

Custom ASPX or web service which calls a Microsoft API:

PID of the Classic .NET AppPool W3WP.exe application pool

 

Custom ASP or HTML page which calls a Microsoft API:

PID of the DefaultAppPool W3WP.exe application pool

 

Exchange Store Service:

Exchange Mailbox Servers (2007 and 2010)  execute under the “Microsoft  Exchange Information Store” service - the service name is called “MSExchangeIS”.  This service controls the running of store.exe which is located in the "bin" folder of the Exchange installation folder:

 

Example from an Exchange 2010 server:

C:\Program Files\Microsoft\Exchange Server V14\bin\store.exe

 

Example from an Exchange 2007 server:

C:\Program Files\Microsoft\Exchange Server\bin\store.exe

 

You can get the process ID (PID) for store.exe by running the following command line from the mailbox server:

               

                tasklist /svc /fi "imagename eq store.exe"

 

The size of the store.exe process may be quite large.  This is usually normal, however you should be aware of this if you need to take a dump or IDNA trace - you would want to check to be sure that there is suffient disk space before taking a dump or trace.   If your interested on why it groes so large, read the article below:

Understanding Exchange 2007 Memory Usage and its use of the Paging File
http://msexchangeteam.com/archive/2008/08/06/449484.aspx

With the exception of MAPI against Exchange 2007, APIs do not go directly against the store process.  Read more about MAPI and against Exchange below.

MAPI Service on Exchange:

MAPI clients communicate using EMSMDB32 to talk to a process running on the Exchange server over RPC.  The service Exchange uses is different in Exchange 2010 from prior versions of Exchange.   

 

2007 and prior:

MAPI clients communicate to the backend server.   MAPI executes Store.exe service on the mailbox server.  The “Microsoft  Exchange Information Store” store process controls Store.exe.

 

 

 

For further reading:

How Outlook, CDO, MAPI, and Providers Work Together

http://technet.microsoft.com/en-us/library/aa996249(EXCHG.65).aspx  

Exchange 2010:

MAPI clients don’t connect to the mailbox server under 2010, they connect to the RPC Client Access service on the CAS which you will see running under the “Microsoft.Exchange.RpcClientAccess.Service.exe” service. The “Microsoft Exchange RPC Client Access” Service manages the  “Microsoft.Exchange.RpcClientAccess.Service.exe” process.

Here is suggested reading if you want detailed information on RPC related to Exchange 2010:

 

Uncovering the new RPC Client Access Service in Exchange 2010 (Part 1)         

Uncovering the new RPC Client Access Service in Exchange 2010 (Part 2) 
Uncovering the new RPC Client Access Service in Exchange 2010 (Part 3)
Uncovering the new RPC Client Access Service in Exchange 2010 (Part 4)

Outlook:

Outlook runs under outlook.exe (go figure).  For Outlook 2007 (12), it is normally installed under C:\Program Files\Microsoft Office\Office12 in the Program Files folder. 

 

Note: Outlook Add-ins also run under Outlook’s process as they are DLLs.  Outlook will catch exceptions which are not caught by an add-in.    Be aware of this when looking at dumps, etc.