Every since the entry into service of IIS 6 (which comes with Windows 2003) the notion of application pools was introduced. An application pool is a means of isolation a web-application, so that the errors it may encounter will not influence other web applications executing on the server or the IIS server itself. If the default settings for an application pool are used a single w3wp.exe process is used to execute the web-applications that are hosted in the pool. In the diagram below, applications A and B are hosted by pool 1 while applications C and D each have their own dedicated pool, pool 2 and pool 3 respectively.
The problem is that when it comes to w3wp.exe processes for the diagram above, there are three of them and just by looking in the task manager there is no easy way to tell them apart. Each instance of a w3wp.exe process has a PID (short for process identifier), but the question is which PID belongs to which application pool.
In IIS 6 (Windows 2003):
The easy way to solve this problem was to call a Visual Basic script file that was located in the %windir%\system32\folder. The file was called iisapp.vbs, and the output of this command listed the instances of w3wp.exe present on the system, their PIDs and to which application pool they belonged to.
In IIS 7 (Windows 2008) and IIS 7.5 (Windows 2008 R2)
The Visual Basic script file has been removed. Most of the IIS 6 script files that were dedicated to a single task (like iisapp.vbs) have been integrated into a command line utility that can be used to administer the IIS server as a whole. This utility is called appcmd.exe and it is located in the %windir%\system32\intesrv\ folder.
CAUTION: to access the tool you must launch the command line prompt with administrator rights, otherwise it will not work. To do this simply right click on a command line short cut and chose 'Run as Administrator' from the context menu.
Then navigate to the folder where appcmd is located and run the following command: appcmd list wp – this will list all the instances of the w3wp.exe process (worker process) that are present on your server with their respective PIDs and application pools.
Other nice commands are appcmd list sites and appcmd list appPools to list the web sites that are present on the server and the application pools on your IIS server. For more information about appcmd, you may continue reading this article:
Getting Started with AppCmd
by Paul Cociuba - French ASP.net / IIS Support Team
If you are anything like me, you have developed ASP.net applications, debugged them using Visual Studio
Alternatively, if you go into IIS Manager, click on the server in the left nav pane, then open 'Worker Processes' from the IIS heading on the main window, you will see a list of the App Pools as well as their PIDs, CPU usage, etc.
Note: Someone needs to be connected to your website in order for the Worker Process to be displayed in the Worker Process tab or the "appcmd list wp" command. This is a new feature of IIS 7, consolidating the number of processes running by only instantiating the application pool's process when someone connects to the specific website.
@Brian: actually application pools by default (even in IIS 6) will only spawn a worker process (w3wp.exe) on the first request to a web-application hoted by that particular pool. The w3wp.exe instance will then remain alive for another 20 minutes (assuming default settings) and if no other requests for that application pool come in, IIS will shut the w3wp.exe down - remark that the pool is still active. The setting that controls this is the Idle Timeout in both IIS 6 and 7.
Have a look at the architecture videos I have publish on IIS 7.5 - this should make the app pool concept clearer: http://linqto.me/IISArchP1 and http://linqto.me/IISArchP2
Thank you so much!
Thanks for the article. I find Debug diagnostic tool very handy: www.microsoft.com/.../details.aspx
The folder intesrv does not exist on my server.
As Fran mentioned, the intesrv folder does not exist. In other words, there is a tiny typo where the folder is originally mentioned in the article. Should be inetsrv. Other than that, terrific article! Thanks!