Je parie que c'est Skype. Décochez la case ci-dessous si vous l'avez installé.

Exécutez les opérations suivantes à partir d'une invite de commande élevée :

netstat -ab

Tout d'abord, je vais répondre directement à cette question et toute personne lisant ceci peut ignorer toute réponse parlant d'applications tierces, non-Microsoft, utilisant le System Process. Le processus System est répertorié comme PID 4 sur tous les systèmes Windows modernes. Il s'agit d'un accès en mode noyau. Cela exclut la plupart des produits web tiers comme Apache.

1. Depuis la création de WinRM (Windows Remote Management), le service HTTP ( %SystemRoot%\system32\drivers\http.sys ) est un élément standard de Windows (Vista et versions ultérieures / Server 2008 et versions ultérieures). http.sys fonctionne selon le processus System ( PID 4 ).

2. D'autres logiciels développés par Microsoft peuvent également utiliser le pilote %SystemRoot%\system32\ http.sys dans le cadre du processus System comme IIS , SQL Reporting Services , et Microsoft Web Deployment Service http://support.microsoft.com/kb/2597817 )…

3. Les ports par défaut de WinRM 1.0 étaient :
   HTTP = 80 HTTPS = 443 WinRM 2.0 et plus sont les ports par défaut :
   HTTP = 5985 HTTPS = 5986 Vérifiez avec les commandes suivantes :
   Winrm enumerate winrm/config/listener Winrm get http://schemas.microsoft.com/wbem/wsman/1/config

Étapes de dépannage :

Obtenez le numéro de processus du port que vous recherchez (443 dans ce cas) :

…à partir d'un lecteur non mappé de Windows pour éviter “Accès refusé” :
netstat -aon | trouvez “:443” La sortie devrait ressembler à ce qui suit pour le processus System :
C:>netstat -ano |find “:443” TCP 0.0.0.0:443 0.0.0.0:0 LISTENING 4 TCP [: :]:443 [: :]:0 LISTENING 4 La dernière colonne est le PID (4).

1. L'exécution de la tasklist pour savoir ce qui se passe dans le processus s'avère peu utile :
   tasklist /SVC /FI “PID eq 4” tasklist /m /FI “PID eq 4”

2. Recherchez le service HTTP dans le registre : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HTTP\Parameters\UrlAclInfo Il y aura une liste d'URL (avec les numéros de port) qui peut vous conduire à l'application en cours d'exécution et qui contient les ports :
   http:// +:5985/wsman/ –> WinRM https:// +:5986/wsman/ –> WinRM http:// +:80/Reports/ –> SQL Reporting Server http:// + : 80/ReportServer/ –> SQL Reporting Server https:// server_fqdn:443/Reports/ –> SQL Reporting Server https:// server_fqdn:443/ReportsServer/ –> SQL Reporting Server http://* : 2869/ –> Service SSDPSRV (Simple Service Discovery Protocol) ** http://* :5357/ –> **Services web de découverte dynamique (WS-Discovery) https://* : 5358/ –> Web Services Dynamic Discovery (WS-Discovery)

Vous pouvez alors trouver le service correspondant sur le système et l'arrêter et voir que le port souhaité est libéré en confirmant avec une autre commande netstat -aon | find “:443”.

Il s'agit souvent du service d'agent hôte de VMware (nécessaire pour la communication entre hôtes de VM et invités) - vmware-hostd.exe.

Un bon moyen de savoir quel est le sous-processus exécuté par svchost.exe est d'utiliser le Process Explorer de Sysinternals.

J'ai rencontré des problèmes similaires pour le routage de 443 demandes vers mon serveur WAS. C'est ce que j'ai fait en me basant sur les recommandations de cette question :

1. netstat -a -n -o | findstr 443
2. J'ai identifié le PID du processus d'écoute sur 443
3. J'ai utilisé l'explorateur de processus pour identifier le processus à partir du PID.
4. Dans mon cas, l'écoute de l'application était vmwarehostd.exe
5. J'ai arrêté le serveur VMware Workstation à partir de services.msc. Redémarré par le serveur WAS.

Et toutes les 443 demandes sont arrivées à 443 heureusement pour toujours.

