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.
Best Answer
Procexplorer, netstat, tasklist, etc... tend to be shy on details as System obfuscates underlying info.
You could try
net stop httpto deload HTTP.sys. it should warn you what services have a dependency on it. Use that output to go through a process of elimination... hopefully you find the culprit.As a side note, I know Dell SupportAssist uses port 5700, but that shouldn't run as System.