I am trying to use port 80 for my application server, but when I perform "netstat -aon" I get
TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 4
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?
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/
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.
Culprit was Web Deployment Agent Service.
Better solution than net stop http is to stop the services named "Web Deployment Agent Service".
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.
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!
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.
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.
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.
Windows Sync Share is what killed us on Windows 2012 R2. Once we disabled this feature, everything came up fine.
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.
