Pourquoi le processus 'System' écoute-t-il sur le port 443?

45

J'ai des problèmes pour démarrer mon serveur Apache, car le port 443 est déjà utilisé.

En fin de compte, le processus système (PID 4) utilise le port 443. IIS n'est pas installé, services.msc n'affiche (de manière prévisible) aucun serveur Exchange en cours d'exécution, ni WWW-Services, ni IIS. Je n'ai aucune idée de comment savoir quel service utilise ce port, à part désactiver simplement chaque service l'un après l'autre, et je ne suis même pas sûr que cela aiderait.

Je serais reconnaissant si quelqu'un pouvait m'indiquer comment je peux récupérer mon port SSL, merci :)

PS: Bien sûr, "basculer simplement Apache sur un autre port pour SSL" résoudrait le problème de l'impossibilité de démarrer Apache. Mais j'aimerais quand même savoir ce qui insiste tellement sur le monopole du port 443. :)

J'ai maintenant pris la 'voie difficile' et désactivé les services les uns après les autres. Il s’est avéré que le service "Routing and RAS" était le coupable.

Merci à tous pour votre précieuse contribution et les nouveaux outils de lutte contre "WTF, que fait mon système maintenant?".

windows Corneille
la source
Connexe: superuser.com/questions/121901 Vous pouvez utiliser n'importe laquelle des réponses données pour vous aider à déterminer le service ouvrant le port 443.
mardi
1
Malheureusement, comme je suis incapable (ou tout simplement trop stupide) de savoir quel service tient exactement le port ouvert, je ne peux pas utiliser "SC Config Servicename Type = own" pour un décalage de Servicename. Les différentes incantations de Netstat me dirigent vers le processus système, comme dit précédemment, tout comme TCPView. Les "piles", comme pour PE, ne fonctionnent apparemment pas sur Win7 et comme je ne regarde pas une instance de svchost.exe, je n'ai pas de colonne "Service" dans l'onglet TCP / IP. Skype n'est pas en cause, et aucun autre logiciel VoIP ou P2P n'est en cours d'exécution. Mais l’autre question que vous avez liée m’a éclairé; Je vous remercie.
Cornelius
Merci pour l'info! Pour moi, c’était aussi le service «Routage et accès à distance» qui avait lié le port 443.
Codler
3
Homme, la quantité de réponses n'essayant même pas de répondre à la question est incroyable. Il en va de même pour la quantité de désinformation. Si le PID 4 est à l'écoute, c'est http.sys. Toujours. Heureusement, il existe déjà une réponse sur la façon de mieux comprendre .
Daniel B

Réponses:

18

Exécutez les opérations suivantes à partir d'une invite de commande avec privilèges élevés:

netstat -ab
tonyr roth
la source
Je suis un peu surpris. Tout le reste a montré que "le processus du système" était le coupable. Cette commande prétend maintenant qu'il s'agit d'un svchost.exe qui contient ce port. : | Comment PE / "autres" appels Netstat ont-ils été inclus dans le processus système? (Bien que le port reste affiché comme étant détenu par PID 4 / System.) Comment puis-je inspecter davantage? :(
Cornelius
pas sûr mais courir PE élevé peut-être!
tonyr roth
2
Les informations suivantes peuvent également vous aider à mieux comprendre le processus wmic> test.txt
tonyr roth
1
J'ai exécuté Process Explorer en tant qu'administrateur - et le port apparaît toujours comme le prétend "Système"; pas vraiment beaucoup plus d'informations disponibles là-bas: | À présent, je pense que ce sera quelque chose de vraiment stupide que j'ai fait sans le vouloir;)
Cornelius
4
Cela ne fonctionne pas pour moi, sous la ligne 0.0.0.0:443, je viens juste de recevoir Impossible d’obtenir des informations sur la propriété .
MGOwen
33

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

Alt text

