aspnetcore: Kestrel startup issue - address already in use

I’m experiencing this as well. Getting the following exception

System.IO.IOException: Failed to bind to address http://127.0.0.1:3278: address already in use. ---> Microsoft.AspNetCore.Server.Kestrel.Transport.Abstractions.Internal.AddressInUseException: Error -4091 EADDRINUSE address already in use ---> Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv.Internal.Networking.UvException: Error -4091 EADDRINUSE address already in use
   at Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv.Internal.Networking.LibuvFunctions.ThrowError(Int32 statusCode)
   at Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv.Internal.Networking.LibuvFunctions.tcp_getsockname(UvTcpHandle handle, SockAddr& addr, Int32& namelen)
   at Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv.Internal.Networking.UvTcpHandle.GetSockIPEndPoint()
   at Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv.Internal.Listener.ListenTcp(Boolean useFileHandle)
   at Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv.Internal.Listener.CreateListenSocket()
   at Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv.Internal.Listener.<>c.b__8_0(Listener listener)
   at Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv.Internal.LibuvThread.CallbackAdapter`1.<>c.<.cctor>b__3_1(Object callback, Object state)
   at Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv.Internal.LibuvThread.DoPostWork()

Always On is set to On and I don’t have any try-catch in Program.cs or Startup.cs.

Reloading the web app through the portal fixes the problem, but I don’t want to do this manually.

We are experiencing the same problem in our Azure hosted ASP.NET Core apps.

UseExceptionHandler applies to request processing exceptions, not startup exceptions.

@halter73 we just hit it as well. We use UseExceptionHandler to log exception and return 500 to the user - does it count as “not-crashing”? If yes, what would be the suggested change in UseExceptionHandler lambda

if (exception is System.IO.IOException) throw exception;

or

if (exception is System.IO.IOException) {await next(); return; }

?

This issue happens quite frequently. We don’t handle exceptions in the Program.cs and in the Startup.cs and there is no custom code on the stack when this happens. Please let me know if you found anything in the framework or there is something we could add to our custom code to crash the application. Maybe on the ANCM side it would be a good idea to replace the random algorithm and check the ports used by IIS. @halter73

I took a second look at the stack trace in the original report, and saw there was no Program.Main() up the stack or any indication that the binding failure crashed the process.

The ANCM IIS module which hosts ASP.NET Core apps in the Azure App Service environment will start the dotnet process telling it to listen on a randomly specified port. There is no guarantee that the port that ANCM specified isn’t already in use.

If the port is in use, ANCM expects the dotnet process to crash/exit so it can restart the dotnet process with a new random port to listen on. If the process doesn’t crash, the dotnet process won’t be restarted and the app will be unresponsive since there is no communication between ANCM and the app.

I would double check to ensure any exceptions thrown from WebHost.Run() don’t get caught but instead crash the process.