Bien que des personnes signalent des services spécifiques (par exemple, le "service d'agent de déploiement Web"), cela ne parvient pas à résoudre la cause première. Si vous désactivez simplement les services qui déclenchent le problème, il est probable qu'il réapparaîtra à l'avenir sous une forme légèrement différente. Il vaut donc la peine de comprendre ce qui ne va pas, car cela conduit à une meilleure solution.
Ce problème se produit lorsqu'un serveur d'applications souhaite un contrôle total du port 80. Cela entre en conflit avec une fonctionnalité de Windows conçue pour permettre à plusieurs processus de gérer les demandes sur le port 80. Il est tout à fait possible d'avoir un nombre illimité de processus recevant tous des demandes HTTP sur le port. 80, car Windows dispose d'un mécanisme de répartition HTTP intégré. Chaque processus peut indiquer à Windows les URL qu'il souhaite gérer.
Cependant, si un serveur d'applications ignore totalement cela, vous êtes de retour dans le monde des sockets old-school moins flexible où un seul processus peut recevoir des demandes destinées à un port particulier.
Cela peut être bien - si vous ne voulez vraiment rien d'autre qu'un processus particulier gérant la requête HTTP sur le port 80, alors il devient tolérable d'utiliser un serveur d'applications qui ne prend pas en charge les mécanismes plus flexibles offerts par Windows. (Et certains serveurs d'applications populaires ont cette limitation. Par exemple, AFAIK, Tomcat est incapable de bien jouer avec les autres et insiste pour avoir le port 80 pour lui tout seul. Donc, si vous utilisez le serveur d'applications de quelqu'un d'autre, il peut être difficile de l'adapter pour utiliser le mécanisme préféré.)
Windows tente de prendre en charge de tels services inflexibles en ne liant pas son mécanisme de répartition au port 80 jusqu'à ce que quelque chose le demande activement. (C'est pourquoi vous ne verrez pas nécessairement un problème au départ, mais vous pouvez rencontrer ce problème après une sorte de mise à jour ou de changement de configuration.) Mais compter sur ce n'est pas une solution très solide - vous avez essentiellement confiance en la chance que rien tente d'écouter sous le port 80 avant le lancement de votre serveur d'applications. (Il existe plusieurs raisons pour lesquelles un processus peut tenter de s'inscrire pour certaines URL sur le port 80 de manière spéculative, puis le désactiver s'il n'est pas autorisé.)
Donc, si vous voulez qu'un service ait un accès exclusif au port 80, vous feriez mieux de le dire à Windows. Il n'est pas vraiment suffisant d'essayer de désactiver tous les services qui pourraient essayer d'utiliser le mécanisme de partage de port habituel, car il est difficile d'être sûr que vous les avez tous trouvés. (En particulier lorsque les mises à jour Windows semblent modifier ce qui est activé par défaut.) Il est probablement recommandé de désactiver celles que vous connaissez, mais il est préférable de procéder de la même manière: désactivez les services dont vous ne voulez pas et assurez-vous également que ce n'est pas le cas. possible pour ceux que vous ne connaissiez pas de vous trébucher.
Par défaut HTTP.SYS(le mécanisme de répartition HTTP de partage de port sous-jacent dans Windows) est capable d'écouter sur toutes les adresses. Mais vous pouvez le lui dire. Cette page montre une façon de le faire: http://www.mikeplate.com/2011/11/06/stop-http-sys-from-listening-on-port-80-in-windows/
C'est une façon relativement légère de le faire, car elle permet toujours d'écouter sur localhost pour IPv6. Il libère simplement le port IPv4 80. Vous pouvez aller plus loin avec une configuration plus spécialisée. (Vous pouvez même désactiver HTTP.SYScomplètement, mais cela pourrait casser des choses en utilisant des ports autres que 80, donc cela pourrait causer des problèmes.)
Mais quoi que vous fassiez, le but est de vous assurer que HTTP.SYSvous n'écoutez pas sur le port 80 sur l'adresse IP qui vous intéresse. Une fois que vous avez fait cela, vous n'avez pas à vous soucier de la désactivation des services, ni à vous soucier des autres changements réintroduisant le problème. Si vous vous êtes assuré que le point de terminaison dont vous avez besoin est effectivement hors limites pour le partage de port, vous devez constater que le processus système cesse de s'y lier.