IIS - The Process Cannot Access the File Because it is Being Used by Another Process


Microsoft IIS

Recently I had some issues with running a local IIS server/website on my local development machine. The solution was fairly well documented, but the surprising culprit and the fact that it had never happened to me before (despite it being a replicable process) made it worthwhile documenting.


Upon trying to start manually start the IIS website the following error message popped up:

Internet Information Services (IIS) Manager: The process cannot access the file because it is being used by another process. (Exception from HRESULT: 0x80070020)


We also get two entries in the System Logs:

IIS-W3SVC (Event ID: 1004): The World Wide Web Publishing Service (WWW Service) did not register the URL prefix http://*:80/ for site 1. The site has been disabled. The data field contains the error number.


HttpEvent (Event ID: 15005): Unable to bind to the underlying transport for [::]:80. The IP Listen-Only list may contain a reference to an interface which may not exist on this machine. The data field contains the error number.


What’s happening here is that something is hogging TCP port 80 and/or 443.


First we need to find out what’s sat on these ports. We can do this using netstat, so open up a command line and use one of the following:

netstat -aon | find ":80"
netstat -aon | find ":443"

The result will be something like the below:

TCP         LISTENING  5484

It’s the and entries marked as listening that are of concern to us. That final number is a Process ID (PID) that we can then use to track down the culprit blocking our ports. We can do this by simply opening up Task Manager and tracking down that PID (ordering by PID helps, you can do this on the Details tab).

Task Manager Processes

Skype - Use port 80 and 443 for additional incoming connections

For me the culprit was Skype grabbing TCP ports 80 and 443 at startup before anyone else could have their say. A bit of a strange one this, as I’ve installed Skype on many machines and never had this issue, what makes it even stranger was that once I had solved the issue, it was still replicable.

The setting responsible for this was found in (Tools - Options) Advanced - Connection, labeled "Use port 80 and 443 for additional incoming connections". Once you disable this setting and restart Skype you will be able to start up your IIS website. The setting is intended as a failover if the port Skype chooses for incoming connections is unavailable but unfortunately it interferes with servers such as IIS or Apache.

Skype Advanced - Connection

So in the war of IIS vs Skype, apparently Skype wins...

Of course, the process responsible for blocking the port won’t always be Skype, but the same investigation steps will still lead you to the process responsible.

I hope this helps you solve this annoying problem that is stopping you from doing something that matters.

Share this article: