TCP Listener on Localhost causes application to crash Start() without any exception being thrown

Question

TCP Listener on Localhost causes application to crash Start() without any exception being thrown

Anuran Gupta 0

I have a use case where I am creating a TCP listener on Localhost with a specific portnumber. However , in x86 , the app crashes when I try to start the listener (i.e., listener.Start()). There is no exception being thrown and I have determined that the port is also free. There are no issues when we run the app with x64 but my specific use case requires x86. I am using .NET10 version to run the app.

As a temporary workaround, adding a slight delay before listener.Start() does work.

Can I have any specific details that might cause this and any probable solution?Code Snippet -

public static void Start(short portNumber)
{
    blnCanSendMessage = true;
    Startup.AddToLog("TCP listener starting on port: " + portNumber);

    try
    {
        listener = new TcpListener(IPAddress.Parse("127.0.0.1"), portNumber);
        listener.Start();

    }
    catch (Exception ex)
    {
        Startup.AddToLog($"TCP listener FAILED port {portNumber}.");
        Console.WriteLine($"log: ERROR - Failed to start listener on port {portNumber}.");
        Console.Out.Flush();
        return;
    }

    Console.WriteLine("log: Listening on: " + portNumber);
    Console.Out.Flush();
    Startup.AddToLog("TCP listener started on port: " + portNumber);

    _stopEvent.Reset(); // Fix #2 — allow restart after Stop()
    listener.BeginAcceptTcpClient(OnClientConnected, null);
    _stopEvent.Wait();
}

AgaveJoe 31,361 Reputation points

2026-05-15T11:04:41.72+00:00

If adding a delay prevents the crash, you likely have an asynchronous race condition where a resource is being accessed before it's fully ready. It's tough to pinpoint without seeing your source code. Could you share the snippet where your TcpListener is initialized and accepts connections?
Anuran Gupta 0 Reputation points

2026-05-15T11:46:56.6333333+00:00

I have updated the relevant code snippet.

2 answers

Your answer

AgaveJoe 31,361 Reputation points

2026-05-15T11:04:41.72+00:00

If adding a delay prevents the crash, you likely have an asynchronous race condition where a resource is being accessed before it's fully ready. It's tough to pinpoint without seeing your source code. Could you share the snippet where your TcpListener is initialized and accepts connections?
Anuran Gupta 0 Reputation points

2026-05-15T11:46:56.6333333+00:00

I have updated the relevant code snippet.

Answer 1

Thanks for sharing your code. Looking at the implementation, the issue stems from a combination of thread blocking and resource lifecycle management rather than a localhost restriction. This is why a manual delay altered the behavior—it artificially shifted the application's timing to hide a race condition.

There are two main architectural issues here:

The Single-Handoff Limitation: The legacy BeginAcceptTcpClient method only registers a listener for a single connection attempt. Once a client connects, the listener stops accepting new traffic unless you manually queue up another BeginAccept call from within your connection callback.
Thread Blocking: Relying on _stopEvent.Wait() completely halts your setup thread. If the background thread callback interacts with shared state or encounters an unhandled exception before signaling that event, it will result in a deadlocked state or a silent application crash.

Recommended Solution

The Begin/End Asynchronous Programming Model (APM) used here is legacy and highly susceptible to timing bugs. It is much safer to implement the modern Task-based Asynchronous Pattern (TAP) using async/await. This handles the state machine and exceptions inherently, allowing you to use a cancellation token loop instead of manual thread blocking primitives.

Rather than rewriting the legacy callback logic, you can review Microsoft's official production-ready guidance and complete code samples for managing asynchronous TCP listeners here:

https://learn.microsoft.com/en-us/dotnet/fundamentals/networking/sockets/tcp-classes

https://learn.microsoft.com/en-us/dotnet/api/system.net.sockets.tcplistener?view=netframework-4.8.1&viewFallbackFrom=net-10.0

Anuran Gupta 0 Reputation points

2026-05-15T13:21:26.89+00:00

Thank you. Let me look into this.

Answer 2

Varsha Dundigalla(INFOSYS LIMITED) 4,945 Microsoft External Staff

Thank you for reaching out.

The issue here is that the application is crashing when listener.Start() is called in x86, and no exception is coming, while it works fine in x64. Since adding a small delay fixes it, this usually means there could be a timing or environment-related problem.

This behavior is not expected, and to understand what is causing the crash, it could be related to how the application is starting or some environment condition. To confirm this better, could you please share if this issue happens only when the application starts, and also check if there are any errors recorded in the Windows Event Viewer at the time of the crash. Additionally, please confirm that the project is explicitly targeting x86 in the project file and try to reproduce the same issue in a simple test application.

These details will help identify whether the issue is related to startup timing, configuration, or something specific in the environment.

Anuran Gupta 0 Reputation points

2026-05-15T13:18:45.3666667+00:00

Hello Varsha , to answer your question, it is occuring at application start. There are no specifc erros recorded in event viewer at the time of crash. Also, project is explicitly targeting x86.
Varsha Dundigalla(INFOSYS LIMITED) 4,945 Reputation points Microsoft External Staff

2026-05-15T15:05:47.68+00:00

Thank you for reaching out.

Since this issue is happening exactly at application startup, no errors are captured in Event Viewer, and the project is already targeting x86, this behavior is not expected and it indicates that the crash is likely happening outside the normal managed exception flow, possibly due to a timing or initialization issue during startup. The fact that adding a small delay fixes it further supports that something may not be fully ready when listener.Start() is called.

To confirm this better, could you please try one check: create a simple standalone test application with only the TcpListener code and see if the issue reproduces there as well. This will help us understand whether the issue is coming from the application environment or from some other dependency during startup.

Share via

TCP Listener on Localhost causes application to crash Start() without any exception being thrown

2 answers

Recommended Solution

Your answer