Windows – How to find which actual application uses port 80 via the System process

portwindows

TL;DR

An application is listening on TCP port 80, but the process listed when I run netstat or TcpView from the SysInternals tools is System. I want to know which application is really listening on this port.

I have read this question, and tried running netstat, but it didn't help finding the actual application which uses port 80. The PID it gave me was 4, which corresponds to System. If I try to open a browser on localhost:80, it only gives me a basic 404 page ("HTTP Error 404. The requested resource is not found.").

I tried using a simple HTTP request via telnet, and I got the following:

                       HTTP/1.1 400 Bad Request
Content-Type: text/html; charset=us-ascii
Server: Microsoft-HTTPAPI/2.0
Date: Thu, 28 Jul 2016 19:22:42 GMT
Connection: close
Content-Length: 334

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN""http://www.w3.org/TR/html4/strict.dtd">
<HTML><HEAD><TITLE>Bad Request</TITLE>
<META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii"></HEAD>
<BODY><h2>Bad Request - Invalid Hostname</h2>
<hr><p>HTTP Error 400. The request hostname is invalid.</p>
</BODY></HTML>

Is there another way to find out which application is blocking my port 80 through the System process? I'm using Windows 7.

Update

Here's an extract of the output when I run netstat -anbo | findstr :80:

TCP    0.0.0.0:80             0.0.0.0:0              LISTENING       4
TCP    0.0.0.0:8000           0.0.0.0:0              LISTENING       3900
TCP    0.0.0.0:8081           0.0.0.0:0              LISTENING       2876

And it's impossible to start our own HTTP server because port 80 is already in use.

Update2

We found out which application was using the port afterall (see my answer). However, I'm curious to see if anyone has a collection of tricks to speed up the process of finding which application uses a port in the case where it is using it via the System process (and not in the case where a virus is emulating the System process, as suggested by Steven).

Best Answer

We finally found the culprit. In our case, it was the BranchCache service. From what we learned, this service uses TCP port 80 by default, and our IT service didn't change the default configuration. Stopping this service freed the port 80.

We had to manually stop every services on our computer, until we found the service which actually used port 80. This can lead to weird behaviors though, so I'm not fully sure this is the best way to get the information.

Related Question