Application pools and Windows processes

IIS6 uses application pools, where a server process named w3wp.exe services requests for a collection of web sites. Which sites are in which application pool is set as a site property. You can determine easily enough which sites are in each pool from IIS Manager, but what if you need to know which Windows process an application pool is running under? Hint: the processes are all named w3wp.exe. :)

Fear not young padawan, there is a handy little script included that will tell you just that. Drop to the command line and enter cscript %windir%\system32\iisapp.vbs (although you may be able to just enter iisapp.vbs depending on server configuration). So for example iisapp.vbs | sort would give you output like this:

W3WP.exe PID: 1088   AppPoolId: ASP2C-AppPool
W3WP.exe PID: 1356   AppPoolId: ASP1C-AppPool
W3WP.exe PID: 1800   AppPoolId: ASP2A-AppPool
W3WP.exe PID: 2356   AppPoolId: ASP1A-AppPool
W3WP.exe PID: 4148   AppPoolId: ASP1-CCApp-AppPool
W3WP.exe PID: 4484   AppPoolId: ASP1-Jobs-AppPool
W3WP.exe PID: 4820   AppPoolId: ASP1-Purchased-AppPool
W3WP.exe PID: 5020   AppPoolId: ASP2B-AppPool
W3WP.exe PID: 5964   AppPoolId: ASP1B-AppPool

You can see the Windows PIDs for each process using the command-line utility tasklist, or customize the Windows Task Manager to display the PID. For example, tasklist | find “w3wp.exe” | sort will yield something that looks like this:

w3wp.exe                      1088 Console                    0    121,956 K
w3wp.exe                      1356 Console                    0    160,040 K
w3wp.exe                      1800 Console                    0    170,408 K
w3wp.exe                      2356 Console                    0     53,264 K
w3wp.exe                      4148 Console                    0     38,592 K
w3wp.exe                      4484 Console                    0    119,088 K
w3wp.exe                      4820 Console                    0     18,380 K
w3wp.exe                      5020 Console                    0     13,604 K
w3wp.exe                      5964 Console                    0    138,344 K

This can come in particularly handy when you have a process out of control and need to know which application pool is in trouble.

Starting a VMware guest freezes Vista

VMs are indispensable for testing software. At work, I had previously used VMware Server 1.x on Windows XP without any real problems. Unlike Workstation which might actually be better for test VMs, Server is free, and it is always easier to use free than to get approval for the company to spend money. So when I recently received a new laptop as part of the standard hardware replacement cycle at work, I updated to Vista. This was after it was ordered with XP because Vista is not approved software, and exceptions are too much bother to get but it is already covered under our licensing with Microsoft. But I digress… So of course I loaded VMware on it, but being Vista I expected I might run into some problems. I was not disappointed. It went fine for the most part, probably because I do run as a local administrator and had already disabled the very annoying UAC (User Account Control). However, when starting a VM, Vista would be completely, totally, utterly unresponsive for 5 minutes or more while the hard drive activity light went solid. Sigh.

I found some information on tweaking AV exclusions or this or that VMware setting, to no avail until I found an article that had information that actually solved the problem. It turns out to be aggressive swapping, whether Vista or VMware I am not entirely clear. The trick to the whole thing – in my situation anyway – was to set the host settings such that VMware did not allow swapping out the guest but rather kept it in RAM. I have 4G so this was not a problem for me. You will find the setting under menu item Host->Settings, over on the Memory tab. Be sure to set aside the maximum you will ever want to use concurrently, and add some for VMware overhead. I used an extra 512M but you can likely get by with 256M or maybe less. Then, and this is the most important part, select the option to Fit all virtual machine memory into reserved host RAM which is not the default. That is really the core of the solution, once you have enough memory allocated. Incidentally, VMware will tell you if you didn’t give it enough memory when you try to start a VM that pushes it over the limit.

Not ideal as you do need a fair bit of RAM, but it does solve the problem.

Eliminating DCOM errors

I recently encountered a DCOM error repeating numerous times in the event logs on a SharePoint server, which eventually led to a resolution I am about to explain. But DCOM errors are certainly not exclusive to SharePoint, and I have personally seen this error occur with a number of applications. The method presented here can be used to try and resolve similar issues regardless of the software involved.

I also need to say that much of this was drawn from a post by Søren Nielsen where he solved a SharePoint DCOM error. If you administer SharePoint, I highly recommend his blog, particularly for more advanced technical topics. He has a knack for tracking down the oddball things that are often found on SharePoint servers. Now, on to the solution to the problem…

The preceeding screenshot is what I was seeing in the event viewer. There are two things to note in this event, besides it being a DCOM error. First, the CLSID is a reference to the software component that generated the error. Second, the description indicates that the user – scrubbed out here - is lacking the “Local Activation” permissions. You can also see a hint as to where you fix the problem – using the “Component Services administrative tool”.

We are first going to search the registry to figure out the name of the software component generating the error. The CLSID is rather lengthy, so I recommend you select the string in the event viewer and press Ctrl-C to copy it to the clipboard. Open the registry editor (Start, Run, and enter regedit). Scroll the left-hand pane all the way to the top and select My Computer, then select Find under the Edit menu. Paste (or type if you must) the CLSID into the Find what textbox, and Keys should be checked under Look at. Click Find Next until the path to the key displayed on the status bar looks like My Computer\HKEY_CLASSES_ROOT\CLSID\yourCLSID and regedit looks something like this:

Take a look at the (Default) value for the name of the component. In some cases like the SharePoint component shown, you may have subkeys. If you do, also take a look at what values are in them. In this case, VersionIndependentProgID was helpful to me as it ultimately contained the name of the component as a prefix to the (Default) value.

We should now have enough information to fix the problem. Click Start, select Run, and enter dcomcnfg to open the Component Services administration snapin. Expand Component Services, then Computer, then My Computer, and finally DCOM Config. On a typical server, you will see many components are installed. Look for one with the name you found in the registry; in my case it was OSearch from the VersionIndependentProgID key as mentioned above. It is critical that you find the right component, otherwise none of the remaining steps are going to fix anything and you may inadvertenly cause other problems, or potentially even open a security hole.

Right-click the component, in my case OSearch, and select Properties, then select the Security tab. The Launch and Activation Permissions is where you fix the problem, so in that groupbox, select Customize if it isn’t already selected then click the Edit button. You should see something like the following:

The user identified in the event needs to be in the list of user names. If not, click Add and use the standard dialogs to add the user to the list. Highlight the user, then ensure that Local Launch and Local Activation are selected, then click OKs until you close all dialogs. That should fix the problem!

It always seems so simple after you know the solution… :)