As a followup to yesterday's post on resolving listener and activation errors, here's an additional point to consider while attempting to diagnose a problem. Once you've found where the failure symptoms first appear, whether that be in the service, the listener, or in the host application, you still have to do some more searching to find the root cause of the failure. This is always true when debugging, but it's a particular issue when you're trying to diagnose the cause of failure based on an indirect observation, such as a service not starting, rather than a direct observation.

As an example, consider the basic case where IIS is running successfully for HTTP services but your non-HTTP services won't activate. Your services have two dependencies, one pointing towards the service configuration and another pointing towards the infrastructure. Following the dependency tree towards the infrastructure, it has multiple dependencies, one pointing towards the specific protocol listener that receives the first message and another pointing towards WAS, which performs the generic process management. The specific protocol listener in turn has more dependencies, such as the configuration, the application pools using the listener, and so on.

Diagnosing problems quickly becomes a learned skill based on building a mental model for how the activation components work in sequence. This is another reason why I recommended having a particular order of investigation in the previous post because it's easier to pin the blame on a component when you can rule out the cause being that component's dependencies.