Error: listen EACCES: permission denied 127.0.0.1:8000 #1048

New Issue

claunia · 2026-01-29T16:56:36Z

claunia commented

2026-01-29 16:56:36 +00:00

Originally created by @DYH1319 on GitHub (Jan 13, 2026).

Version: 0.4.0

Target: Windows, dotnet 10.0

Steps to Reproduce:

When I minimized the startup console application, the following error occurred:

A JavaScript error occurred in the main process
Uncaught Exception:
Error: listen EACCES: permission denied 127.0.0.1:8000
at Server.setupListenHandle [as listen2] (node:net:1881:21)
at listenlnCluster (node:net:1946:12)
at GetAddrlnfoReqWrap.doListen [as callback] (node:net:2116:7)
at GetAddrlnfoReqWrap.onlookup [as oncomplete] (node:dns:111:8)

I used the Windows netsh command to obtain a range of ports that, for reasons unknown, have been excluded by Windows, resulting in these ports being unavailable for use:
The GetActiveTcpListeners() method within GetFreePort() cannot retrieve the aforementioned excluded ports.

// PortHelper.cs

public static int GetFreePort(int? defaultPost)
{
    var listeners = IPGlobalProperties.GetIPGlobalProperties().GetActiveTcpListeners().Select(e => e.Port).ToList();

    int port = defaultPost ?? 8000;

    while (true)
    {
        if (!listeners.Contains(port))
        {
            return port;
        }

        port += 2;
    }
}

Originally created by @DYH1319 on GitHub (Jan 13, 2026).    * **Version**: 0.4.0   * **Target**: Windows, dotnet 10.0   Steps to Reproduce: 1. When I minimized the startup console application, the following error occurred: ```shell A JavaScript error occurred in the main process Uncaught Exception: Error: listen EACCES: permission denied 127.0.0.1:8000 at Server.setupListenHandle [as listen2] (node:net:1881:21) at listenlnCluster (node:net:1946:12) at GetAddrlnfoReqWrap.doListen [as callback] (node:net:2116:7) at GetAddrlnfoReqWrap.onlookup [as oncomplete] (node:dns:111:8) ``` 2. I used the Windows netsh command to obtain a range of ports that, for reasons unknown, have been excluded by Windows, resulting in these ports being unavailable for use: <img width="1113" height="892" alt="Image" src="https://github.com/user-attachments/assets/9906a434-548a-4529-9ee2-87cca133b52a" /> 3. The GetActiveTcpListeners() method within GetFreePort() cannot retrieve the aforementioned excluded ports. ```c# // PortHelper.cs public static int GetFreePort(int? defaultPost) { var listeners = IPGlobalProperties.GetIPGlobalProperties().GetActiveTcpListeners().Select(e => e.Port).ToList(); int port = defaultPost ?? 8000; while (true) { if (!listeners.Contains(port)) { return port; } port += 2; } } ```

claunia added the bug label 2026-01-29 16:56:36 +00:00

claunia commented

2026-01-29 16:56:37 +00:00

@DYH1319 commented on GitHub (Jan 14, 2026):

This is a port occupancy issue caused by Hyper-V. I have resolved it by directly executing netsh int ipv4 set dynamicport tcp start=49152 num=16384. Is it possible to exclude ports occupied by Hyper-V in the Electron.NET source code?

@DYH1319 commented on GitHub (Jan 14, 2026): This is a port occupancy issue caused by Hyper-V. I have resolved it by directly executing `netsh int ipv4 set dynamicport tcp start=49152 num=16384`. Is it possible to exclude ports occupied by Hyper-V in the Electron.NET source code?

claunia commented

2026-01-29 16:56:38 +00:00

@FlorianRappl commented on GitHub (Jan 14, 2026):

Is it possible to exclude ports occupied by Hyper-V in the Electron.NET source code?

