How to see what is reserving ephemeral port ranges on Windows?

Question

I have a Windows application that needs to use ports 50005 and 50006 but it is being blocked.

I see the following when I run netsh int ip show excludedportrange protocol=tcp:

Protocol tcp Port Exclusion Ranges

Start Port    End Port
----------    --------
5357        5357
49709       49808
49809       49908
49909       50008
50009       50108
50109       50208
50280       50379

* - Administered port exclusions.

So something on my machine is reserving ports 49909 to 50008, which is presumably what is causing my application to fail. I've tried deleting this excludedportrange with the following command:

netsh int ip delete excludedportrange protocol=tcp numberofports=100 startport=49909

But I see an error Access is denied., which makes me think that whatever is reserving this ports is actively running, but I have no idea what that could be.

What's also weird is that after running that command, even though I saw an error, if I reboot the excludedportrange will be different.

As a sanity check I've also run resmon.exe and confirmed that there is nothing running on ports 50005 and 50006.

How can I tell what is adding the excludedportrange?

EDIT: I've narrowed this down to Hyper-V. If I disable Hyper-V then those ports are not excluded.

Sized

why dont you try executing the netstat -a -b to figure out manually what services are being executed at the given ports – Sarajane

If your application depends on specific ports, you need to use user ports and register those ports with IANA: "Assigned ports both System and User ports SHOULD NOT be used without or prior to IANA registration." – King

"Access is denied" probably just because you ran a command prompt without elevation. Only elevated administrator processes can make changes to the network settings – Bedspread

@AnkurGoel Nothing appears to be using anything in those port ranges. – Sized

@BenVoigt I'm running the command prompt as administrator. – Sized

Turning off Hyper-V worked for me. Went to Turn Windows features on or off and unselected Hyper-V (Windows 10). I think the issue was that Hyper-V was randomly reserving the port range that included ports I needed to run – Huxley

The solution is to reserve the ports on boot before running any hyper-v related assets. See #48479369. I believe you can't release the ports because they were reserved with SYSTEM principal. – Bianchi

Turning off Hyper-V worked for me too. It was reserving 4400-4500'ish range that I was trying to use. – Referential

This is insane. Reserved port ranges? No way to see what reserved them, and cannot unreserved them with Admin privileges? What kind of screwed up feature is this? This is suddenly halting development with "port in use" errors and nothing is using the port. After another botched windows update that I did not authorize (Windows just forces it now, in spite of disabling the service). – Balenciaga

@Sized did anyone ever work this out? My Sonos is trying to bind to port 3410 but that's in the exclusion range (which is really very long) and I can't work out what's doing it - as with you Liam there's nothing actually using port 3410, but the bind is being disallowed by Windows anyway – Strait

@liam did you found any solution for this. in my case the list of excluded ranges has 45 entries and it is changing after every restart. i unsinstalled hyper-v (the only suspect i had) – Conceive

Answer 1

Investigate and Free the Ports

It appears that Hyper-V reserves random ports (or something Hyper-V related at least). Use netsh int ip show excludedportrange protocol=tcp to confirm that the ports that aren't working are in the output.

This has worked for me to free the ports up. It doesn't seem intrusive to me (25 thumbs up):

This is often caused by the Windows NAT Driver (winnat), stopping and restarting that service may resolve the issue.

net stop winnat
docker start ...
net start winnat

After this the ports were no longer reserved, but my WSL2 terminal no longer had connection to the internet, so I needed to reboot after this to get everything working again.

Reserve the Ports From Now On

If you don't do anything more, you'll likely run into this problem again. So to e.g. reserve ports 9012 and 9013 for your future use (so winnat never tries to use them):

netsh int ipv4 add excludedportrange protocol=tcp startport=9012 numberofports=2

(Thanks @Venryx for reminding me)

Other Approaches

In an answer to a similar question about why docker couldn't open ports (24 thumbs up), this also worked for me:

netcfg -d --this will clean up all networking devices, and requires a reboot

Somebody does warn about it though (4 thumbs up). Your maileage may vary. It worked for me, mostly because I didn't see the following warning until after I ran it successfully....

that (netcfg -d) is dangerous command, it corrupted my docker and it does not start up anymore. Even after reinstalling HyperV. and rebooting machine. It seems that this command removes several network adapters. Also restart does nothing. I had to reset (loose) containers and images but that led me to another issue

another answer to a similar docker question (129 thumbs up) has this, but it seemed much more involed for me, so I didn't try it:

@veqryn the workaround worked for me, the steps are:

1. Disable hyper-v (which will required a couple of restarts)

   dism.exe /Online /Disable-Feature:Microsoft-Hyper-V

2. When you finish all the required restarts, reserve the port you want so hyper-v doesn't reserve it back

   netsh int ipv4 add excludedportrange protocol=tcp startport=50051 numberofports=1 store=persistent

3. Re-Enable hyper-V (which will require a couple of restart)

   dism.exe /Online /Enable-Feature:Microsoft-Hyper-V /All

when your system is back, you will be able to bind to that port successfully.

Ulbricht

I tried the winnat service restart to succesfully free up the ports as that seems like the easiest optoin. Hopefully it continues to work for me in the future and does not corrupt anything – Surbase

