I am trying to use port 80 for my application server, but when I perform "netstat -aon" I get


When I look up the process in task manager, it shows PID 4 is SYSTEM, thats it, not extension... nothing, just "SYSTEM". Whats going on here?

I'm afraid to end this process, what do I do?

  • net stop http WORKED FOR ME Mar 26, 2020 at 14:30

10 Answers 10


Although people are pointing out specific services (e.g. the "Web Deployment Agent Service"), this fails to address the root cause. If you just disable services that trigger the problem, chances are it will rear its head again in the future in a marginally different guise. So it's worth understanding what's going wrong, because that leads to a better fix.

This problem arises when an application server wants total control of port 80. This conflicts with a feature of Windows that is designed to enable multiple processes to handle requests on port 80. It's entirely possible to have any number of processes all receiving HTTP requests on port 80, because Windows has a built-in HTTP dispatch mechanism. Each process can tell Windows which URLs it wants to handle.

However, if an application server totally ignores this, then you're back in the less flexible old-school sockets world where only one process can receive requests destined for any particular port.

That may be fine - if you really don't want anything other than a particular process handling HTTP request on port 80, then it becomes tolerable to use an application server that fails to support the more flexible mechanisms offered by Windows. (And some popular app servers have this limitation. E.g., AFAIK, Tomcat is incapable of playing well with others, and insists on having port 80 all to itself. So if you're using someone else's app server, it may well be impractical to adapt it to use the preferred mechanism.)

Windows attempts to accommodate such inflexible services by not binding its dispatch mechanism to port 80 until something actively asks for that. (This is why you won't necessarily see a problem initially, but can run into this issue after some sort of update or config change.) But relying on this is not a very solid solution - you're essentially trusting to luck that nothing attempts to listen under port 80 before your app server launches. (There are various reasons a process might speculatively attempt to register for certain URLs on port 80, and back off if it's not allowed.)

So if you want one service to have exclusive access to port 80, you'd better tell Windows. It's not really good enough to attempt to switch off all services that might try to use the usual port sharing mechanism, because it's difficult to be confident that you've found all of them. (Particularly when Windows updates seem to change what's on by default.) It's probably good practice to disable the ones you know about, but it's best to approach this from both ends: disable services you don't want, and also ensure that it's not possible for ones you didn't know about to trip you up.

By default HTTP.SYS (the underlying port sharing HTTP dispatch mechanism in Windows) is able to listen on all addresses. But you can tell it not to. This page shows one way to do that: http://www.mikeplate.com/2011/11/06/stop-http-sys-from-listening-on-port-80-in-windows/ (wayback link: https://web.archive.org/web/20140329090533/http://www.mikeplate.com/2011/11/06/stop-http-sys-from-listening-on-port-80-in-windows/)

That is a relatively light way to do it, because it still enables listening on localhost for IPv6. It just frees up IPv4 port 80. You could take it further with more specialized config. (You could even disable HTTP.SYS entirely, but that might break things using ports other than 80, so it may cause problems.)

But whatever you do, the point is to ensure that HTTP.SYS doesn't attempt to listen on port 80 on the IP address you care about. Once you've done that, you don't need to worry about disabling services, nor do you need to worry about other changes re-introducing the problem. If you've ensured that the endpoint you need is effectively out of bounds for port sharing, then you should find that the system process stops binding to it.

  • Thanks for a very informative answer. As a Unix user, I didn't know that Windows has a HTTP dispatch mechanism to allow multiple simultaneous processes respond to requests on Port 80. Feb 17, 2017 at 11:49

Culprit was Web Deployment Agent Service.

Better solution than net stop http is to stop the services named "Web Deployment Agent Service".

  • 3
    Man! F***ing horrible Microsoft practices! I had to spend hours trying to find out why there was an IIS instance (judging by headers when connecting via telnet) listening on and preventing Apache from starting, EVEN when I had removed IIS from Windows features/roles. Yes, it was the Web Deployment Agent Service, blocking all access to port 80 on any address! Man! Sep 7, 2013 at 8:43
  • 2
    More a case of an app server using bad practices. Windows has a mechanism designed to enable multiple processes to handle HTTP requests on port 80. It's entirely possible for IIS to coexist with multiple other applications all handling port 80 requests. This is why the system process listens on 80 for you - it can dispatch each request to whichever process is responsible for the particular URL. Unfortunately, if an app server totally ignores this, and wants total ownership of port 80, it all goes wrong. If the app server doesn't ignore convention, you don't get this problem. Dec 18, 2013 at 10:52
  • 1
    Ok, i just learned that Nginx ignores "this MS" convention... and just disabled the service. Oct 18, 2015 at 1:37
  • 4
    The specific name of the service you need to stop and disable is World Wide Web Publishing Service. While "net stop http" is itself a really brutal answer full of nasty side effects - services like your print spooler and part of Windows 10's log in process rely on http - what it will do if you try it, is give you a list of services that depend on http, and the option to back out. Trying the small handful of services in that list one by one is how I found out that the WWW Publishing Service was the culprit. Nov 3, 2015 at 17:53
  • In my case it was World Wide Web Publishing Service which prevented everything else from listening to port 80. I can have multiple apache and nginx running without problem at the same time but when World Wide Web Publishing Service got into the mix after recent Windows Update everything else on port 80 stopped working.
    – J. Wrong
    May 20, 2018 at 14:50

It's most likely IIS 6.0 or later.

The HTTP protocol stack (HTTP.sys), which runs in kernel mode, receives client requests and routes them to the appropriate request queue. Worker processes, which run in user mode, pull the requests directly from their own kernel request queues, eliminating the process hops that occur in IIS 5.0 (and that also occur in IIS 5.0 isolation mode) when the Web server sends a request to a High-isolation, out-of-process application. Because these extra process hops are eliminated in worker process isolation mode, IIS can provide application isolation without sacrificing performance.

  • Hmm, I thought IIS showed up as "inetinfo.exe" - guess there are some situations where it isn't. Sep 15, 2009 at 23:53
  • It does! :) It shows up as both - the user mode stuff goes in inetfino.exe, but the kernel mode stuff comes from "system".
    – Mark Allen
    Sep 18, 2009 at 20:01

Try to stop the HTTP.SYS by going into Device Manager/Non Plug and Play Drivers and Select HTTP, try to stop it and you will see services which are triggering this HTTP to use port 80.


Last I checked, you can't end the "system" process, and if you do, I'm guessing it's going to have catastrophic effects. I'm not going to try it on the PC I'm on right now either!

It would seem that something inside Windows itself is listening on :80 - I'm going to guess that it could be something malicious. The best way to find out is to either:

a) Open a web browser to localhost and see what comes up

b) Start Telnet and telnet to localhost 80 and run some basic HTTP GET (e.g. GET /) and see what it returns

