Założę się, że to Skype. Usuń zaznaczenie pola wyboru pokazanego poniżej, jeśli masz go zainstalowanego.

Uruchom następujące polecenie z podniesionego wiersza poleceń:

netstat -ab

Po pierwsze, odpowiem na to pytanie bezpośrednio, a każdy, kto to czyta, może zignorować wszelkie odpowiedzi mówiące o aplikacjach firm trzecich, innych niż Microsoft, używających procesu systemowego.

1. Proces System jest wymieniony jako PID 4 w każdym współczesnym systemie Windows. Służy on do dostępu do trybu jądra. Wyklucza to większość produktów internetowych innych firm, takich jak Apache.

2. Od czasu powstania WinRM (Windows Remote Management), usługa HTTP ( %SystemRoot%System32\drivershttp.sys ) jest standardową częścią systemu Windows (Vista i nowsze / Server 2008 i nowsze). http.sys działa pod procesem System ( PID 4 ).

3. Inne oprogramowanie opracowane przez firmę Microsoft może również korzystać z %SystemRoot% ™system32 ™drivers http.sys w ramach procesu System, np. IIS, SQL Reporting Services i Microsoft Web Deployment Service http://support.microsoft.com/kb/2597817 )…

4. Domyślnymi portami WinRM 1.0 były:
   HTTP = 80 HTTPS = 443 WinRM 2.0 i większe domyślne porty to:
   HTTP = 5985 HTTPS = 5986 Sprawdź za pomocą następujących poleceń:
   Winrm enumerate winrm/config/listener Winrm get http://schemas.microsoft.com/wbem/wsman/1/config

Kroki rozwiązywania problemów:

Uzyskaj numer procesu portu, którego szukasz (w tym przypadku 443):

…z niemapowanego dysku Windows, aby uniknąć “Access Denied”:
netstat -aon | find “:443” Wyjście powinno wyglądać jak poniżej dla procesu System:
C:>netstat -ano |find “:443” TCP 0.0.0.0:443 0.0.0.0:0 LISTENING 4 TCP [::]:443 [::]:0 LISTENING 4 Ostatnia kolumna to PID (4).

1. Uruchamianie tasklist w celu sprawdzenia, co jest uruchomione w procesie, okazuje się bezużyteczne:
   tasklist /SVC /FI “PID eq 4” tasklist /m /FI “PID eq 4”

2. Poszukaj w rejestrze usługi HTTP: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HTTP\Parameters\UrlAclInfo Będzie tam lista adresów URL (z numerami portów), która może doprowadzić Cię do tego, która aplikacja jest uruchomiona i trzyma jakie porty:
   http:// +:5985/wsman/ –> WinRM https:// +:5986/wsman/ –> WinRM http:// +:80/Reports/ –> SQL Reporting Server http:// +: 80/ReportServer/ – }> SQL Reporting Server https:// server:443/Reports/ – }> SQL Reporting Server https:// server: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)

Możesz następnie znaleźć odpowiednią usługę w systemie i zatrzymać ją oraz sprawdzić, czy poszukiwany port został zwolniony, potwierdzając to innym poleceniem netstat -aon | find “:443”.

Miałem problem, że port 443 był używany przez “system” z PID 4 na mojej maszynie Windows 7. Rozwiązaniem dla mnie było usunięcie “Połączenia przychodzącego” (VPN), które istniało w folderze połączeń sieciowych.

Wygląda na to, że utworzyłem je i zapomniałem usunąć po użyciu…

Często jest to usługa VMware host agent (wymagana do komunikacji VM-host-to-gość) - vmware-hostd.exe.

Dobrym sposobem na sprawdzenie jaki proces podrzędny svchost.exe jest uruchomiony jest użycie Sysinternals’ Process Explorer .

Zmierzyłem się z podobnymi problemami z routingiem żądań 443 do mojego serwera WAS. Opierając się na zaleceniach w tym pytaniu, oto co zrobiłem:

1. Z podniesionego znaku zachęty cmd uruchomił netstat -a -n -o | findstr 443
2. Zidentyfikowałem PID procesu nasłuchującego na 443
3. Użyłem Process Explorera do zidentyfikowania procesu na podstawie PID.
4. W moim przypadku aplikacja nasłuchująca miała numer vmwarehostd.exe
5. Zatrzymałem serwer VMware Workstation z services.msc. Ponowne uruchomienie przez serwer WAS.

I wszystkie żądania 443 przyszły do 443 szczęśliwie.

PS: Odinstalowałem już skype'a, który był wbudowany w moją instalację Windows 8. Usługa routingu i zdalnego dostępu była wyłączona na moim komputerze.

Jeśli jest to proces uruchomiony przez usługę, netstat -ab nie pomoże.

W tym przypadku spróbuj netstat -ao | find /i "443" w wierszu poleceń administratora. To da ci wyjście jak poniżej:

TCP 0.0.0.0:443 your_hostname:0 LISTENING PID

Następnie wpisz tasklist | find /i "<PID>" w innym wierszu poleceń administratora.

W moim przypadku PID to 2912, a moja komenda to:

tasklist | find /i "2912"

Wyjście mojej komendy to:

vmware-hostd.exe 2912 Services 0 39 856 K

Wow, zapomniałem nawet, że zainstalowałem VMware, aby sprawdzić funkcjonalność…

W moim przypadku był to DataManager od F5 Networks, który używa wewnętrznie Tomcat 6 do serwowania swoich stron internetowych. Zapomniałem odinstalować tę aplikację. Zła decyzja projektowa, jeśli o mnie chodzi.

W moim przypadku był to proces DTC (Distributed Transaction Coordinator), który używał portu 443. W szczególności, aktywowałem WS-AT w DTC, a on używał portu 443.

Ogólnie rzecz biorąc, rozumiem, że kiedy proces System (PID 4) używa portu 443/HTTPS, jest to wewnętrzny proces Windows (w moim przypadku DTC, ale myślę, że może to być również inny proces), jeśli nie jest to witryna IIS, która go używa.

Używając netstat -ao | find ":443", odkryłem, że port 443 jest używany przez PID 4, który był procesem systemowym. Zdarzyło mi się to dwa razy na Windows Server 2012, i było to spowodowane jednym z następujących powodów:

1. Uruchomiony był IIS, wymieniony jako “World Wide Web Publishing Service” w Usługach, który zatrzymałem.
2. Zainstalowała się funkcja Work Folders, więc ją odinstalowałem.

To może nie być rozwiązanie dla każdego, ale niektórym może pomóc.

Odkryłem, że używanie funkcji VPN w Windows 8 (prawdopodobnie to samo dla Windows 7) używało portu 443.

Dodatkowo, mój port został ponownie zamknięty przez PMB.exe (Pando Media Booster).

U mnie, po aktualizacji Windows Server 2016, Apache 443 nie mógł się uruchomić z typowym zdarzeniem na liście.

Znalazłem winowajcę, aby być “Windows Sync Share” Service (SyncShareSvc). Wyłączyłem i byłem w stanie uruchomić Apache.

Dla mnie był to agent McAfee EPO nasłuchujący na porcie 80. Musiałem pokonać kilka bolesnych przeszkód, aby to zmienić. https://kc.mcafee.com/corporate/index?page=content&id=KB67605

Na moim Windows Server 2019 rozwiązałem go, uruchamiając ten PS.

Stop-Service -Name KPSSVC

Uruchomił się jako proces 4 (proces SYSTEM) z uprawnieniami Usługi sieciowe. Uruchomienie

netstat -ab

nie pomogło. Wyświetlił komunikat “Nie można uzyskać informacji o własności”.

Po zatrzymaniu usługi, netstat -aon | findstr “:443” nie pokazuje już wpisu. Dowiedziałem się tego poprzez literowe zatrzymywanie każdej usługi po kolei.

Usługa KDC Proxy Server (KPS) - Usługa KDC Proxy Server działa na serwerach brzegowych w celu przekazywania komunikatów protokołu Kerberos do kontrolerów domeny w sieci korporacyjnej.

Wireshark poda Ci szczegóły. http://www.wireshark.org/ ](http://www.wireshark.org/)Or TCP Monitor: http://www.itsamples.com/tcp-monitor.html

To pomoże.

Jeśli masz jakiś sterownik wirtualnej sieci LAN (jak OpenVM, VMware, etc…) - upewnij się, że ‘zwalniasz’ port przed przekazaniem go do czegoś innego…

Tylko szybka wskazówka ;)

Miałem ten sam problem podczas próby zainstalowania aktualizacji VMware. Udało mi się go zlokalizować w Skype. Nowy klient domyślnie ustawia się na 443.