I am having problems starting my Apache server, because port 443 is already in use.

It turns out, the system process (PID 4) uses the port 443. I don't have IIS installed, the services.msc shows (predictably) no Exchange server running, nor WWW-Services, nor IIS. I have no idea how to find out what service uses that port, short of just disabling each service one after the other, and I am not even sure that would help.

I would be grateful if someone could point me towards how I can get my SSL port back, thank you :)

P.S.: Of course "just switch Apache to another port for SSL" would solve the problem of not being able to start Apache. But I'd still like to know what is so insistent about hogging port 443. :)

I by now took the 'hard route' and disabled services one after the other. It turned out that the "Routing and RAS" service was the culprit.

Thank you all for the valuable input and the new tools in the combat against "WTF does my system do now?".

  • Related: superuser.com/questions/121901 You could use any of the answers given to help you determine which service is opening port 443.
    – heavyd
    Commented Mar 29, 2010 at 19:17
  • 1
    Unfortunately, as I am unable (or just too stupid) to find out which service exactely holds the port open, I cannot use "SC Config Servicename Type= own" for a lag of Servicename. Netstat's various incantation point me at the System process, as said, just like TCPView did. "Stacks", as for PE, don't work on Win7 apparently and as I do not look at a svchost.exe instance, I do not have a "Service" column on the TCP/IP tab. Skype is not at fault, nor do I have any other VoIP or P2P software running. But the other question you linked was enlightening to me; thank you.
    – Cornelius
    Commented Mar 29, 2010 at 21:41
  • Thanks for the info! For me it was "Routing and Remote Access" service that had binded port 443 also.
    – Codler
    Commented Apr 1, 2013 at 18:27
  • 6
    Man, the amount of answers not even trying to answer the question is incredible. So is the amount of misinformation. If PID 4 is listening, it’s http.sys. Always. Luckily, there’s already an answer on how to gain insight.
    – Daniel B
    Commented Aug 3, 2017 at 7:48

18 Answers 18


Run the following from an elevated command prompt:

