Failed to bind to address http://127.0.0.1:5000: address already in use.

This likely happens because another process is already using that port. By default, many .NET Core and .NET 5+ applications attempt to listen on port 5000 for HTTP.

To fix "Access Denied" for netstat, run the command with administrative privileges.

• Press the Windows Key, type cmd, right-click on Command Prompt, and select Run as administrator.
• Run netstat -ano | findstr :5000.
• The last column in the output is the PID (Process ID) of the application using the port.

Once you have the PID from the step above:

1. Open Task Manager (Ctrl+Shift+Esc).
2. Go to the Details tab.
3. Find the PID you noted earlier to see which application is responsible.
4. Right-click the process and select End Task.

Instead of stopping other services, you can change the port your .NET app uses to avoid conflicts.

• Via launchSettings.json: Open Properties/launchSettings.json and update the applicationUrl to a different port (e.g., http://localhost:5050).
• Via Environment Variable: Set the environment variable ASPNETCORE_URLS to http://localhost:5050 before starting your app.
• Via Command Line: When running the exe, use the --urls flag: cmd

    yourapp.exe --urls "http://localhost:5050"
  

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin

Hi @Tom Haepers ,

Thanks for sharing the update, and glad you were able to track down the actual cause.

In Azure App Service, the public endpoint is not usually the same thing your ASP.NET Core process binds to directly. The platform/IIS layer sits in front of the app and forwards traffic to the internal process. So seeing localhost:5000 in this case does not necessarily mean a random external process was taking the port; it can be part of how the hosted app process is being wired up internally.

The important part is that the previous app process had not fully cleared from that internal binding yet. So when you started the .exe manually from the console, it was a useful confirmation that the app could launch, but it failed once Kestrel tried to bind to the same internal port that was still associated with the App Service-hosted process.

The real root cause being the startup timeout also fits well. By default, the ASP.NET Core Module waits only a limited amount of time for the application to start. If the initial startup work takes longer than that, the hosting layer can treat the app as failed even though the application may still be in the middle of initializing. That can leave the situation looking like a port conflict, when the underlying issue is actually that startup did not complete within the configured timeout.

Increasing the startupTimeLimit in web.config is the right fix if the application genuinely needs more time during startup, for example:

<aspNetCore processPath=".\MyApp.exe"
            arguments=""
            stdoutLogEnabled="false"
            stdoutLogFile=".\logs\stdout"
            hostingModel="outofprocess"
            startupTimeLimit="300" />

The exact processPath, arguments, and hostingModel should match the published app, but the key setting here is startupTimeLimit. Setting it to a higher value gives the app more time to finish its initial startup before the hosting layer decides it failed.

Longer term, it may still be worth reviewing what happens during startup and moving any heavy initialization work to a background process where possible. But for this case, extending the startup timeout explains why the deployment started working without needing to change the port.

If my explanation to your solution was truly helpful to you, I would greatly appreciate it if you could follow the instructions here so others with the same problem can benefit as well and understand your solution deeply. Thank you!

Hi @Tom Haepers ,

Thanks for reaching out.

This can happen when Kestrel tries to start on the default ASP.NET Core HTTP port, 5000, but another process is already using it. In a published app, that port may be coming from the ASP.NET Core defaults, ASPNETCORE_URLS, DOTNET_URLS, appsettings.json, or code in Program.cs such as UseUrls() or ListenLocalhost(). launchSettings.json is mainly used by Visual Studio or dotnet run, so it usually does not affect a published .exe directly.

Open Command Prompt or PowerShell as Administrator and check what is using the port:

netstat -ano | findstr :5000

The last column is the PID. You can look it up with:

tasklist /FI "PID eq <PID>"

or check the Details tab in Task Manager. If netstat shows “Access is denied”, the terminal likely was not opened with administrator rights.

If the process using port 5000 is not needed, stop it. Otherwise, run your app on another port:

YourApp.exe --urls "http://127.0.0.1:5050"

or set it with an environment variable. In Command Prompt:

set ASPNETCORE_URLS=http://127.0.0.1:5050
YourApp.exe

In PowerShell, use:

$env:ASPNETCORE_URLS="http://127.0.0.1:5050"
.\YourApp.exe

If this is hosted in IIS, also make sure the deployed app is not carrying over a hardcoded development URL. Check Program.cs, appsettings*.json, web.config, and server-level environment variables for anything pointing to 127.0.0.1:5000.

With IIS, the app should normally be started through the ASP.NET Core Module. Manually launching the executable is useful for troubleshooting, but if IIS is already starting the app, running it again can create another instance and cause the same conflict.

Hope this helps! If my answer was helpful, I would greatly appreciate it if you could follow the instructions here so others with the same problem can benefit as well.

If you want to deploy your ASP.NET Core app to IIS, please try publishing according to Microsoft document Publish an ASP.NET Core app to IIS.