PS : J'avais déjà désinstallé skype qui était intégré à mon installation de Windows 8. Le service de routage et d'accès à distance a été désactivé dans ma machine.

S'il s'agit d'un processus lancé par un service, netstat -ab n'aidera pas.

Dans ce cas, essayez netstat -ao | find /i "443" dans une ligne de commande administrateur. Cela vous donnera un résultat comme celui-ci :

TCP 0.0.0.0:443 your_hostname:0 LISTENING PID

Puis tapez tasklist | find /i "<PID>" dans une autre ligne de commande administrateur.

Dans mon cas, le PID était 2912 et ma commande était :

tasklist | find /i "2912"

Le résultat de ma commande était :

vmware-hostd.exe 2912 Services 0 39 856 K

Wow, j'ai même oublié que j'ai installé VMware pour vérifier une fonctionnalité…

Dans mon cas, c'était DataManager de F5 Networks qui utilise Tomcat 6 en interne pour servir ses pages web. J'ai oublié de désinstaller cette application. Une mauvaise décision de conception, si vous voulez mon avis.

Dans mon cas, c'était le processus de DTC (Distributed Transaction Coordinator) pour utiliser le port 443. En particulier, j'ai activé le WS-AT dans le DTC, et il utilisait le port 443.

En général, je comprends que lorsque le processus System (PID 4) utilise le port 443/HTTPS, c'est un processus interne de Windows (dans mon cas DTC, mais je pense que cela peut être aussi un autre processus), si ce n'est pas un site web IIS qui l'utilise.

En utilisant netstat -ao | find ":443", j'ai découvert que le port 443 est utilisé par le PID 4, qui était le processus du système. Cela m'est arrivé deux fois sur Windows Server 2012, et c'était dû à l'une des raisons suivantes :

1. IIS fonctionnait, répertorié comme “World Wide Web Publishing Service” dans Services, que j'ai arrêté.
2. La fonction “Dossiers de travail” était installée, je l'ai donc désinstallée.

Ce n'est peut-être pas une solution pour tout le monde, mais cela peut en aider certains.

J'ai constaté que l'utilisation de la fonctionnalité VPN dans Windows 8 (probablement la même pour Windows 7) utilisait le port 443.

De plus, mon port a été refermé par PMB.exe (Pando Media Booster).

Pour moi, après la mise à jour de Windows Server 2016, Apache 443 ne pouvait pas démarrer avec les événements habituels énumérés.

J'ai trouvé que le coupable était le service “Windows Sync Share” (SyncShareSvc). Je l'ai désactivé et j'ai pu démarrer Apache.

Pour moi, c'était l'agent McAfee de l'OEB qui écoutait sur le port 80. J'ai dû passer par plusieurs étapes douloureuses pour le faire changer. https://kc.mcafee.com/corporate/index?page=content&id=KB67605

Sur mon Windows Server 2019, je l'ai résolu en exécutant cette PS.

Stop-Service -Name KPSSVC

Il s'est exécuté en tant que processus 4 (processus SYSTEM) sous les privilèges du service réseau. L'exécution de

netstat -ab

n'a pas aidé. Il affichait “Can not obtain ownership information” (Impossible d'obtenir des informations sur la propriété).

Après avoir arrêté le service, netstat -aon | findstr “:443” n'affiche plus l'entrée. Trouvé par l'arrêt littéraire de chaque service un par un.

KDC Proxy Server service (KPS) - Le service KDC Proxy Server s'exécute sur les serveurs de périphérie pour transmettre les messages du protocole Kerberos aux contrôleurs de domaine sur le réseau de l'entreprise.

Wireshark vous donnera les détails. http://www.wireshark.org/ Or TCP Monitor : http://www.itsamples.com/tcp-monitor.html

Cela vous aidera.

Si vous avez une sorte de pilote de réseau local virtuel (comme OpenVM, VMware, etc.) - assurez-vous de “libérer” le port avant de le donner à autre chose…

Juste un petit conseil ;)

J'ai eu le même problème en essayant d'installer une mise à jour de VMware. Je l'ai suivie jusqu'à Skype. Le nouveau client est configuré par défaut sur 443.