Fusil
la source
3
+1 D'autres clients VoIP (et d'autres logiciels tels que des applications de transfert de fichiers P2P) écoutent les ports 80 et 443 s'ils ne trouvent rien d'autre, même si Skype est le "contrevenant" le plus courant. Cependant, je ne suis pas sûr de savoir pourquoi Skype se présenterait comme un processus appartenant au système.
David Spillett
Malheureusement, ce n'est pas Skype. ni d' autres clients VoIP (pas installé) ni P2P etc. Je vérifié que et il est non seulement « un processus appartenant système », il est « le processus du système » (PID 4)
Cornelius
Bizarrement, j'ai eu le même problème que l'OP-443 a été prise par svchost .. et pourtant, éteindre Skype a résolu le problème.
Blorgbeard
Avait ce problème. J'ai
samedi place
Juste pour des raisons de clarté: si votre portage est tenu par svchost et clairement visible dans Process Explorer, ce n'était pas le même problème que moi. D'où mon insistance à préciser que le processus portant le nom de "Système" semblait appartenir au port.
Cornelius
12

J'ai eu le problème que le port 443 était utilisé par "système" avec PID 4 sur mon ordinateur Windows 7. La solution pour moi était de supprimer une "connexion entrante" (VPN) existant dans le dossier des connexions réseau.

Il semble que je l’ai créé et que j’ai oublié de le supprimer après utilisation ...

faiseur
la source
1
Oui, le même problème sur Windows 8.1.
Konstantin Pereiaslov
vient de faire que win7. Il a cessé d'écouter sur TCP 443, mais écoute toujours sur le port UDP 443, mais cela peut suffire.
barlop
1
J'ai eu ce problème sur Windows Server 2008 R2 x64. Il m'a fallu un certain temps pour trouver votre message et la réponse officielle à cette question m'étonne, car elle ne répond pas du tout à la question. Merci!
simontemplar
Cela a fonctionné pour moi lorsque, au lieu de supprimer la "connexion entrante" (je ne me souviens plus comment la recréer si j'en ai besoin de nouveau), je l'ai décochée [_] Allow other computers to connect to this onesous Centre réseau et partage, Configuration de l'adaptateur, Connexion entrante, Propriétés.
Alexander Gelbukh
11

Tout d'abord, je vais répondre directement à cette question et toute personne qui lit ceci peut ignorer les réponses concernant des applications tierces non Microsoft utilisant le processus système.

  1. Le processus système est répertorié en tant que PID 4 sur chaque système Windows moderne. C'est pour l'accès en mode noyau. Cela exclut la plupart des produits Web tiers tels qu'Apache.

  2. Depuis la création de WinRM (Windows Remote Management), le service HTTP ( % SystemRoot% \ system32 \ drivers \ http.sys ) fait partie intégrante de Windows (Vista et versions ultérieures / Server 2008 et versions ultérieures). http.sys s'exécute sous le processus système ( PID 4 ).

  3. D'autres logiciels développés par Microsoft peuvent également utiliser% SystemRoot% \ system32 \ drivers \ http.sys dans le processus système tel que IIS , SQL Reporting Services et Microsoft Web Deployment Service ( http://support.microsoft.com/kb/2597817 ) ...

  4. Les ports par défaut de WinRM 1.0 étaient:
    HTTP = 80
    HTTPS = 443 Les
    ports par défaut de WinRM 2.0 et supérieurs sont les suivants:
    HTTP = 5985
    HTTPS = 5986
    Vérifiez à l'aide des commandes suivantes:
    Winrm énumère winrm / config / listener
    Winrm obtient 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):

... depuis un lecteur non mappé de Windows pour éviter "Accès refusé":
netstat -aon | find ": 443"
Pour le processus système, la sortie devrait ressembler à ceci :
C:> netstat -ano | find ": 443"
TCP 0.0.0.0:443 0.0.0.0:0 ECOUTE 4
TCP [::]: 443 [: :]: 0 ECOUTE 4
La dernière colonne est le PID (4).

  1. L'exécution de la liste de tâches pour savoir ce qui est en cours d'exécution s'avère peu
    utile : liste de tâches / SVC / FI "PID éq 4"
    / liste de tâches / m / FI "PID éq 4"

  2. Recherchez dans le registre le service HTTP suivant: HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ services \ HTTP \ Parameters \ UrlAclInfo
    Il y aura une liste d’URL (avec les numéros de port) pouvant vous indiquer quelle application est en cours d’exécution et qui détient les ports suivants:
    http : // +: 5985 / wsman / -> WinRM
    https: // +: 5986 / wsman / -> WinRM
    http: // +: 80 / Rapports / -> SQL Reporting Server
    http: // +: 80 / ReportServer / -> SQL Reporting Server
    https: // serveur_fqdn: 443 / Rapports / -> SQL Reporting Server
    https: // serveur_fqdn: 443 / ReportsServer / -> SQL Reporting Server
    http: // *: 2869 / - -> Service SSDPSRV (Service Service Protocol) simple
    http: // *: 5357 / ->Découverte dynamique des services Web (WS-Discovery)
    https: // *: 5358 / -> Découverte dynamique des services Web (WS-Discovery)

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

