title: What causes a NullReferenceException in .NET Threading / accepting TCP connections?
body: <p>In my own webserver software, I am getting entries in the Event Viewer on the server that contain the following stack trace:</p>
  
  <pre><code>Framework Version: v4.0.30319
  Description: The process was terminated due to an unhandled exception.
  Exception Info: System.ArgumentNullException
  Stack:
     at System.Net.FixedSizeReader.ReadCallback(System.IAsyncResult)
     at System.Net.LazyAsyncResult.Complete(IntPtr)
     at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
     at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
     at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
     at System.Net.ContextAwareResult.Complete(IntPtr)
     at System.Net.Sockets.BaseOverlappedAsyncResult.CompletionPortCallback(UInt32, UInt32, System.Threading.NativeOverlapped*)
     at System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32, UInt32, System.Threading.NativeOverlapped*)
  </code></pre>
  
  <p>Needless to say, this crashes the process, which means the server goes down.</p>
  
  <p>Since none of the stacktrace mentions my own code, I am quite puzzled. Is this a bug in .NET? If so, are there any known workarounds? Or is there a known cause to this particular exception?</p>
  
  <p>The name <code>CompletionPortCallback</code> mentioned in the stacktrace leads me to believe that it occurs when the server tries to accept an incoming TCP connection, so I’m going to include the relevant code for that below. Of course I’m happy to include other code if you think the problem lies elsewhere.</p>
  
  <p>The call to <code>BeginAccept</code> looks like this:</p>
  
  <pre><code>_listeningSocket.BeginAccept(acceptSocket, null);
  </code></pre>
  
  <p>Here, <code>_listeningSocket</code> is of type <code>System.Net.Sockets.Socket</code>.</p>
  
  <p>The <code>acceptSocket</code> method is shown below. I am going to assume that the comments explain the code well enough; if not, I’m happy to clarify in a comment. Since this code runs in RELEASE mode on the live server, the <code>#if DEBUG</code> will of course be false.</p>
  
  <pre><code>private void acceptSocket(IAsyncResult result)
  {
  #if DEBUG
      // Workaround for bug in .NET 4.0 and 4.5:
      // https://connect.microsoft.com/VisualStudio/feedback/details/535917
      new Thread(() =&gt;
  #endif
      {
          // Ensure that this callback is really due to a new connection (might be due to listening socket closure)
          if (!IsListening)
              return;
  
          // Get the socket
          Socket socket = null;
          try { socket = _listeningSocket.EndAccept(result); }
          catch (SocketException) { } // can happen if the remote party has closed the socket while it was waiting for us to accept
          catch (ObjectDisposedException) { }
          catch (NullReferenceException) { if (_listeningSocket != null) throw; } // can happen if StopListening is called at precisely the "wrong" time
  
          // Schedule the next socket accept
          if (_listeningSocket != null)
              try { _listeningSocket.BeginAccept(acceptSocket, null); }
              catch (NullReferenceException) { if (_listeningSocket != null) throw; } // can happen if StopListening is called at precisely the "wrong" time
  
          // Handle this connection
          if (socket != null)
              HandleConnection(socket);
      }
  #if DEBUG
      ).Start();
  #endif
  }
  </code></pre>