Scommetto che è Skype. Deseleziona la casella di controllo mostrata qui sotto se lo hai installato.

Esegui il seguente da un prompt dei comandi elevato:

netstat -ab

Prima di tutto, risponderò direttamente a questa domanda e chiunque stia leggendo può ignorare qualsiasi risposta che parli di applicazioni di terze parti e non Microsoft che usano il processo di sistema.

1. Il processo System è elencato come PID 4 su ogni sistema Windows moderno. È per l'accesso in modalità kernel. Questo esclude la maggior parte dei prodotti web di terze parti come Apache.

2. Dalla nascita di WinRM (Windows Remote Management), il servizio HTTP ( %SystemRoot%\system32\drivers\http.sys ) è stato una parte standard di Windows (Vista e successivi / Server 2008 e successivi). http.sys gira sotto il processo System ( PID 4 ).

3. Anche altri software sviluppati da Microsoft possono usare la %SystemRoot%\system32\drivers\ http.sys sotto il processo System come IIS , SQL Reporting Services , e Microsoft Web Deployment Service http://support.microsoft.com/kb/2597817 )…

4. Le porte predefinite di WinRM 1.0 erano:
   HTTP = 80 HTTPS = 443 Le porte predefinite di WinRM 2.0 e superiori sono:
   HTTP = 5985 HTTPS = 5986 Controlla con i seguenti comandi:
   Winrm enumerate winrm/config/listener Winrm get http://schemas.microsoft.com/wbem/wsman/1/config

Passi per la risoluzione dei problemi:

Ottieni il numero di processo della porta che stai cercando (443 in questo caso):

…da un'unità non mappata di Windows per evitare “Access Denied”:
netstat -aon | find “:443” L'output dovrebbe essere come il seguente per il processo System:
C:>netstat -ano |find “:443” TCP 0.0.0.0:443 0.0.0.0:0 LISTENING 4 TCP [::]:443 [::]:0 LISTENING 4 L'ultima colonna è il PID (4).

1. Eseguire tasklist per scoprire cosa è in esecuzione nel processo si dimostra inutile:
   tasklist /SVC /FI “PID eq 4” tasklist /m /FI “PID eq 4”

2. Cercate nel registro di sistema il servizio HTTP: HKEYLOCALMACHINE\SYSTEM\CurrentControlSet\services\HTTP\Parameters\UrlAclInfo Ci sarà un elenco di URL (con i numeri delle porte) che può portarvi a quale applicazione è in esecuzione e a quali porte:
   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/ –> Simple Service Discovery Protocol service (SSDPSRV) http://* :5357/ –> Web Services Dynamic Discovery (WS-Discovery) https://* : 5358/ –> Web Services Dynamic Discovery (WS-Discovery)

Si può quindi trovare il servizio corrispondente sul sistema e fermarlo e vedere che la porta desiderata è rilasciata confermando con un altro comando netstat -aon | find “:443”.

Ho avuto il problema che la porta 443 era usata da “system” con PID 4 sulla mia macchina Windows 7. La soluzione per me era di cancellare una “Incoming Connection” (VPN) che esisteva nella cartella delle connessioni di rete.

Sembra che l'abbia creata e abbia dimenticato di cancellarla dopo l'uso…

Spesso questo è il servizio VMware host agent (richiesto per la comunicazione VM-host-to-guest) - vmware-hostd.exe.

Un buon modo per scoprire quale sottoprocesso svchost.exe è in esecuzione è usare Sysinternals’ Process Explorer .

Ho affrontato problemi simili con il routing delle richieste 443 al mio server WAS. Sulla base delle raccomandazioni in questa domanda, questo è ciò che ho fatto:

1. Dal prompt di cmd elevato ho eseguito netstat -a -n -o | findstr 443
2. Identificato il PID del processo in ascolto su 443
3. Ho usato Process Explorer per identificare il processo dal PID.
4. Nel mio caso l'applicazione in ascolto era vmwarehostd.exe
5. Fermato il server VMware Workstation da services.msc. Riavviato dal server WAS.

