49

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
  • Related: superuser.com/questions/121901 You could use any of the answers given to help you determine which service is opening port 443. – heavyd Mar 29 '10 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 Mar 29 '10 at 21:41
  • Thanks for the info! For me it was "Routing and Remote Access" service that had binded port 443 also. – Codler Apr 1 '13 at 18:27
  • 4
    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 Aug 3 '17 at 7:48

17 Answers 17

19

Run the following from an elevated command prompt:

netstat -ab
8
  • 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 Mar 29 '10 at 22:05
  • not sure but run PE elevated maybe! – tonyr roth Mar 29 '10 at 22:25
  • 2
    also the following may give you more insight wmic process > test.txt – tonyr roth Mar 29 '10 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 Mar 29 '10 at 22:40
  • 8
    This doesn't work for me, under the line with 0.0.0.0:443 I just get Can not obtain ownership information. – MGOwen Sep 24 '14 at 11:08
32

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

Alt text

7
  • 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. – David Spillett Mar 29 '10 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 Mar 29 '10 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 Jul 2 '11 at 15:03
  • Had this problem. Followed these instructions and figured out it was Skype: mydigitallife.info/… – saturdayplace Mar 15 '12 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 Oct 29 '12 at 10:43
19

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

4
  • Regarding point 6, how do we find the process listening for those ports? – galmok Nov 22 '18 at 11:31
  • 1
    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 Dec 3 '19 at 8:31
  • 2
    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 Feb 12 '20 at 17:22
  • I found vmware client was using the port 443 – Alex Angelico Aug 10 '20 at 23:33
11

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
  • 1
    Yep, had the same issue on Windows 8.1. – Konstantin Pereiaslov Feb 1 '15 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 Jun 8 '15 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! – simontemplar Jan 2 '16 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. – Alexander Gelbukh Oct 9 '18 at 23:14
9

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.

3
  • 3
    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 Apr 14 '16 at 10:50
  • @gronostaj Thank you so much i just spend 3 hours trying to find this :( – Simon Kirsten Dec 31 '17 at 2:29
  • Note you must run VMware Workstation as an administrator, otherwise the "Disable Sharing" button will be grayed out. – pacoverflow Jul 14 '20 at 21:45
7

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
  • 3
    -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 Jun 8 '15 at 10:33
6

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
  • 2
    For me this was PID 4... being System. Still no clue :) – Wouter Mar 14 '17 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 Jun 18 '17 at 9:00
1

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.

1

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
  • This answer does not really add any new information that wasn't already in the answers submitted by elbedoit or tonyr – Ramhound May 19 '16 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 May 20 '16 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 Jul 5 '16 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 Jul 6 '16 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 Mar 14 '17 at 16:36
1

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.

1

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.

0

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

0

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

0

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)

-1

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

That'll help.

4
  • 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 Mar 29 '10 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 Mar 30 '10 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 Oct 29 '12 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 Jun 8 '15 at 10:35
-1

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 ;)

-2

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
  • 4
    This just a repeat of an existing answer. Please upvote existing answers rather than reposting. – Chenmunka Nov 19 '13 at 19:04
  • @Chenmunka Maybe he didn't read it – FindOutIslamNow May 2 '18 at 13:51

Not the answer you're looking for? Browse other questions tagged or ask your own question.