SocketException inside .Net library crash whole application even with a try/catch

We have a .Net application running as a service listening on an UDP port for traffic using UdpClient. It can run successfully for days and thousands of connections, but at some point the service crash with this exception in the Windows event viewer:

Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.Net.Sockets.SocketException
   at System.Net.Sockets.Socket.DoBeginReceiveFrom(Byte[], Int32, Int32, System.Net.Sockets.SocketFlags, System.Net.EndPoint, System.Net.SocketAddress, System.Net.Sockets.OverlappedAsyncResult)
   at System.Net.Sockets.Socket.BeginReceiveFrom(Byte[], Int32, Int32, System.Net.Sockets.SocketFlags, System.Net.EndPoint ByRef, System.AsyncCallback, System.Object)
   at System.Net.Sockets.UdpClient.BeginReceive(System.AsyncCallback, System.Object)
   at OurNamespace.OurService.DataReceived(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.LazyAsyncResult.ProtectedInvokeCallback(System.Object, IntPtr)
   at System.Net.Sockets.BaseOverlappedAsyncResult.CompletionPortCallback(UInt32, UInt32, System.Threading.NativeOverlapped*)
   at System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32, UInt32, System.Threading.NativeOverlapped*)

Our code handling the data receive is pretty simple and standard:

private void StartListen()
{
    if (UdpServer != null)
    {
        UdpServer.Close();
        UdpServer = null;
    }

    UdpServer = new UdpClient(new IPEndPoint(IPAddress.Any, ListenPort));
    UdpServer.BeginReceive(DataReceived, UdpServer);
}

private void DataReceived(IAsyncResult ar)
{            
    var c = (UdpClient) ar.AsyncState;

    try
    {
        var receivedIpEndPoint = new IPEndPoint(IPAddress.Any, ListenPort);
        var receivedBytes = c.EndReceive(ar, ref receivedIpEndPoint);
        if (receivedBytes.Any())
            Task.Factory.StartNew(() => InternalExecute(receivedBytes, receivedIpEndPoint));

        // Restart listening
        c.BeginReceive(DataReceived, ar.AsyncState);
    }
    catch (Exception ex)
    {
        ex.Log();
        StartListen();
    }
}

I did a quick search online, and there's tons of reasons to have SocketException in socket programming, but I can't find anything related to this particular call stack and the process terminating.

Just a proof that the exception handling works, we also often have this line getting logged in our exception handler without the process terminating (the normal case of the connection getting cut, nothing to worry about):

System.Net.Sockets.SocketException (0x80004005): An existing connection was forcibly closed by the remote host
   at System.Net.Sockets.Socket.EndReceiveFrom(IAsyncResult asyncResult, EndPoint& endPoint)
   at System.Net.Sockets.UdpClient.EndReceive(IAsyncResult asyncResult, IPEndPoint& remoteEP)
   at OurNamespace.OurService.DataReceived(IAsyncResult ar)

My issue really is with the process terminating in the case of the first exception.

I have a single hypothesis of what could happens, but I have no idea how to prove it. The "IOCompletion" mentioned in the call stack reminds me that we have another completely independent process running on the same machine that use a LOT of sockets and we manually raised he maximum number of IO completion threads using ThreadPool.SetMaxThreads(). This other process never crash and works perfectly. My supposition is that Windows reach a certain maximum number of allocated resources and provoke and internal exception that we can't do nothing about, would that be possible?