I‘m not yet clear what I did, but I‘m blogging it so it can be found if someone else has this issue.

For whatever reason, last week both of my Vista 64-bit machines suddenly stopped being able to start IIS (Internet Information Server). The service just wouldn‘t start. I started getting this error instead "Cannot start service W3SVC on Computer ‘.‘" which wasn‘t too helpful.

A visit to the System Event Log via the Event Viewer in Computer Management told me these four errors:

"The World Wide Web Publishing Service service depends on the Windows Process Activation Service service which failed to start because of the following error: The system cannot find the file specified."

and

"The Windows Process Activation Service service terminated with the following error: 
The system cannot find the file specified."

and

"Windows Process Activation Service (WAS) is stopping because it encountered an error. The data field contains the error number."

and

"The directory specified for the temporary application pool config files is either missing or is not accessible by the Windows Process Activation Service. Please specify an existing directory and/or ensure that it has proper access flags. The data field contains the error number."

Unfortunately there‘s little information to go on in any of these error messages. However, it‘s clear (as mud) from the last error that there‘s a directory missing or not accessible. I‘ll add "anymore" to that because it worked before. That means that something changed.

If IIS won‘t start because Windows Process Activation Service won‘t start, then I need to get WAS started up first. However, I don‘t know what directory it doesn‘t have access to.

I can see from the Services application that WAS isn‘t its own executable, but rather lives inside of an instance of svchost.exe, where a lot of services live.

So I‘ll fire up Process Monitor and set the filters (filters are VERY important if you want to avoid being overwhelmed quickly in procmon) to show only svchost.exe processes.

Even still, there‘s a lot of svchost.exe processes out there and they will quickly fill the monitor up. I‘ll need to setup some strategic (read: guessed) highlighting as well.

The hotkey to stop capturing in procmon.exe is Ctrl-E. Basically I‘ll clear the screen, hit Ctrl-E to capture, try to start WAS (pronounced WAAZ), watch it fail, the stop capture with Ctrl-E.

Based on the vague message about application pools temporary files and a directory I‘ll make a guess and configure highlighting to find paths that contain "temp," "log," "config" or "app" in Process Monitor as seen in the screenshot below.

After I run the capture, I scroll around looking for suspicious stuff. One of the nice things about Process Monitor is that you can EXCLUDE things in a given capture after that fact. For example, I saw a pile of Audio and Media related stuff that was visually confusing and cluttering the point, so I excluded it.

The result is here:

It looks like there SHOULD be a folder call c:\inetpub\temp\apppools and on my Vista 64 machines, in the last two weeks to a month, it just disappeared. No idea why. I just noticed recently when I tried to move from a local web development service to IIS itself.

I created the folder, started WAS, then IIS and I was back up and running.

I‘ll pass the feedback on to the WAS team about the obscure error messages, but I thought I‘d share this little ten minute debugging session to point out a few things that I think are important and possibly helpful, Dear Reader:

• Know What Your Processes Are Doing (or at least, know how to find out)
• Knowing how to look INSIDE the Windows "Black Box" using tools like ProcMon makes you realize that no OS is a Black Box at all. It‘s very empowering to know that you CAN see inside.
• TASK: Learn Process Monitor and Process Explorer.
• Enable Your Intuition
• Debugging is 95% tools and 5% intuition. Know what tools can get you that next bit of information you need to take the next step in your analysis.
• If you feel you‘ve hit a wall in your analysis, knock that wall down. Your process is doing IO to a file/registry/device/network/etc. Watch it. Look for failures.