I agree, @YogeshJindal. It is also the one I now use when I run into this from time to time. I've edited the post to make it the first suggestion. – Licensee

Stopping and restarting "winnat" (whatever that is) worked for me. It worked immediately, didn't even require a restart. Windows 10 Pro 20H2 19042.804 Windows Feature Experience Pack 120.2212.551.0 – Vedavedalia

Thanks @zentrunix, I've clarified my answer. The reason I needed to reboot after stop/start winnat was that it broke my WSL2 networking. – Licensee

Is there an answer to original question - which process exactly has reserved the range? (Not workarounds with stopping something hoping port range will be unreserved.) – Odel

Thanks so much! Those last three steps from an administrator command shell work for me. I run Hugo locally and normally it grabs port 1313, but lately it wasn't able to even after a reboot. Disabling Hyper-V as above, running netsh int ipv4 add excludedportrange protocol=tcp startport=1313 numberofports=2 store=persistent, re-enabling Hyper-V, and rebooting fixed it. – Eyeopening

For my setup at least, the above fixes were just workarounds for the root problem, which was that the dynamic-ports range was set incorrectly on my pc. I found the solution here: https://mcmap.net/q/217293/-cannot-bind-to-some-ports-due-to-permission-denied – Christinchristina

For me, restarting winnat breaks networking in WSL - so this doesn't seem like a good solution – Anathema

@Odel we still don't know. Hyper-V and Winnat are suspects... – Penicillate

@szx: As I wrote: "WSL2 terminal no longer had connection to the internet, so I needed to reboot after this to get everything working again." I also had to reboot, but couldn't find any better solution. Do you have a better solution? – Licensee

Answer 2

Set the Windows "Dynamic Port Range" in a non conflicting place

We managed to contain this problem, for the case where you can not change your ports' needs to other location (like a non configurable application).

When you issue the command:

netsh int ip show excludedportrange protocol=tcp

You get an output with a list of port ranges reserved:

Protocol tcp Port Exclusion Ranges

Start Port    End Port
----------    --------
     33474       33573
     50000       50059     *
     58159       58258
     58259       58358
     58359       58458
     58459       58558
     58559       58658
     58659       58758
     58759       58858

* - Administered port exclusions.

The most likely reason for this is the Windows Hyper-V (Microsoft's hardware virtualization product) that reserves random port ranges (usually blocks of 100 ports). This becomes a pain, because if you are developing an application or larger solution that uses multiple ports, some times you get a conflict and some times not after rebooting your system.

To lookup for the "Dynamic Port Range" you can issue the command:

netsh int ipv4 show dynamicport tcp

The answer:

Protocol tcp Dynamic Port Range
---------------------------------
Start Port      : 1024
Number of Ports : 64511

You can instruct Windows to modify this range out of the conflicting area.

Let's say your development is under and up to port 60000, you can issue the following command to restrict the dynamic port range out of it (you must have administrator privileges):

netsh int ipv4 set dynamic tcp start=60001 num=5534

To make Hyper-V (and Windows in general) use this new dynamic range you have to reboot your system.

Now if we request the excluded port range:

netsh int ip show excludedportrange protocol=tcp

The response has changed:

Protocol tcp Port Exclusion Ranges

Start Port    End Port
----------    --------
     50000       50059     *
     63904       64003
     64004       64103
     64105       64204
     64205       64304
     64305       64404
     64405       64504
     64505       64604
     64605       64704

* - Administered port exclusions.

Only the "Administered port exclusions" remains below port 60001

Vivid

I prefer this answer. Very useful information, easy fix. However, I prefer to set 30,000-39,999 as the dynamic port range, since I do have a handful of programs trying to use ports in the 40k, 50k, and 60k ranges. I have yet to see any that use the 30k ports by default. – Curvilinear

Sure, the range suggested is only as an example, because the one needed depends of the case you are into. – Vivid

I recently learned that these dynamic ports are also needed for all outbound connections, and exhausting them can cause new connections to fail, so you ought to be generous with your allocation. – Curvilinear

Answer 3

I had the same problem and uninstalled Hyper-V, but the reserver ports were still there. After several attempts I identified Windows Sandbox as the culprit to be disinstalled

Hacking

Answer 4

Answer

First, confirm this answers applies to you by running netsh int ipv4 show dynamicport tcp in cmd.exe as admin.

If you see that the problematic port is within one of those ranges, then follow these steps:

1. Run cmd.exe as admin
2. Run netsh int ipv4 set dynamic tcp start=49152 num=16383
3. Restart your machine
4. Confirm the new dynamic port range netsh int ipv4 show dynamicport tcp

Rationale

The dynamic port range should be 49152-65535

Sources

• Microsoft on TCP IP port exhaustion troubleshooting

To comply with Internet Assigned Numbers Authority (IANA) recommendations, Microsoft has increased the dynamic client port range for outgoing connections. The new default start port is 49152, and the new default end port is 65535.

• IANA port ranges

Port numbers are assigned in various ways, based on three ranges: System Ports (0-1023), User Ports (1024-49151), and the Dynamic and/or Private Ports (49152-65535); the different uses of these ranges are described in [RFC6335]

• RFC6335

the Dynamic Ports, also known as the Private or Ephemeral Ports, from 49152-65535 (never assigned)

Tailspin