Kenya Graham
la source
En ce qui concerne le point 6, comment trouvons-nous le processus à l'écoute de ces ports?
Galmok
8

Il s’agit souvent du service d’agent d’hôte VMware (requis pour la communication entre hôte et invité) - vmware-hostd.exe.

Un bon moyen de savoir quel sous-processus svchost.exe est en cours d'exécution consiste à utiliser l'Explorateur de processus de Sysinternals .

Tony
la source
2
Si vous avez effectivement installé VMware Workstation, vérifiez sous Edition -> Préférences -> Ordinateurs virtuels partagés. Le partage de machine virtuelle est probablement activé et le port par défaut est 443. Vous pouvez désactiver le partage, modifier le port et l'activer, ou simplement le laisser désactivé si vous n'en avez pas besoin.
gronostaj
@gronostaj Merci beaucoup, je viens de passer 3 heures à essayer de trouver ceci :(
Simon Kirsten
7

J'ai rencontré des problèmes similaires avec le routage de 443 requêtes sur mon serveur WAS. D'après les recommandations de cette question, voici ce que j'ai fait:

  1. À partir de l'invite de commande élevée, exécutée netstat -a -n -o | findstr 443
  2. Identifié le PID du processus en écoute sur 443
  3. Utilisé Process Explorer pour identifier le processus à partir du PID.
  4. Dans mon cas, l'application était à l'écoute vmwarehostd.exe
  5. Arrêté le serveur VMware Workstation services.msc. Redémarré par le serveur WAS.

Et toutes les 443 demandes sont venues à 443 heureusement pour toujours.

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

praveen
la source
3
-1 C'était le PID 4, c'était beaucoup plus difficile. Vous écrivez "Explorateur de processus utilisé pour identifier le processus à partir du pid". <- Le vôtre n’était pas le PID 4, par exemple svchost ou quelque chose comme ça. Le vôtre était un tiers exe. Vous auriez pu simplement utiliser le gestionnaire de tâches! Si vous ne montrez pas déjà la colonne, alors view..choose column Mais vous avez eu de la chance que votre PID ne soit pas PID 4. Je ne sais pas si l'explorateur de processus peut y aider, mais le gestionnaire de tâches ne le peut pas. Mais dans votre cas, un simple gestionnaire de tâches l’aurait fait.
barlop
5

S'il s'agit d'un processus lancé par un service, netstat -abcela ne vous aidera pas.

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

    TCP   0.0.0.0:443   your_hostname:0   LISTENING   PID

Puis tapez tasklist | find /i "<PID>"une autre invite 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é ...

elbedoit
la source
1
Pour moi, c'était le PID 4 ... étant le système. Toujours pas la moindre idée :)
Wouter
PID 4 signifie généralement un service Windows natif de Microsoft, ce qui signifie un niveau de noyau. Essayez d’arrêter les services un par un et vérifiez si le problème a été résolu. Désactivez le service / désinstallez la fonctionnalité causée par @Wouter. Services habituels sont: Routing and RAS, tout en notant IISou World Wide Puplishing, Exchange Windows Sync Share, Web Deployment Agent Service, SQL Server Reporting Services, File Server Storage Reports Manageret similaire.
Elbedoit
1

Dans mon cas, DataManager de F5 Networks utilisait Tomcat 6 en interne pour servir ses pages Web. J'ai oublié de désinstaller cette application. Mauvaise décision de conception, si vous me demandez.

Roman Zenka
la source
1

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

  1. IIS était en cours d'exécution, répertorié comme "Service de publication World Wide Web" dans Services, que j'ai arrêté.
  2. La fonctionnalité Dossiers de travail installée, je l'ai donc désinstallée.

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

Anishpatel
la source
Cette réponse n’ajoute pas vraiment de nouvelles informations qui ne figuraient pas déjà dans les réponses soumises par elbedoit ou tonyr
Ramhound
1
J'ai spécifiquement ajouté cette réponse car la désinstallation de la fonctionnalité Dossiers de travail a fonctionné pour moi et constitue donc une solution potentielle au problème tel qu'il est écrit. Devrais-je présenter cette information dans un commentaire à la place?
Anishpatel
1
J'ai eu le même problème comme indiqué dans la question, et la réponse de tonyr n'a pas fonctionné pour moi. La réponse d'elbedoit n'aide pas lorsque vous avez le PID 4 (comme indiqué dans la question); allez-vous arrêter / redémarrer de manière aléatoire les processus système pour résoudre le problème?
Anishpatel
1
Aucune autre réponse ne mentionne la désinstallation de la fonctionnalité Dossiers de travail, solution apportée à la question. J'ai répété les informations de la ou des autres réponses pour aider les autres personnes ayant le même problème à déterminer si cette solution pourrait leur convenir (c.-à-d., Vérifiez que PID est égal à 4). Si le PID n'est pas 4, cette réponse ne vous aidera certainement pas. En quoi cette réponse est-elle plus incomplète que celle de doener ou de tonyr? S'il vous plaît suggérer comment je peux mieux communiquer ma solution.
Anishpatel
1
Oui! C'était aussi la fonction Dossiers de travail pour moi! Merci beaucoup d'avoir mentionné cela. C'est en effet une réponse également valable que de mentionner Skype ou tout autre service ...
Wouter
1

Dans mon cas, il s’agissait du processus DTC (Distributed Transaction Coordinator) pour utiliser le port 443. En particulier, j'ai activé WS-AT dans DTC, qui utilisait le port 443.

En général, je comprends que lorsque le processus système (PID 4) utilise le port 443 / HTTPS, il s’agit d’un processus interne de Windows (dans mon cas, le DTC, mais je pense que cela peut aussi être un autre processus), si ce n’est pas un site Web IIS En l'utilisant.

Gurca
la source
0

Pour moi, après la mise à jour Windows Server 2016, Apache 443 n'a pas pu commencer avec l'événement habituel indiqué.

J'ai trouvé le coupable d'être le service "Windows Sync Share" (SyncShareSvc). J'ai désactivé et j'ai pu démarrer Apache.

JEC
la source
0

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

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

utilisateur1788951
la source
-1

Wireshark vous dira les détails. http://www.wireshark.org/ Ou moniteur TCP: http://www.itsamples.com/tcp-monitor.html

Ça va aider.

Adeelx
la source
tcp-monitor n'a malheureusement pas vraiment pu m'aider du tout; Comme pour Wirehark - Je n'ai pas pu générer / capturer les paquets dirigés vers le port 443. :(
Cornelius
1
La seule option restante est Process Explorer (sysinternals). Il vous montrera les processus avec les ports. Wireshark est l'un des meilleurs produits de cette gamme, mais je ne comprends pas pourquoi cela n'a pas fonctionné pour vous: s (Avez-vous installé le pilote de capture WinPCAP?)
adeelx
Réponse très tardive, désolée. Mais je n'ai rien pu enregistrer parce qu'il n'y avait apparemment aucun trafic à renifler. Au moins donc je présume.
Cornelius
-1 Wireshark ne vous montrera rien qui puisse aider à identifier ce qui est sur le port .. sauf s'il y a des paquets qui vont sur le port quelle est cette adresse IP.
barlop
-1

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 indice;)

Ruslan Abuzant
la source
-2

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

Cal
la source
4
Ceci ne fait que répéter une réponse existante. S'il vous plaît upvote les réponses existantes plutôt que republier.
Chenmunka
@Chenmunka Peut-être qu'il ne l'a pas lu
FindOutIslamNow