netstat -ab
  • I am a bit surprised. Anything else showed just "the system process" as culprit. This command now claims that it -is- a svchost.exe that holds this port. :| How comes PE / 'other' netstat calls subsumed it under the System process? (Although the port is still shown as held by PID 4 / System.) How can I inspect further? :(
    – Cornelius
    Commented Mar 29, 2010 at 22:05
  • not sure but run PE elevated maybe!
    – tonyr roth
    Commented Mar 29, 2010 at 22:25
  • 2
    also the following may give you more insight wmic process > test.txt
    – tonyr roth
    Commented Mar 29, 2010 at 22:27
  • 1
    I did run process explorer as administrator -- and still the port shows up as claimed by "System"; not really much more intel available there :| By now I think it'll be something really stupid I unwittingly did ;)
    – Cornelius
    Commented Mar 29, 2010 at 22:40
  • 10
    This doesn't work for me, under the line with I just get Can not obtain ownership information.
    – MGOwen
    Commented Sep 24, 2014 at 11:08

I bet it's Skype. Uncheck the checkbox shown below if you have it installed.

Alt text

  • 3
    +1. Other VoIP clients (and other software like P2P file transfer apps) will listen on ports 80 and 443 if they find nothing else there, though Skype is the most common "offender". I'm not sure why Skype would be showing up as a system owned process though. Commented Mar 29, 2010 at 19:00
  • Unfortunately it is not Skype; nor other VoIP clients (none installed) nor P2P etc. etc. I checked that and it is not only "a system owned process", it is "the system process" (PID 4)
    – Cornelius
    Commented Mar 29, 2010 at 21:42
  • Oddly, I had the same issue as the OP - 443 was taken by svchost.. and yet, turning off Skype fixed it.
    – Blorgbeard
    Commented Jul 2, 2011 at 15:03
  • Had this problem. Followed these instructions and figured out it was Skype: mydigitallife.info/… Commented Mar 15, 2012 at 21:41
  • Just for clarity's sake: If your port is held by svchost and plainly visible in Process Explorer, it was not the same problem I had. Hence my insistence on making clear that the process with the name "System" seemed to own the port.
    – Cornelius
    Commented Oct 29, 2012 at 10:43

First off, I will answer this question directly and anyone reading this can ignore any answers talking about 3rd-party, non-Microsoft applications using the System Process.

  1. The System process is listed as PID 4 on every modern-day Windows system. It is for kernel-mode access. This rules out most 3rd-party web products like Apache.

  2. Since the inception of WinRM (Windows Remote Management), the HTTP service (%SystemRoot%\system32\drivers\http.sys) has been a standard part of Windows (Vista and later / Server 2008 and later). http.sys runs under the System process (PID 4).

  3. Other Microsoft-developed software may also use the %SystemRoot%\system32\drivers\http.sys under the System process like IIS, SQL Reporting Services, and Microsoft Web Deployment Service (http://support.microsoft.com/kb/2597817)...

  4. WinRM 1.0 default ports were:
    HTTP = 80
    HTTPS = 443
    WinRM 2.0 and greater default ports are:
    HTTP = 5985
    HTTPS = 5986
    Check with the following commands:
    Winrm enumerate winrm/config/listener
    Winrm get http://schemas.microsoft.com/wbem/wsman/1/config

Troubleshooting steps:

Get the process number of the port that you are looking for (443 in this case):

...from a non-mapped drive of Windows to avoid "Access Denied":
netstat -aon | find ":443"
Output should look like the following for the System process:
C:>netstat -ano |find ":443"
TCP [::]:443 [::]:0 LISTENING 4
The last column is the PID (4).

  1. Running tasklist to find out what is running in the process proves unhelpful:
    tasklist /SVC /FI "PID eq 4"
    tasklist /m /FI "PID eq 4"

  2. Look in the registry for the HTTP service: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HTTP\Parameters\UrlAclInfo
    There will be a list of URLs (with the port numbers) which can lead you to which application is running and holding which 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/ --> Simple Service Discovery Protocol service (SSDPSRV)
    http://* :5357/ --> Web Services Dynamic Discovery (WS-Discovery)
    https://* :5358/ --> Web Services Dynamic Discovery (WS-Discovery)

You can then find the corresponding service on the system and stop it and see that wanted port is released by confirming with another netstat -aon | find ":443" command.

  • Regarding point 6, how do we find the process listening for those ports?
    – galmok
    Commented Nov 22, 2018 at 11:31
  • 3
    This is by far(as of my reading) the most valuable answer. However, it doesn't resolve my problem. I'm having the problem on a Windows Server 2016 and the above step 6 shows https://+:443/sra_{BA195980-CD49-458b-9E23-C84EE0ADCD75}/ on my server. The GUID BA1959xxx indicates an SSTP server. But I'm sure I'm running at least another process listening on 443 other than the SSTP server. Anyway, I vote up for you.
    – Robert
    Commented Dec 3, 2019 at 8:31
  • 6
    Thanks to your answer I looked up http.sys, and found the command netsh http show servicestate which dumps a lot of data including the actual current listening URLs. It solved my problem of "why is SYSTEM listening on port X", it could help others.
    – Medinoc
    Commented Feb 12, 2020 at 17:22
  • I found vmware client was using the port 443 Commented Aug 10, 2020 at 23:33
  • Step 6 is very valuable. In my case what I did was to edit ALL the registries using :443 to something like :4443 (another port) and restarted the system. After that I was able to start my IIS website Commented Jan 18, 2022 at 14:06

I had the problem that port 443 was used by "system" with PID 4 on my Windows 7 machine. The solution for me was to delete a "Incoming Connection" (VPN) which existed in the network connections folder.

It seems that I created it and forgot to delete it after usage...

  • 1
    Yep, had the same issue on Windows 8.1. Commented Feb 1, 2015 at 15:37
  • just did that win7. It stopped listening on TCP 443 though still is listening on UDP port 443 though that may be good enough.
    – barlop
    Commented Jun 8, 2015 at 10:31
  • 1
    I had this issue on Windows Server 2008 R2 x64. Took me a while to find your post and I'm surprised at the official answer for this question, since it doesn't actually answer the question at all. Thank you! Commented Jan 2, 2016 at 10:47
  • It worked for me when instead of deleting the "Incoming Connection" (I don't remember how to create it again if I need it again) I unchecked [_] Allow other computers to connect to this one under Network and Sharing Center, Adapter Configuration, Incoming Connection, Properties. Commented Oct 9, 2018 at 23:14

Often this is the VMware host agent service (required for VM-host-to-guest communication) - vmware-hostd.exe.

A good way to find out what sub process svchost.exe is running is to use Sysinternals' Process Explorer.

enter image description here

  • 4
    If you indeed have VMware Workstation installed, check under Edit -> Preferences -> Shared VMs. You probably have VM sharing enabled and default port is 443. You can disable sharing, change port and enable it back or just leave it disabled if you don't need it.
    – gronostaj
    Commented Apr 14, 2016 at 10:50
  • 1
    @gronostaj Thank you so much i just spend 3 hours trying to find this :( Commented Dec 31, 2017 at 2:29
  • 1
    Note you must run VMware Workstation as an administrator, otherwise the "Disable Sharing" button will be grayed out. Commented Jul 14, 2020 at 21:45

I faced similar issues with routing 443 requests to my WAS server. Based on the recommendations in this question, this is what I did:

  1. From elevated cmd prompt ran netstat -a -n -o | findstr 443
  2. Identified the PID of the process listening on 443
  3. Used Process Explorer to identify the process from the PID.
  4. In my case the application listening was vmwarehostd.exe
  5. Stopped the VMware Workstation server from services.msc. Restarted by WAS server.

And all the 443 requests came to 443 happily ever after.

PS: I had already uninstalled skype which came builtin with my Windows 8 installation. Routing and remote access service was disabled in my machine.

  • 4
    -1 His was PID 4 it was much harder. You write "Used process explorer to identify the process from the pid." <-- Yours wasn't PID 4 e.g. svchost or something like that. Yours was some 3rd party exe. You could've just used task manager! If you're not showing the column already then view..choose column But you were lucky your PID wasn't PID 4. I don't know if process explorer could help there though task manager can't. But certainly in your case simple task manager would've done it.
    – barlop
    Commented Jun 8, 2015 at 10:33

If it is a process started by a service, netstat -ab won't help.

In this case try netstat -ao | find /i "443" in an administrator command line. This will give you an output like this:

    TCP   your_hostname:0   LISTENING   PID

Then type tasklist | find /i "<PID>" in another administrator command prompt.

In my case the PID was 2912 and my command was:

tasklist | find /i "2912"

The output of my command was:

vmware-hostd.exe   2912 Services   0   39 856 K

Wow, I have even forgotten that I installed VMware to check a functionality...

  • 2
    For me this was PID 4... being System. Still no clue :)
    – Wouter
    Commented Mar 14, 2017 at 14:36
  • PID 4 usually means a native Microsoft based Windows service, which means kernel level. Try stopping services one by one, and check if it solved the problem. Disable the service/uninstall the feature that @Wouter caused the issue. Usual services are: Routing and RAS, anything noting IIS or World Wide Puplishing, Exchange Windows Sync Share, Web Deployment Agent Service, SQL Server Reporting Services, File Server Storage Reports Manager and similar.
    – elbedoit
    Commented Jun 18, 2017 at 9:00

In my case it was DataManager from F5 Networks which uses Tomcat 6 internally to serve its web pages. I forgot to uninstall that app. Bad design decision, if you ask me.


Using netstat -ao | find ":443", I found out that port 443 is being used by PID 4, which was the System process. This happened to me twice on Windows Server 2012, and it was due to one of the following reasons:

  1. IIS was running, listed as "World Wide Web Publishing Service" in Services, which I stopped.
  2. The Work Folders feature installed, so I uninstalled it.

This might not be a solution for everyone, but it may help some.

  • This answer does not really add any new information that wasn't already in the answers submitted by elbedoit or tonyr
    – Ramhound
    Commented May 19, 2016 at 19:58
  • 1
    I specifically added this answer because uninstalling the Work Folders feature worked for me, and thus it is a potential solution to the problem as it it written. Should I present this information in a comment instead?
    – anishpatel
    Commented May 20, 2016 at 1:21
  • 1
    I had the same issue as stated in the question, and tonyr's answer did not work for me. elbedoit's answer does not help when you have PID 4 (as stated in the question); are you going to randomly stop/restart system processes to fix the issue?
    – anishpatel
    Commented Jul 5, 2016 at 20:25
  • 1
    No other answer mentions uninstalling the Work Folders feature, which is a solution to the question. I repeated the information from the other answer(s) to help others with the same issue identify if this solution may work for them (i.e., check to make sure PID is 4). If the PID is not 4, this answer will definitely not help. How is this answer any more incomplete then doener's or tonyr's answers? Please suggest how I can communicate my solution better.
    – anishpatel
    Commented Jul 6, 2016 at 20:32
  • 1
    Yes! It was also the Work Folders feature for me! Thanks a lot for mentioning this. It is indeed an equaly valid answer as mentioning Skype or any other service...
    – Wouter
    Commented Mar 14, 2017 at 16:36

In my case it was the DTC (Distributed Transaction Coordinator) process to use the 443 port. In particular, I activated WS-AT in DTC, and it was using 443 port.

In general, I understand that when the System process (PID 4) uses the 443/HTTPS port, it is an internal process of Windows (in my case DTC, but I think can be also another process), if it's not an IIS website using it.


For me, after the Windows Server 2016 update, Apache 443 could not start with usual event listed.

I found the culprit to be "Windows Sync Share" Service (SyncShareSvc). I disabled and was able to start Apache.


Open services from the start menu search and find and stop the Secure Socket Tunneling Protocol Service. Based on other answers I could infer that it's the underlying system service that sits on this port. I thought it's needed for VPNs but I could use a 3rd party one just fine with its own app. If it solved the problem feel free to disable it. It'll cause its dependencies to not run as well, which are Remote Access Connection Manager and Routing and Remote Access.

It was running after a completed Windows 10 update in 2022 April, I could use the port just fine just before that.

This likely happens because I used the allow incoming connections in the network connections window to set up Windows users (without their profiles) to create users for file sharing on the LAN (Samba). This option was left in, creating a VPN server I believe.

If you accepting incoming connections


For me it was the McAfee EPO agent listening on port 80. I had to go through several painful hoops to get it changed. https://kc.mcafee.com/corporate/index?page=content&id=KB67605


I found that using the VPN functionality in Windows 8 (probably the same for Windows 7) used port 443.

Additionally, my port closed up again by PMB.exe (Pando Media Booster).


On my Windows Server 2019, I solved it by running this PS.

Stop-Service -Name KPSSVC

It ran as process 4 (SYSTEM process) under Network Service privileges. Running

netstat -ab

did not help. It displayed 'Can not obtain ownership information'.

After stopping the service, netstat -aon | findstr ":443" does not show the entry anymore. Found out by literary stopping each service one by one.

KDC Proxy Server service (KPS) - KDC Proxy Server service runs on edge servers to proxy Kerberos protocol messages to domain controllers on the corporate network.

Another culprit could be Windows Admin Center (ServerManagementGateway)


Wireshark will tell you the details. http://www.wireshark.org/ Or TCP Monitor: http://www.itsamples.com/tcp-monitor.html

That'll help.

  • tcp-monitor unfortunately could not really help me at all; as for wireshark -- I was unable to generate / capture packets directed at port 443. :(
    – Cornelius
    Commented Mar 29, 2010 at 22:25
  • 1
    The only remaining option is Process Explorer (sysinternals) it'll show you proceses with ports. Wireshark is one of the top products in this line, but I can't comprehend why it didn't work for you :s (Did you install the WinPCAP capture driver?)
    – adeelx
    Commented Mar 30, 2010 at 18:10
  • Very late response, sorry. But I could not get anything to log because there apparrently just was no traffic to sniff. At least so I presume.
    – Cornelius
    Commented Oct 29, 2012 at 10:42
  • -1 Wireshark will not show you anything that might help identify what is on the port.. unless there are packets going to the port And even then, you should provide more info e.g. that the person should then ping the IP and try to find out what that IP is.
    – barlop
    Commented Jun 8, 2015 at 10:35

If you have some sort of Virtual LAN driver (like OpenVM, VMware, etc..) - make sure you 'release' the port before giving it to something else...

Just a quick side-hint ;)


I had the same trouble while trying to install a VMware update. I tracked it down to Skype. The new client defaults to 443.

  • 4
    This just a repeat of an existing answer. Please upvote existing answers rather than reposting.
    – Chenmunka
    Commented Nov 19, 2013 at 19:04
  • @Chenmunka Maybe he didn't read it Commented May 2, 2018 at 13:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .