Here at Cheezburger we run on two main platforms – ASP.NET powers cheezburger.com, and WordPress powers all of our content sites. This requires us to run both locally to develop against. A common setup on the team is to use IIS Express or Cassini on any arbitrary port to run the ASP.NET applications, and WampServer on port 80 to run WordPress.

This has worked well…until today when Apache decided that it wouldn’t start.

tl;dr

If Apache won’t start on Windows, you don’t have IIS installed, Skype isn’t being dumb, and you have the Web Deployment Tool installed, then try disabling the Web Deployment Agent Service.

Not the usual culprits

I typically do not run full IIS on my dev machine due to port contention like this and using IIS Express is just easier.

A quick check of the Windows Features confirmed that it was not installed.

The next most common issue is that for some dumb reason Skype will claim ports 80 and 443 with its default settings. I’d just upgraded Skype, so it was worth checking.

Nope, that option stayed unselected after the upgrade.

Digging deeper

Having ruled out the most common programs that could claim port 80, I downloaded one of the many terrific Sysinternals tools, TCPView, which shows detailed information about all open TCP connections on your system.

Now we know that the port is being held by the system…not exactly something we can simply whack on the head. Unlike the many svchost processes running on your system, Process Explorer can’t tell you what all is running in System.

WampServer also has a utility for checking the status of port 80.

That gives us a little more detail – even without IIS installed HTTP.SYS, the kernel-mode HTTP driver, is still listening for HTTP requests.

Jackpot!

Just as I was about to give up and just change Apache’s port, Scott Hanselman posted an article about using SSL with IIS Express, including reference to the netsh command. Scott was using it to add an entry for HTTP.SYS, but maybe it could show me what is behind the port snatching?

netsh http show urlacl

Looks like the Web Deploy agent is what is preventing Apache from using port 80. According to Programs and Features, I just happened to have gotten an updated version today as well, probably from the Web Platform Installer while getting the MVC 3 Tools Update and other items updated the same day.

Rather than uninstalling Web Deploy I opted to disable the Web Deployment Agent Service, which had been set to start automatically. After making this change Apache is now able to start!

Given this appears to be new with the latest version of the Web Deploy Tool, I’m not sure what ramifications there may be from disabling this service locally. My best guess is something to do with WebMatrix.