No, in general you can always have such an issue - if its not Hyper-V then maybe some other software. We cannot possibly know all software or anything that can run (if we'd go after this we should not open any ports).

I think that the given code is flawed anyway - there is a better mechanism to reliably open a port.

@FlorianRappl commented on GitHub (Jan 14, 2026): > Is it possible to exclude ports occupied by Hyper-V in the Electron.NET source code? No, in general you can always have such an issue - if its not Hyper-V then maybe some other software. We cannot possibly know all software or anything that can run (if we'd go after this we should not open any ports). I think that the given code is flawed anyway - there is a better mechanism to reliably open a port.

claunia commented

2026-01-29 16:56:38 +00:00

@DYH1319 commented on GitHub (Jan 15, 2026):

Thank you for your response.

The GetFreePort() code provided above is internal to ElectronNet, located at https://github.com/ElectronNET/Electron.NET/blob/main/src/ElectronNET.API/Runtime/Helpers/PortHelper.cs.
It attempts to obtain an available port to serve as the listening port for Electron's socket (line 272 of https://github.com/ElectronNET/Electron.NET/blob/main/src/ElectronNET.Host/main.js#L272).
The port used cannot be modified externally.

Perhaps I didn't say it clearly. The netsh interface ipv4 show excludedportrange protocol=tcp command displays TCP port ranges excluded by the Windows system - not by some software. When Windows hosts software like WSL or Docker Desktop, it may reserve certain ports at the operating system level.

However, the current GetFreePort() method only selects a free port not currently being listened to. I think it's also necessary to choose the port not excluded by the Windows operating system.

@DYH1319 commented on GitHub (Jan 15, 2026): Thank you for your response. The GetFreePort() code provided above is internal to ElectronNet, located at https://github.com/ElectronNET/Electron.NET/blob/main/src/ElectronNET.API/Runtime/Helpers/PortHelper.cs. It attempts to obtain an available port to serve as the listening port for Electron's socket (line 272 of https://github.com/ElectronNET/Electron.NET/blob/main/src/ElectronNET.Host/main.js#L272). The port used cannot be modified externally. Perhaps I didn't say it clearly. The `netsh interface ipv4 show excludedportrange protocol=tcp` command displays TCP port ranges excluded by the Windows system - not by some software. When Windows hosts software like WSL or Docker Desktop, it may reserve certain ports at the **operating system level**. However, the current `GetFreePort()` method only selects a free port not currently being listened to. I think it's also necessary to choose the port not excluded by the Windows operating system.

claunia commented

2026-01-29 16:56:39 +00:00

@FlorianRappl commented on GitHub (Jan 15, 2026):

I think you misread my response.

What I've written is that we should change the GetFreePort to incl. only available ports (as written "reliably open a port", i.e., select a port that can be reserved and opened) - which means excl. OS occupied ports.

@FlorianRappl commented on GitHub (Jan 15, 2026): I think you misread my response. What I've written is that we should change the `GetFreePort` to incl. only available ports (as written "reliably open a port", i.e., select a port that can be reserved and opened) - which means excl. OS occupied ports.

claunia commented

2026-01-29 16:56:40 +00:00

@DYH1319 commented on GitHub (Jan 15, 2026):

My apologies for my question. I misread your response.

I can submit a PR to fix this issue.

When the platform is Windows, use Process to execute netsh interface ipv4 show excludedportrange protocol=tcp, parse the returned results, and apply them as additional exclusion criteria.

This is the solution I've devised. Is there a better approach?

@DYH1319 commented on GitHub (Jan 15, 2026): My apologies for my question. I misread your response. I can submit a PR to fix this issue. When the platform is Windows, use Process to execute `netsh interface ipv4 show excludedportrange protocol=tcp`, parse the returned results, and apply them as additional exclusion criteria. This is the solution I've devised. Is there a better approach?

claunia commented

2026-01-29 16:56:41 +00:00

@FlorianRappl commented on GitHub (Jan 15, 2026):

This is the solution I've devised. Is there a better approach?

Yes (potentially), we can be platform independent by following an approach reading the network interfaces, then just trying to open / use the port. If the port is blocked / refused, then try another one.

A good example is the get-port npm package.

@FlorianRappl commented on GitHub (Jan 15, 2026): > This is the solution I've devised. Is there a better approach? Yes (potentially), we can be platform independent by following an approach reading the network interfaces, then just trying to open / use the port. If the port is blocked / refused, then try another one. A good example is [the get-port npm package](https://github.com/sindresorhus/get-port/blob/main/index.js).

claunia commented

2026-01-29 16:56:42 +00:00

@softworkz commented on GitHub (Jan 15, 2026):

we can be platform independent by following an approach reading the network interfaces,

Why would that be required for being platform independent? Anyway, we don't need to deal with multi-homed network configurations. The simple way of port allocation will always open the port on local loopback.

Going through NIs can even be wrong when a port is opened specifically on local loopback only and we are probing a different NI, then the port would be available there - but not on local loopback where we need it.

@softworkz commented on GitHub (Jan 15, 2026): > we can be platform independent by following an approach reading the network interfaces, Why would that be required for being platform independent? Anyway, we don't need to deal with multi-homed network configurations. The simple way of port allocation will always open the port on local loopback. Going through NIs can even be wrong when a port is opened specifically on local loopback only and we are probing a different NI, then the port would be available there - but not on local loopback where we need it.

claunia commented

2026-01-29 16:56:42 +00:00

@softworkz commented on GitHub (Jan 15, 2026):

If we want to do it right, we would anyway need to find a PORT-PAIR rather than a single port, because the Electron side uses port+1.

@softworkz commented on GitHub (Jan 15, 2026): If we want to do it right, we would anyway need to find a PORT-PAIR rather than a single port, because the Electron side uses port+1.

claunia commented

2026-01-29 16:56:43 +00:00

@FlorianRappl commented on GitHub (Jan 15, 2026):

Why would that be required for being platform independent?

I am not sure I understand your question. We need to be able to run the code on multiple platforms, i.e., it must be capable not only of Windows, but also on Linux and MacOS.

@FlorianRappl commented on GitHub (Jan 15, 2026): > Why would that be required for being platform independent? I am not sure I understand your question. We need to be able to run the code on multiple platforms, i.e., it must be capable not only of Windows, but also on Linux and MacOS.

claunia commented

2026-01-29 16:56:43 +00:00

@softworkz commented on GitHub (Jan 15, 2026):

We need to be able to run the code on multiple platforms,

I know.

I am not sure I understand your question

Rephrased:

Why would it be required on Linux or MacOS to "read the network interfaces" for opening a port?

@softworkz commented on GitHub (Jan 15, 2026): > We need to be able to run the code on multiple platforms, I know. > I am not sure I understand your question Rephrased: Why would it be required on Linux or MacOS to "read the network interfaces" for opening a port?

claunia commented

2026-01-29 16:56:44 +00:00

@softworkz commented on GitHub (Jan 15, 2026):

Anyway - that's not where the problem lies.

The real problem is that once you have opened a port and closed it, there's no guarantee that you will be able to open it again immediately afterwards.
The way to deal with those situations is to use setsockopt(SO_REUSEADDRESS). But we cannot set that, because the second opening of the port is done by SocketIOClient - which doesn't set this of course).

For those reasons, GetActiveTcpListeners() was the most suitable option, yet - admittedly - I wasn't even aware of those port reservations' existence. Nonetheless, that's where I would put the focus on for fixing (like reading them somehow and adding these to the exclusion list.

@softworkz commented on GitHub (Jan 15, 2026): Anyway - that's not where the problem lies. The real problem is that once you have opened a port and closed it, there's no guarantee that you will be able to open it again immediately afterwards. The way to deal with those situations is to use `setsockopt(SO_REUSEADDRESS)`. But we cannot set that, because the second opening of the port is done by SocketIOClient - which doesn't set this of course). For those reasons, GetActiveTcpListeners() was the most suitable option, yet - admittedly - I wasn't even aware of those port reservations' existence. Nonetheless, that's where I would put the focus on for fixing (like reading them somehow and adding these to the exclusion list.

claunia commented

2026-01-29 16:56:45 +00:00

@softworkz commented on GitHub (Jan 15, 2026):

Side note: For getting a single free port, you don't do iterations over port numbers. You specify '0' as port and then your socket gets a free port assigned which you can read out then.

@softworkz commented on GitHub (Jan 15, 2026): Side note: For getting a single free port, you don't do iterations over port numbers. You specify '0' as port and then your socket gets a free port assigned which you can read out then.

claunia commented

2026-01-29 16:56:45 +00:00

@softworkz commented on GitHub (Jan 15, 2026):

Why would it be required on Linux or MacOS to "read the network interfaces" for opening a port?

I need to go out, so the answer is: It's not needed to use a specific NI to open a port. If you don't do that, the port will be open on all NIs (except for Multicast - in that case it's opened on the default NI only and you need to explicitly bind it on other NIs if you want).
You CAN open a port on a specific NI, but you only do that when you want to open the port on that specific NI - ONLY.

@softworkz commented on GitHub (Jan 15, 2026): > Why would it be required on Linux or MacOS to "read the network interfaces" for opening a port? I need to go out, so the answer is: It's not needed to use a specific NI to open a port. If you don't do that, the port will be open on all NIs (except for Multicast - in that case it's opened on the default NI only and you need to explicitly bind it on other NIs if you want). You CAN open a port on a specific NI, but you only do that when you want to open the port on that specific NI - ONLY.

claunia commented

2026-01-29 16:56:45 +00:00

@TANGHULU6 commented on GitHub (Jan 15, 2026):

I agree. Rather than iterating to find a free port, it might be safer to bind to port 0 and read back the port assigned by the OS.

@TANGHULU6 commented on GitHub (Jan 15, 2026): I agree. Rather than iterating to find a free port, it might be safer to bind to port 0 and read back the port assigned by the OS.

claunia commented

2026-01-29 16:56:46 +00:00

@DYH1319 commented on GitHub (Jan 15, 2026):

The real problem is that once you have opened a port and closed it, there's no guarantee that you will be able to open it again immediately afterwards.

This is indeed an issue worth considering.

For Windows platforms, we can simply use the netsh interface ipv4 show excludedportrange protocol=tcp command, parse the output, and add those ports to the exclusion list (I'm not sure if macOS and Linux platforms have excluded ports; in any case, this is the first time I've learned about Windows' excluded ports).

Alternatively, we could maintain the current approach: use TcpListener to check port availability (ignoring specific network interfaces) while additionally setting listener.ExclusiveAddressUse = false before startup. This allows the port to be reused for listening (perhaps?).

Alternatively, we could let Electron's socket choose its own startup port (by specifying port 0). However, if operating in dotnet first startup mode, this might require monitoring electron's console output or using inter-process communication (or perhaps a better method exists?) to obtain the listening port of electron's socket.

@DYH1319 commented on GitHub (Jan 15, 2026): > The real problem is that once you have opened a port and closed it, there's no guarantee that you will be able to open it again immediately afterwards. This is indeed an issue worth considering. For Windows platforms, we can simply use the `netsh interface ipv4 show excludedportrange protocol=tcp` command, parse the output, and add those ports to the exclusion list (I'm not sure if macOS and Linux platforms have excluded ports; in any case, this is the first time I've learned about Windows' excluded ports). Alternatively, we could maintain the current approach: use `TcpListener` to check port availability (ignoring specific network interfaces) while additionally setting `listener.ExclusiveAddressUse = false` before startup. This allows the port to be reused for listening (perhaps?). Alternatively, we could let Electron's socket choose its own startup port (by specifying port 0). However, if operating in dotnet first startup mode, this might require monitoring electron's console output or using inter-process communication (or perhaps a better method exists?) to obtain the listening port of electron's socket.

claunia commented

2026-01-29 16:56:46 +00:00

@softworkz commented on GitHub (Jan 15, 2026):

For Windows platforms, we can simply use the netsh interface ipv4 show excludedportrange protocol=tcp command, parse the output, and add those ports to the exclusion list

There's an API for this: LookupPersistentTcpPortReservation

Alternatively, we could maintain the current approach: use TcpListener to check port availability (ignoring specific network interfaces) while additionally setting listener.ExclusiveAddressUse = false before startup. This allows the port to be reused for listening

No, it does not, for the reasons I mentioned above. ExclusiveAddressUse is exactly doing what I said (just at a higher level than setsockopt()).
It's a bit confusing, though: Windows had traditionally some different behavior, using their own socket option "SO_EXCLUSIVEADDRUSE", which was almost - but not exactly - the opposite of SO_REUSEADDRESS. But later, MS worked towards improving portability and meanwhile, setting the ExclusiveAddressUse property from .NET does no longer set SO_EXCLUSIVEADDRUSE (which still exists), but the internal constant ExclusiveAddressUse (same name es the property).
Here's the definition from the .net source:

ExclusiveAddressUse = ~ReuseAddress,

(but anyway, I've come to a somewhat different verdict now...)

@softworkz commented on GitHub (Jan 15, 2026): > For Windows platforms, we can simply use the `netsh interface ipv4 show excludedportrange protocol=tcp` command, parse the output, and add those ports to the exclusion list There's an API for this: LookupPersistentTcpPortReservation > Alternatively, we could maintain the current approach: use TcpListener to check port availability (ignoring specific network interfaces) while additionally setting listener.ExclusiveAddressUse = false before startup. This allows the port to be reused for listening No, it does not, for the reasons I mentioned above. ExclusiveAddressUse is exactly doing what I said (just at a higher level than setsockopt()). It's a bit confusing, though: Windows had traditionally some different behavior, using their own socket option "SO_EXCLUSIVEADDRUSE", which was almost - but not exactly - the opposite of SO_REUSEADDRESS. But later, MS worked towards improving portability and meanwhile, setting the ExclusiveAddressUse property from .NET does no longer set SO_EXCLUSIVEADDRUSE (which still exists), but the internal constant ExclusiveAddressUse (same name es the property). Here's the definition from the .net source: `ExclusiveAddressUse = ~ReuseAddress,` (but anyway, I've come to a somewhat different verdict now...)

claunia commented

2026-01-29 16:56:46 +00:00

@softworkz commented on GitHub (Jan 15, 2026):

Here's my final assessment

After reading a bit and thinking about the case, my conclusion is this:

The case described here is a kind of one-off or a rare anomaly, which is unexpected and normally does not happen like this

The anomaly is not the existence of reserved port ranges - it's about the numeric range within which those reservations have been made. Normally, those reservations are either very targeted (.e.g. IIS reserves ports like 80 and 443 to prevent them from getting hijacked on restart) and specific, but when these are bulk reservations, they are normally made in the ephemeral or at least a rather high range of port numbers.

What the screenshot is showing in the OP is totally unacceptable (if it would be normal). The reservations cover a wide range of well-known ports, many of them officially assigned by IANA. Naturally, a Windows machine must never behave like this, and when we think about this, we suddenly see it very clear when putting it all together:

For example, in our software (Emby), we use a fixed default port of 8096. In all the years, I've never seen a single case where a user would have reported that our server cannot bind to that port
At least as far as I have followed, there hasn't ever been such report been made here in this repo (with that same underlying cause)
We were all wondering about never having heard that these reservations even exist. Why is that so?
=> Of course because it normally never happens that reservations are interfering with running applications like this!

As far as I'm seeing it, there's no need to make any change. It goes without saying that it's possible to find a better implementation. But that is a very very tricky subject which can't be accomplished by a quick PR. The devil's in the details and whatever somebody would implement will need careful testing on all platforms.

If someone wants to take a chance on this nonetheless, I would strongly prefer an implementation that doesn't wipe away the current mechanism (I know it's not great - but it's reliable...), and rather builds on top of it - something that comes into effect only in cases when the current method fails.

@softworkz commented on GitHub (Jan 15, 2026): ### Here's my final assessment After reading a bit and thinking about the case, my conclusion is this: The case described here is a kind of one-off or a rare anomaly, which is unexpected and normally does not happen like this The anomaly is not the existence of reserved port ranges - it's about the numeric range within which those reservations have been made. Normally, those reservations are either very targeted (.e.g. IIS reserves ports like 80 and 443 to prevent them from getting hijacked on restart) and specific, but when these are bulk reservations, they are normally made in the ephemeral or at least a rather high range of port numbers. What the screenshot is showing in the OP is totally unacceptable (if it would be normal). The reservations cover a wide range of well-known ports, many of them officially assigned by IANA. Naturally, a Windows machine must never behave like this, and when we think about this, we suddenly see it very clear when putting it all together: - For example, in our software (Emby), we use a fixed default port of 8096. In all the years, I've never seen a single case where a user would have reported that our server cannot bind to that port - At least as far as I have followed, there hasn't ever been such report been made here in this repo (with that same underlying cause) - We were all wondering about never having heard that these reservations even exist. Why is that so? => Of course because it normally never happens that reservations are interfering with running applications like this! As far as I'm seeing it, there's no need to make any change. It goes without saying that it's possible to find a better implementation. But that is a very very tricky subject which can't be accomplished by a quick PR. The devil's in the details and whatever somebody would implement will need careful testing on all platforms. If someone wants to take a chance on this nonetheless, I would strongly prefer an implementation that doesn't wipe away the current mechanism (I know it's not great - but it's reliable...), and rather builds on top of it - something that comes into effect only in cases when the current method fails.

claunia commented

2026-01-29 16:56:46 +00:00

@softworkz commented on GitHub (Jan 15, 2026):

Almost forgot - for comparison:

PS C:\Users\user> netsh interface ipv4 show excludedportrange tcp

Protocol tcp Port Exclusion Ranges

Start Port    End Port
----------    --------
     26638       26737
     26738       26837
     26838       26937
     26938       27037
     27038       27137
     27138       27237
     27238       27337
     27380       27479
     27480       27579
     49682       49781
     49782       49881
     49882       49981
     50000       50059     *
     50060       50159
     50160       50259
     50260       50359
     50360       50459
     50460       50559
     50560       50659

* - Administered port exclusions.

@softworkz commented on GitHub (Jan 15, 2026): Almost forgot - for comparison: ``` PS C:\Users\user> netsh interface ipv4 show excludedportrange tcp Protocol tcp Port Exclusion Ranges Start Port End Port ---------- -------- 26638 26737 26738 26837 26838 26937 26938 27037 27038 27137 27138 27237 27238 27337 27380 27479 27480 27579 49682 49781 49782 49881 49882 49981 50000 50059 * 50060 50159 50160 50259 50260 50359 50360 50459 50460 50559 50560 50659 * - Administered port exclusions. ```

claunia commented

2026-01-29 16:56:47 +00:00

@softworkz commented on GitHub (Jan 15, 2026):

On the other hand, if somebody wants do implement the P/Invoke into that Windows API for adding the reservations to the exclusion list - that's totally fine of course (even though I don't think it's necessary).

@softworkz commented on GitHub (Jan 15, 2026): On the other hand, if somebody wants do implement the P/Invoke into that Windows API for adding the reservations to the exclusion list - that's totally fine of course (even though I don't think it's necessary).

claunia commented

2026-01-29 16:56:47 +00:00

@DYH1319 commented on GitHub (Jan 16, 2026):

What the screenshot is showing in the OP is totally unacceptable (if it would be normal). The reservations cover a wide range of well-known ports, many of them officially assigned by IANA. Naturally, a Windows machine must never behave like this

I agree with you. If neither your software (Emby) nor this repository has ever seen user reports of port binding failures, I believe over 99.9% of users won't encounter this issue. Under normal circumstances, Windows shouldn't and won't reserve widely known ports. I should prioritize checking my own computer to find out why these ports are being reserved.

The devil's in the details and whatever somebody would implement will need careful testing on all platforms.

If virtually no one will encounter this problem, I think we don't need to consider it for now—at least until more user report it.

@DYH1319 commented on GitHub (Jan 16, 2026): > What the screenshot is showing in the OP is totally unacceptable (if it would be normal). The reservations cover a wide range of well-known ports, many of them officially assigned by IANA. Naturally, a Windows machine must never behave like this I agree with you. If neither your software (Emby) nor this repository has ever seen user reports of port binding failures, I believe over 99.9% of users won't encounter this issue. Under normal circumstances, Windows shouldn't and won't reserve widely known ports. I should prioritize checking my own computer to find out why these ports are being reserved. > The devil's in the details and whatever somebody would implement will need careful testing on all platforms. If virtually no one will encounter this problem, I think we don't need to consider it for now—at least until more user report it.

claunia commented

2026-01-29 16:56:47 +00:00

@softworkz commented on GitHub (Jan 16, 2026):

Windows shouldn't and won't reserve widely known ports. I should prioritize checking my own computer to find out why these ports are being reserved.

It's probably relatively easy to find out by whom and why they are being reserved, the question is rather why those reservations are being made within in the low range of ports...

While researching, I came across a number of things like registry keys, commands etc. - so there are some things worth exploring, but in the end, it might be just some stupid reason which none of us has on the plate...

If virtually no one will encounter this problem, I think we don't need to consider it for now—at least until more user report it.

Yes, I had thought the same: if there would be another one coming next week (or later), reporting the same issue - then that would turn the situation by 180°.

@softworkz commented on GitHub (Jan 16, 2026): > Windows shouldn't and won't reserve widely known ports. I should prioritize checking my own computer to find out why these ports are being reserved. It's probably relatively easy to find out by whom and why they are being reserved, the question is rather why those reservations are being made within in the low range of ports... While researching, I came across a number of things like registry keys, commands etc. - so there are some things worth exploring, but in the end, it might be just some stupid reason which none of us has on the plate... > If virtually no one will encounter this problem, I think we don't need to consider it for now—at least until more user report it. Yes, I had thought the same: if there would be another one coming next week (or later), reporting the same issue - then that would turn the situation by 180°.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/Electron.NET#1048