Embora as pessoas estejam apontando serviços específicos (por exemplo, o "Serviço do Agente de Implantação da Web"), isso não resolve a causa raiz. Se você apenas desabilitar os serviços que desencadeiam o problema, é provável que ele volte a sua cabeça no futuro em uma aparência marginalmente diferente. Portanto, vale a pena entender o que está errado, porque isso leva a uma solução melhor.
Esse problema surge quando um servidor de aplicativos deseja o controle total da porta 80. Isso entra em conflito com um recurso do Windows projetado para permitir que múltiplos processos tratem solicitações na porta 80. É totalmente possível ter qualquer número de processos todos recebendo solicitações HTTP na porta 80, porque o Windows possui um mecanismo de despacho HTTP interno. Cada processo pode informar ao Windows quais URLs ele deseja manipular.
No entanto, se um servidor de aplicativos ignorar isso totalmente, você estará de volta ao mundo menos flexível dos sockets da velha escola, onde apenas um processo pode receber solicitações destinadas a qualquer porta em particular.
Isso pode ser bom - se você realmente não deseja nada além de um processo específico que lida com solicitação HTTP na porta 80, torna-se tolerável usar um servidor de aplicativos que não suporta os mecanismos mais flexíveis oferecidos pelo Windows. (E alguns servidores de aplicativos populares têm essa limitação. Por exemplo, AFAIK, o Tomcat é incapaz de jogar bem com os outros e insiste em ter a porta 80 totalmente para si. Portanto, se você estiver usando o servidor de aplicativos de outra pessoa, pode ser impraticável adapte-o para usar o mecanismo preferido.)
O Windows tenta acomodar esses serviços inflexíveis, não vinculando seu mecanismo de envio à porta 80 até que algo solicite isso ativamente. (É por isso que você não necessariamente vê um problema inicialmente, mas pode enfrentar esse problema após algum tipo de atualização ou alteração de configuração.) Mas confiar nisso não é uma solução muito sólida - você está basicamente confiando na sorte de que nada tenta escutar na porta 80 antes de o servidor de aplicativos ser iniciado. (Há várias razões pelas quais um processo pode tentar especulativamente se registrar para determinados URLs na porta 80 e recuar se não for permitido.)
Portanto, se você deseja que um serviço tenha acesso exclusivo à porta 80, é melhor informar ao Windows. Não é realmente bom o suficiente tentar desativar todos os serviços que possam tentar usar o mecanismo de compartilhamento de portas usual, porque é difícil ter certeza de que você encontrou todos eles. (Principalmente quando as atualizações do Windows parecem alterar o que está ativado por padrão.) Provavelmente, é uma boa prática desativar os que você conhece, mas é melhor abordar isso dos dois lados: desabilite os serviços que você não deseja e também garanta que não possível para aqueles que você não conhecia.
Por padrão HTTP.SYS(a porta subjacente que compartilha o mecanismo de envio HTTP no Windows) pode escutar em todos os endereços. Mas você pode dizer para não. Esta página mostra uma maneira de fazer isso: http://www.mikeplate.com/2011/11/06/stop-http-sys-from-listening-on-port-80-in-windows/
Essa é uma maneira relativamente leve de fazê-lo, porque ainda permite escutar no host local para IPv6. Ele libera a porta 80 do IPv4. Você pode ir além com configurações mais especializadas. (Você pode até desativar HTTP.SYScompletamente, mas isso pode quebrar coisas usando outras portas que não sejam 80, por isso pode causar problemas.)
Mas o que quer que você faça, o objetivo é garantir que HTTP.SYSnão tente escutar na porta 80 no endereço IP de seu interesse. Depois de fazer isso, você não precisa se preocupar com a desativação de serviços, nem com outras alterações que possam apresentar o problema novamente. Se você garantiu que o terminal que você precisa está efetivamente fora dos limites do compartilhamento de portas, deverá descobrir que o processo do sistema para de vincular-se a ele.