E tutte le richieste 443 sono arrivate a 443 felici e contenti.

PS: Avevo già disinstallato skype che era stato integrato nella mia installazione di Windows 8. Il servizio di routing e di accesso remoto era disabilitato nella mia macchina.

Se è un processo avviato da un servizio, netstat -ab non aiuterà.

In questo caso prova netstat -ao | find /i "443" in una linea di comando di amministratore. Questo vi darà un output come questo:

TCP 0.0.0.0:443 your_hostname:0 LISTENING PID

Poi digitate tasklist | find /i "<PID>" in un altro prompt dei comandi di amministratore.

Nel mio caso il PID era 2912 e il mio comando era:

tasklist | find /i "2912"

L'output del mio comando era:

vmware-hostd.exe 2912 Services 0 39 856 K

Wow, ho persino dimenticato di aver installato VMware per controllare una funzionalità…

Nel mio caso era DataManager di F5 Networks che usa Tomcat 6 internamente per servire le sue pagine web. Ho dimenticato di disinstallare quell'applicazione. Pessima decisione di design, se me lo chiedete.

Nel mio caso era il processo DTC (Distributed Transaction Coordinator) ad usare la porta 443. In particolare, ho attivato WS-AT in DTC, e stava usando la porta 443.

In generale, capisco che quando il processo di sistema (PID 4) usa la porta 443/HTTPS, è un processo interno di Windows (nel mio caso DTC, ma penso possa essere anche un altro processo), se non è un sito web IIS che lo usa.

Usando netstat -ao | find ":443", ho scoperto che la porta 443 è usata dal PID 4, che era il processo System. Questo mi è successo due volte su Windows Server 2012, ed era dovuto a una delle seguenti ragioni:

1. IIS era in esecuzione, elencato come “World Wide Web Publishing Service” in Services, che ho fermato.
2. La funzione Cartelle di lavoro installata, quindi l'ho disinstallata.

Questa potrebbe non essere una soluzione per tutti, ma potrebbe aiutare qualcuno.

Ho scoperto che utilizzando la funzionalità VPN in Windows 8 (probabilmente lo stesso per Windows 7) ha utilizzato la porta 443.

Inoltre, la mia porta è stata chiusa di nuovo da PMB.exe (Pando Media Booster).

Per me, dopo l'aggiornamento di Windows Server 2016, Apache 443 non poteva partire con il solito evento elencato.

Ho trovato il colpevole nel servizio “Windows Sync Share” (SyncShareSvc). Ho disabilitato ed è stato in grado di avviare Apache.

Per me era l'agente McAfee EPO in ascolto sulla porta 80. Ho dovuto passare attraverso diversi cerchi dolorosi per farlo cambiare. https://kc.mcafee.com/corporate/index?page=content&id=KB67605

Sul mio Windows Server 2019, ho risolto eseguendo questo PS.

Stop-Service -Name KPSSVC

Ha funzionato come processo 4 (processo SYSTEM) sotto i privilegi di Network Service. L'esecuzione di

netstat -ab

non ha aiutato. Ha visualizzato ‘Impossibile ottenere informazioni sulla proprietà’.

Dopo aver fermato il servizio, netstat -aon | findstr “:443” non mostra più la voce. L'ho scoperto fermando ogni servizio uno per uno.

Servizio KDC Proxy Server (KPS) - Il servizio KDC Proxy Server gira sui server edge per fare il proxy dei messaggi del protocollo Kerberos ai controller di dominio sulla rete aziendale.

Wireshark vi dirà i dettagli. http://www.wireshark.org/ Oppure TCP Monitor: http://www.itsamples.com/tcp-monitor.html

Questo ti aiuterà.

Se hai qualche tipo di driver LAN virtuale (come OpenVM, VMware, ecc.) - assicurati di ‘rilasciare’ la porta prima di darla a qualcos'altro…

Solo un consiglio veloce ;)

Ho avuto lo stesso problema mentre cercavo di installare un aggiornamento di VMware. L'ho ricondotto a Skype. Il nuovo client ha come default il 443.