Why is the 'System' process listening on port 443?

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?".

4

18 Answers

Run the following from an elevated command prompt:

netstat -ab
8

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

Alt text

7

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 ()...

  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

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 0.0.0.0:443 0.0.0.0:0 LISTENING 4
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
    :2869/ --> Simple Service Discovery Protocol service (SSDPSRV)
    :5357/ --> Web Services Dynamic Discovery (WS-Discovery)
    :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.

5

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...

4

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

3

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.

1

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 0.0.0.0:443 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

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.

6

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.

For me it was the McAfee EPO agent listening on port 80. I had to go through several painful hoops to get it changed.

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)

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

Wireshark will tell you the details. Or TCP Monitor:

That'll help.

4

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.

2

You Might Also Like