Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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

Edit: 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".

share|improve this question
Related: 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
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

14 Answers 14

up vote 12 down vote accepted

Run the following from an elevated command prompt:

netstat -ab
share|improve this answer
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
also the following may give you more insight wmic process > test.txt – tonyr roth Mar 29 '10 at 22:27
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
This doesn't work for me, under the line with I just get Can not obtain ownership information. – MGOwen Sep 24 '14 at 11:08

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

alt text

share|improve this answer
+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:… – 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

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

A good way to find out what sub process svchost.exe is running is to use sysinternals process explorer.

share|improve this answer
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 at 10:50

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.

Seems that i created it and forgot to delete it after using...

share|improve this answer
Yep, had the same issue on Windows 8.1. – Konstantin Pereyaslov 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
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 at 10:47

I faced similar issues with routing 443 requests to my WAS server. Based on the recommendations in this thread 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 windows8. Routing and remote access service was disabled in my machine

share|improve this answer
-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

In my case 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 System process (PID 4) use 443/https port is a 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.

share|improve this answer

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

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

    TCP   your_hostname:0   LISTENING   PID

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

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 had installed VMware to check a functionality...

share|improve this answer

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.

share|improve this answer

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

share|improve this answer

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

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

share|improve this answer

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

share|improve this answer

Wireshark will tell you the details. Or TCP Monitor:

That'll help.

share|improve this answer
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
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

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

share|improve this answer
This just a repeat of an existing answer. Please upvote existing answers rather than reposting. – Chenmunka Nov 19 '13 at 19:04

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.

share|improve this answer
This answer does not really add any new information that wasn't already in the answers submitted by elbedoit or tonyr – Ramhound May 19 at 19:58
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 at 1:21
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 at 20:25
Still does not change the fact this answer seems incomplete and seems to repeat the same information that already exists in existing questions. – Ramhound Jul 5 at 21:30
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 at 20:32

You must log in to answer this question.

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