Ik wed dat het Skype is. Vink het vakje hieronder uit als u het geïnstalleerd hebt.

Voer het volgende uit vanaf een verhoogde opdrachtprompt:

netstat -ab

Allereerst zal ik deze vraag direct beantwoorden en iedereen die dit leest kan alle antwoorden negeren die gaan over 3rd-party, niet-Microsoft applicaties die gebruik maken van het Systeem Proces.

1. Het System proces staat vermeld als PID 4 op elk modern Windows systeem. Het is voor kernel-mode toegang. Dit sluit de meeste 3rd-party web producten zoals Apache uit.

2. Sinds het ontstaan van WinRM (Windows Remote Management), is de HTTP service ( %SystemRoot%%system32drivershttp.sys** ) een standaard onderdeel van Windows (Vista en later / Server 2008 en later). http.sys draait onder het System proces ( PID 4 ).

3. Andere door Microsoft ontwikkelde software kan ook gebruikmaken van de %SystemRoot%system32drivers http.sys onder het System-proces zoals IIS , SQL Reporting Services , en Microsoft Web Deployment Service http://support.microsoft.com/kb/2597817 )…

4. WinRM 1.0 standaard poorten waren:
   HTTP = 80 HTTPS = 443 WinRM 2.0 en hoger standaard poorten zijn:
   HTTP = 5985 HTTPS = 5986 Controleer met de volgende commando’s:
   Winrm enumerate winrm/config/listener Winrm get http://schemas.microsoft.com/wbem/wsman/1/config

Stappen voor probleemoplossing:

Verkrijg het procesnummer van de poort die u zoekt (443 in dit geval):

…van een niet-gemapte schijf van Windows om “Access Denied” te vermijden:
netstat -aon | find “:443” De uitvoer zou er als volgt uit moeten zien voor het System proces:
C:>netstat -ano |find “:443” TCP 0.0.0.0:443 0.0.0.0:0 LISTENING 4 TCP [::]:443 [::]:0 LISTENING 4 De laatste kolom is de PID (4).

1. Het uitvoeren van tasklist om uit te vinden wat er in het proces draait, blijkt niets op te leveren:
   tasklist /SVC /FI “PID eq 4” tasklist /m /FI “PID eq 4”

2. Zoek in het register naar de HTTP service: HKEYLOCALMACHINE\SYSTEM\CurrentControlSet\services\HTTP\Parameters\UrlAclInfo Er zal een lijst met URL’s (met de poortnummers) zijn die u kan leiden naar welke toepassing draait en welke poorten bezet zijn:
   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)

U kunt dan de corresponderende service op het systeem vinden en deze stoppen en zien dat de gewenste poort is vrijgegeven door dit te bevestigen met een ander netstat -aon | find “:443” commando.

Ik had het probleem dat poort 443 werd gebruikt door “system” met PID 4 op mijn Windows 7 machine. De oplossing voor mij was het verwijderen van een “Inkomende Verbinding” (VPN) die bestond in de map netwerkverbindingen.

Het lijkt erop dat ik het aangemaakt heb en vergeten ben het te verwijderen na gebruik…

Vaak is dit de VMware host agent service (nodig voor VM-host-to-guest communicatie) - vmware-hostd.exe.

Een goede manier om uit te vinden welk subproces svchost.exe draait is door gebruik te maken van Sysinternals’ Process Explorer .

Ik had soortgelijke problemen met het routeren van 443 verzoeken naar mijn WAS server. Gebaseerd op de aanbevelingen in deze vraag, is dit wat ik deed:

1. Vanaf de verhoogde cmd prompt liep netstat -a -n -o | findstr 443
2. Identificeerde de PID van het proces dat luistert op 443
3. Gebruikte Process Explorer om het proces te identificeren aan de hand van de PID.
4. In mijn geval was de applicatie die luisterde vmwarehostd.exe
5. Stopte de VMware Workstation server van services.msc. Opnieuw opgestart door de WAS server.

En alle 443 verzoeken kwamen gelukkig op 443 uit.