B is the better option if you think that you might be hosting malware, as you don't really want to infect yourself again. Although maybe it won't matter.

  • it can't be malware as it is on my VPS thats not been up and running for very long. I also don't use it to browse the web so...
    – GiH
    Sep 15, 2009 at 23:30

I found the answer to this question at: https://superuser.com/questions/352017/pid4-using-port-80

Specifically when it is System Process 4, you need to disable the HTTP.sys driver which is started on demand by another service, such as Windows Remote Management or Print Spooler on Windows 7 or 2008.

  1. Go to device manager, select “show hidden devices” from menu/view, go to “Non-Plug and Play Driver”/HTTP, double click it to disable it (or set it to manual, some services depended on it).

Reboot and use netstat -nao | find “:80″ to check if 80 is still used.

I also tried to get the port back by just running a "net stop http" but the port never seemed to get freed back up. The above did work for me though, and I I did not need the other services that where dependent on this driver.


Windows Sync Share is what killed us on Windows 2012 R2. Once we disabled this feature, everything came up fine.


In my case it was due to Carbon Black anti virus somehow taking a stranglehold on port 80. I spent hours trying to figure it out, so I feel obliged to share just in case it leads a fellow poor soul to the light :) I don't know how it was fixed exactly, go ask your server / network team!

  • Hi, I highly suspect I'm in the same case, how did you find out exactly ?
    – Etienne
    Feb 17, 2021 at 5:12
  • 1
    Hey @Etienne, I never did learn how this was resolved. Just worked with my server team to confirm that Carbon Black was the culprit and they helped me resolve. So rry I can't be of more help! Feb 21, 2021 at 4:50

I had process blocking a port that I needed to use for a docker container and it took forever to resolve. In my case it was PID 4 using port 80 too.

For anyone new coming to this, you can investigate the service using the respective port by following these steps to try to figure out what it is.

In Powershell we can check for what process is using this port:

netstat -aon | findStr /i "LISTENING"  | findStr ":80"

To check what process this is:

tasklist /FI "PID eq 4"

Another way to get the process ID using the port:

Get-Process -Id (Get-NetTCPConnection -LocalPort 80).OwningProcess

Check whether the port has ben reserved for use by another process with:

netsh int ipv4 show excludedportrange protocol=tcp

Also look in Resource Monitor to see if that gives you any more clues.

I tried all of the suggestions I found here and in other posts:

None of these worked to free up the port.

In the end I decided to check for any recent Windows Updates that could have caused it - there was nothing new in the last two weeks.

But when I check for recently installed applications (using Bulk Crap Uninstaller - it's excellent!) I noticed two 'apps' installed yesterday which I definitely didn't manually install so I think they somehow came through Win Update or an auto app update:

  • Microsoft Edge Webview 2 Runtime
  • Web Components

After uninstalling these, I had access to port 80 again!

To make sure it wouldn't happen again, I reserved the port for my own use:

netsh int ipv4 add excludedportrange protocol=tcp startport=80 numberofports=1

I've solved this through a stackoverflow question. Follow this link to find the solution for how to get IIS to stop listening on port 80 for a specified IP address.

You must log in to answer this question.