Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question
add comment

6 Answers

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.

share|improve this answer
    
Hmm, I thought IIS showed up as "inetinfo.exe" - guess there are some situations where it isn't. –  Mark Henderson Sep 15 '09 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 '09 at 20:01
add comment

Culprit was Web Deployment Agent Service.

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

share|improve this answer
    
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 0.0.0.0:80 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! –  Francisco Zarabozo Sep 7 '13 at 8:43
    
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. –  Ian Griffiths Dec 18 '13 at 10:52
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
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 '09 at 23:30
add comment

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.

share|improve this answer
add comment

I found the answer to this question at: http://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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.