PS: Ik had skype al verwijderd, welke ingebouwd zat in mijn Windows 8 installatie. Routing en remote access service was uitgeschakeld op mijn machine.

Als het een proces is dat gestart is door een service, zal netstat -ab niet helpen.

Probeer in dit geval netstat -ao | find /i "443" in een administrator commandoregel. Dit zal je een uitvoer als deze geven:

TCP 0.0.0.0:443 your_hostname:0 LISTENING PID

Type dan tasklist | find /i "<PID>" in een andere beheerders opdrachtprompt.

In mijn geval was de PID 2912 en mijn commando was:

tasklist | find /i "2912"

De uitvoer van mijn commando was:

vmware-hostd.exe 2912 Services 0 39 856 K

Wow, ik ben zelfs vergeten dat ik VMware heb geïnstalleerd om een functionaliteit te controleren…

In mijn geval was het DataManager van F5 Networks die Tomcat 6 intern gebruikt om zijn webpagina’s te serveren. Ik vergat die app te verwijderen. Slechte ontwerp beslissing, als je het mij vraagt.

In mijn geval was het het DTC (Distributed Transaction Coordinator) proces dat de 443 poort gebruikte. In het bijzonder, ik activeerde WS-AT in DTC, en het gebruikte de 443 poort.

In het algemeen begrijp ik dat wanneer het System proces (PID 4) de 443/HTTPS poort gebruikt, het een intern proces van Windows is (in mijn geval DTC, maar ik denk dat het ook een ander proces kan zijn), als het niet een IIS website is die het gebruikt.

Met behulp van netstat -ao | find ":443", kwam ik erachter dat poort 443 wordt gebruikt door PID 4, wat het System proces was. Dit gebeurde mij twee keer op Windows Server 2012, en het was te wijten aan een van de volgende redenen:

1. IIS was aan het draaien, vermeld als “World Wide Web Publishing Service” in Services, die ik gestopt heb.
3. De functie Werkmappen was geïnstalleerd, dus die heb ik gedeïnstalleerd.

Dit is misschien niet voor iedereen een oplossing, maar het kan sommigen helpen.

Ik ontdekte dat het gebruik van de VPN-functionaliteit in Windows 8 (waarschijnlijk hetzelfde voor Windows 7) poort 443 gebruikte.

Bovendien werd mijn poort weer gesloten door PMB.exe (Pando Media Booster).

Bij mij, na de Windows Server 2016 update, kon Apache 443 niet starten met gebruikelijke gebeurtenis vermeld.

Ik vond de boosdoener te zijn “Windows Sync Share” Service (SyncShareSvc). Ik heb deze uitgeschakeld en kon Apache starten.

Bij mij was het de McAfee EPO agent die luisterde op poort 80. Ik moest door verschillende pijnlijke hoepels om het veranderd te krijgen. https://kc.mcafee.com/corporate/index?page=content&id=KB67605

Op mijn Windows Server 2019, loste ik het op door deze PS uit te voeren.

Stop-Service -Name KPSSVC

Het liep als proces 4 (SYSTEM-proces) onder Network Service-privileges. Het uitvoeren van

netstat -ab

hielp niet. Het gaf ‘Can not obtain ownership information’ weer.

Na het stoppen van de service, netstat -aon | findstr “:443” laat de entry niet meer zien. Uitgevonden door elke service één voor één te stoppen.

KDC Proxy Server service (KPS) - KDC Proxy Server service draait op edge servers om Kerberos protocol berichten te proxy'en naar domeincontrollers op het bedrijfsnetwerk.

Wireshark zal je de details vertellen. 0x3 of TCP Monitor: (http://www.wireshark.org/)

Dat zal helpen.

Als je een soort Virtuele LAN driver hebt (zoals OpenVM, VMware, etc..) - zorg er dan voor dat je de poort ‘vrijgeeft’ voordat je hem aan iets anders geeft…

Gewoon een snelle hint ;)

Ik had hetzelfde probleem toen ik een VMware update probeerde te installeren. Ik kwam erachter dat het Skype was. De nieuwe client staat standaard op 443.