Thanks to visit codestin.com
Credit goes to github.com

Skip to content

HttpListener always fails with error 32 on ports 50000-50059 #115088

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
chylex opened this issue Apr 27, 2025 · 8 comments
Open

HttpListener always fails with error 32 on ports 50000-50059 #115088

chylex opened this issue Apr 27, 2025 · 8 comments
Assignees
@rokonec
Labels
area-System.Net untriaged New issue has not been triaged by the area owner

Comments

@chylex
Copy link

chylex commented Apr 27, 2025 •
edited
Loading

Description

Hi, I'm trying to have an HttpListener listen on 127.0.0.1:50000, but it always fails with error 32, saying that the process does not have access to a file because it's being used by another process.

However, there is no process listening on port 50000:

Image

Furthermore, there is no issue at all with the same port, if I use ASP.NET Core and Kestrel instead:

void SetKestrelOptions(KestrelServerOptions options) {
	options.ListenLocalhost(50000, static listenOptions => listenOptions.Protocols = HttpProtocols.Http1);
}

I tried all ports between 20000 and 65535, and the errors mostly correspond to ports that are actually being listened on by other programs, but then there's just a random(?) range of ports 50000-50059 that HttpListener always fails to listen on, despite no other program listening on them.

Reproduction Steps

public static void Main(string[] args) {
	HttpListener listener = new HttpListener();
	listener.Prefixes.Add("http://127.0.0.1:50000/");
	listener.Start();
}

Expected behavior

Call Start with no exceptions.

Actual behavior

System.Net.HttpListenerException (32): Proces nem� p��stup k souboru, nebo� jej pr�v� vyu��v� jin� proces.
   at System.Net.HttpListener.AddPrefixCore(String registeredPrefix)
   at System.Net.HttpListener.AddAllPrefixes()
   at System.Net.HttpListener.Start()

Regression?

No response

Known Workarounds

I tried running the test under WSL1, and there were no issues with ports 50000-50059.

I see that HttpListener has a separate implementation for Windows, and a managed implementation for other operating systems, so it seems the issue is only with the Windows implementation.

A workaround could be to use the managed implementation for Windows, but I don't know if that's possible without rebuilding the whole .NET runtime. https://github.com/dotnet/runtime/blob/main/src/libraries/System.Net.HttpListener/src/System.Net.HttpListener.csproj

Configuration

  • .NET 9.0.102
  • Windows 10 22H2
  • x64

Other information

No response
@dotnet-policy-service dotnet-policy-service bot added the untriaged New issue has not been triaged by the area owner label Apr 27, 2025
@dotnet-policy-service Dotnet Policy Service
Copy link
Contributor

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

@huoyaoyuan
Copy link
Member

Http listener is a simple wrapper on WinHTTP and exists solely for compatibility. There's nothing actionable at .NET side.

HttpListener is outdated today and generally not recommended. See #63941 (comment) .

@elgonzo
Copy link

elgonzo commented Apr 27, 2025 •
edited
Loading

Have you made sure that it is not the system on which you try to connect port 50000?
See for example here for similar issues on Windows machines: https://stackoverflow.com/questions/48478869/cannot-bind-to-some-ports-due-to-permission-denied or here: https://dandini.wordpress.com/2019/07/15/administered-port-exclusions-blocking-high-ports/

@chylex
Copy link
Author

chylex commented Apr 27, 2025 •
edited
Loading

Http listener is a simple wrapper on WinHTTP and exists solely for compatibility. There's nothing actionable at .NET side.

HttpListener is outdated today and generally not recommended. See #63941 (comment) .

I am currently using ASP.NET Core for a built-in HTTP server to allow communication between my application and browsers, but I've been trying to move away from ASP.NET Core, because explaining to regular users the difference between .NET Runtime and ASP.NET Core Runtime is too complicated.

The .NET download page doesn't include installers for ASP.NET Core Runtime for macOS, only binaries. When users try to run the application without ASP.NET Core Runtime installed, the error directs them to another download page, where macOS doesn't have a download for the ASP.NET Core Runtime at all.

I'm not sure how regular users are supposed to figure out how to run .NET applications that depend on ASP.NET Core.

Have you made sure that it is not the system on which you try to connect port 50000? See for example here for similar issues on Windows machines: https://stackoverflow.com/questions/48478869/cannot-bind-to-some-ports-due-to-permission-denied or here: https://dandini.wordpress.com/2019/07/15/administered-port-exclusions-blocking-high-ports/

It's possible, but from what I discovered, it's only .NET's Windows-specific implementation of HttpListener that is having this issue. The managed implementation of HttpListener and ASP.NET Core have no problem binding to these ports.

If the managed implementation of HttpListener does not have this problem, then the solution for me would be using the managed implementation even on Windows, but I'm not sure if this is currently possible?

@MihaZupan
Copy link
Member

You can use a self-contained deployment so that users of your application don't have to install the runtime separately.
HttpListener should be avoided in new development where possible, especially if you already have a working app based on ASP.NET.

@chylex
Copy link
Author

chylex commented Apr 27, 2025

I already use self-contained deployment, but not for every single combination of OS and architecture. It makes sense for me to release a version of my app that can work on any OS/arch if the user installs the runtime, but the dependency on ASP.NET is complicating that so much, that for a long time I've been looking for a solution that lets me get rid of the ASP.NET dependency.

I actually found the Sisk HTTP server library, through which I discovered HttpListener in the first place - I ran into this issue while using the library, and determined it was an issue with HttpListener rather than the library itself. The Sisk developers are working on an alternative to HttpListener, so perhaps that will be my best bet for the future.

@rzikm
Copy link
Member

rzikm commented Apr 28, 2025

#71518 (comment) may be relevant (see comment about port exclusion range)

@chylex
Copy link
Author

chylex commented Apr 28, 2025

Interesting, thanks. It's still strange to me why Kestrel can bind to these ports while HttpListener/WinHTTP cannot. I noticed that Resource Monitor shows Kestrel's sockets as owned by the application itself, while HttpListener's sockets are owned by 'System'. Maybe that's related.

I already try to avoid used ports by looping through IPGlobalProperties.GetActiveTcpListeners and GetActiveTcpConnections (accepting a small chance for race conditions between checking and binding), but these methods don't return the port exclusion ranges.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@rokonec rokonec

Labels
area-System.Net untriaged New issue has not been triaged by the area owner
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@chylex @huoyaoyuan @elgonzo @rokonec @MihaZupan @rzikm