System process is using a port, why? Windows 7

Question

Is there a generic way to find out which service listens to a port as the System process?

In my case, the System process, PID 4, is listening on the port 443 (https), so another program that needs this port cannot start.

Before, for many years the system did not use this port, so I could use that another program.

How can I figure out what causes the system to listen to that port?

netstat -a -b -o run under elevated prompt shows

TCP 0.0.0.0:443 MyComputerName:0 LISTENING 4
Can not obtain ownership information

I have Apache installed, but when I stop it, nothing changes. I have IIS uninstalled. Other suspects are Skype, CrashPlan, and MySQL server, but they have run on this computer for years without causing this problem. Skype has the option [_] Use port 80 and 443 unchecked. Putting CrashPlan to sleep does not release the port.

I have asked this question on StackOverflow, but it was deemed off-topic there.

There is a similar question on the port 80, but the answers there only say to stop this or that specific service, which does not generalize to another port.

There is another similar question, but in that case the OP comments that the netstat -ab shows svchost.exe as the source of connection, and none of the answers solve the problem in my case.

Solution

From my reading, there can be multiple causes. For instance, after reading Cornelius's question: “Why is the System process listening on Port 443?”, I get the impression that at least these three different causes can lead to such a thing:

• HTTP.SYS related to IIS (Microsoft's web server)
• A network connection accepting an incoming VPN connection. (Possibly related to "Remote Access", part of RRAS which is "Routing and Remote Access"?)
• Skype (see the hyperlink earlier in my answer, for pictures).

I'm guessing these have some common factors, such as using Microsoft code and probably using a low-level driver.

I would think there has to be a way to just check, instead of hunting. The TCP/IP stack has to know where to send the traffic, and we can check what the TCP/IP stack will do using the netstat command. Unfortunately, all the netstat command is giving us is the system-wide PID, which points us to a process named "System". I would think that, similarly, the "System" process must have a way to know which driver to send the traffic to. I have not yet found a way to just check that.

Meanwhile, I figured I'd point you to multiple possible causes I did find. Hopefully one of those will lead to you finding the answer you're seeking.

Note: The way I found this cause was by looking at some of the promising "Related" items that Superuser.com displays in the right frame. One of the basic rules of Stack Exchange is to try doing your own prior research. I suggest another good rule is that after you post a question, do check the section called "Related" in the right frame, because IMHO Stack Exchange does a pretty good job of frequently finding very on-topic questions.

On my Microsoft Windows system, PID 4 also belongs to the System process, so it does not appear that particular PID is very random.

The rest of this question just explains some things I checked on my system. It won't help you (Alexander Gelbukh) much because I can tell that you've already figured most or all of this out already. However, hopefully people reading that will be less inclined to blindly recommend netstat as a solution, since netstat's output is not a complete, sufficient solution (because we need to do more than just identify the process that the TCP/IP networking stack will send the traffic to).

I think there can be multiple reasons that netstat -b may say Can not obtain ownership information, including a lack of UAC elevation (at least on some versions of Microsoft Windows; on my Windows 10 I get different results when running un-elevated: netstat just immediately says The requested operation requires elevation. and gives two blank lines, and quits.)

I'm getting the same results as you: When I do run elevated, I cannot seem to see the results of PID 4.

Proto Local Address Foreign Address State PID TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 996 RpcSs [svchost.exe] TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4 Can not obtain ownership information TCP 0.0.0.0:8732 0.0.0.0:0 LISTENING 4 Can not obtain ownership information

(This says PID 996 is svchost.exe, but no info on PID 4.)

C:>tasklist /SVC | more

Image Name PID Session Name Session# Mem Usage ========================= ======== ================ =========== ============ System Idle Process 0 Services 0 4 K System 4 Services 0 4,828 K

C:\WINDOWS\system32>powershell "Get-NetTCPConnection -LocalPort 445 | Format-List"

LocalAddress : :: LocalPort : 445 RemoteAddress : :: RemotePort : 0 State : Listen AppliedSetting : OwningProcess : 4 CreationTime : 3/2/2017 9:56:19 PM OffloadState : InHost

C:\WINDOWS\system32>

Comments

[Biswapriyo]

See the IP address, it is 0.0.0.0, which is not a routable address.

[Alexander Gelbukh]

@Biswa Thank you! I think 0.0.0.0 means to listen at all available interfaces (I have only one, but if I had two, this program would listen at both). howtogeek.com/225487/… says "In the context of servers, 0.0.0.0 means all IPv4 addresses on the local machine."

[TOOGAM]

@Biswa: Correct. I explain this in my answer about :::, responding to a question that also asked about 0.0.0.0. Basically, 0.0.0.0 indicates no address. By having no address specified, the result is listening to any address (instead of a specific address). So, I validate that conclusion.

[TOOGAM]

Oops, I meant @AlexanderGelbukh (not @Biswa). Oh well; both would receive that last comment (and this one) even without an @ in my comment.

[Alexander Gelbukh]

Thank you! Yes, as you have correctly noted, this information gives more details on the question but unfortunately does not provide an answer, or hints on any further action. And yes, I digged through related questions, but only found answers that say "try disabling this or that specific program" and not providing any generic way of actions. None of those programs seems to be the cause in my case. Any better idea?

[TOOGAM]

To respond to your comment's second sentence, in particular, my answer's second bullet point was a direct and unique answer: an idea that wasn't already dismissed in the question. I intentionally put that near the top to be easily found. As for your 3rd sentence seeking a "generic way", I address that idea in my paragraph starting with "I would", essentially stating that I don't have such a series of steps at this time.

[Alexander Gelbukh]

Thank you! Yes, VPN has been dismissed, too (among many other specific things that people mention in related questions) -- sorry I did not specify it in the question.