How can I determine why the System process is listening on port 80?


A customer observed that the System process was listening on port 80 and couldn't figure out why.

The netsh http show urlacl command will show which URLs have been reserved, as well as the access control lists (ACLs) associated with them.

Reserved URL : http://+:80/Temporary_Listen_Addresses/
  User: \Everyone
    Listen: Yes
    Delegate: No
    SDDL: D:(A;;GX;;;WD)

Reserved URL : http://+:80/0131501b-d67f-491b-9a40-c4bf27bcb4d4/
  User: NT AUTHORITY\NETWORK SERVICE
    Listen: Yes
    Delegate: No
    SDDL: D:(A;;GX;;;NS)

Reserved URL : http://+:80/116B50EB-ECE2-41ac-8429-9F9E963361B7/
  User: NT AUTHORITY\NETWORK SERVICE
    Listen: Yes
    Delegate: No
    SDDL: D:(A;;GX;;;NS)

At this point, you have information you can enter into a search engine to see what they're about.

The first URL is used by the Windows Communication Framework; this web page tells you how to modify or delete it.

The second one is assigned to [MS-PCHC]: Peer Content Caching and Retrieval: Hosted Cache Protocol, which appears to be used for subnet-level peer caching as part of Windows BranchCache.

The third one is assigned to [MS-PCCRR]: Peer Content Caching and Retrieval: Retrieval Protocol, which also part of Windows BranchCache.

The customer confirmed that disabling BranchCache caused Windows to stop listening on the second and third URLs.

Comments (10)
  1. ChDF T says:

    When running the command on a non-English system (German in my case; tested and reproduced on Windows 7 and Server 2016), I noticed that while the output is localized (i.e. “Benutzer” instead of “User”), the “Yes”/”No” for the listen and delegate properties are not.
    Were these two values missed when translating or has some important-enough application tried to parse the output and relied on it being English?

    1. I filed a bug to double-check. Thanks for pointing it out.

      1. Entegy says:

        Same thing in fr-CA, Windows 10 v1803. Everything is translated except Yes/No.

        1. henke37 says:

          Here in Sweden everything is in English, sans the resolved usernames.

      2. Team responded that this is unfortunate, but netsh is deprecated in favor of PowerShell, so there no real benefit to improving a deprecated technology.

        1. Vince Valenti says:

          Cool. Except that there is no first party PowerShell equivalent to netsh http.

        2. Joshua says:

          Unfortunately netsh is so much better documented.

          1. Joker_vD says:

            I guess it’s some kind of a Murphy’s law, that the current things are always underdocumented, so if there is a thing that is properly documented, it must be deprecated.

        3. Voo says:

          So what is the comparable PowerShell command to the given netsh ones? If we’re at it the one for sslcert would be useful too.

          It certainly looks like they deprecated a tool without having replacements for most of its functionality.

          1. Ian Yates says:

            Maybe the word deprecated is an unfortunate choice?

            Could we consider netsh to be “done” instead? No further changes short of fixing critical bugs. That is, all issues start with -1000 points instead of the usual -100.

Comments are closed.

Skip to main content