Исключения SEH всегда доставлялись средой CLR управляемому коду, используя ту же механику, что и для исключений, возникающих в самой программе.

В версии 4 среды CLR группа разработчиков продукта делает исключения, указывающие на повреждение состояния процесса, отличными от всех прочих исключений. Мы выделили около десяти исключений SEH, которые будут указывать на повреждение состояния процесса. Их обозначения относятся к контексту, в котором создается исключение, а не к самому типу исключения. Это значит, что нарушения прав доступа, полученные от Windows, будут помечены как исключения CSE (исключения поврежденного состояния), а исключения, возникающие в коде пользователя в результате порождения нового System.AccessViolationException, не будут помечены как CSE
...
Начиная с версии 4 система исключений среды CLR не будет доставлять исключения CSE управляемому коду, если код не укажет явно, что он может обрабатывать исключения поврежденного состояния процесса. Это означает, что оператору catch (Exception e) в управляемом коде CSE передаваться не будут.

namespace ConsoleApplication1
{
    using System;
    using System.Collections.Generic;

    class Program
    {
        static void Main(string[] args)
        {
            for (; ; )
            {
                try
                {
                    var list = new List<byte[]>();

                    for (; ; )
                        list.Add(new byte[1024 * 1024]);
                }
                catch (OutOfMemoryException)
                {
                    Console.WriteLine("OutOfMemoryException caught");
                }
            }
        }
    }
}

J>    private void OnAccept(IAsyncResult ar)
J>    {
J>        using (socket = _listener.EndAccept(ar))
J>        {
J>            using(var c1 = new Connection(socket)) {
                          //…
                        }//using
                        // …
                        using(var c2 =  new Connection(socket)) {
                          // Использование c2, а сокет уже тю-тю
                        }//using
J>        }
J>    }

J>socket = null;

1. в Connection::Dispose() не закрывать сокет, отдавая эту прерогативу тому, что создал объект
   
2. Создавать сокет в конструкторе Connection и гарантированно закрывать в Connection::Dispose(), обрабатывая возможные исключения
   
3. Передавать в Connection дополнительный параметр, который скажет, нужно ли закрывать сокет в Connection::Dispose().

A set of exceptions indicate your process state is corrupted
а. Access Violations are the most common
b. Does not include Out of Memory, Division by Zero, Stack Overflow, Null Reference

J>>Я обеими руками за. Только вот не вижу как это применить в данной ситуации

    private void OnAccept(IAsyncResult ar)
    {
        socket = _listener.EndAccept(ar);
        new Connection(socket);
    }

J>namespace ConsoleApplication1
J>{
J>    using System;
J>    using System.Collections.Generic;

J>    class Program
J>    {
J>        static void Main(string[] args)
J>        {
J>            for (; ; )
J>            {
J>                try
J>                {
J>                    var list = new List<byte[]>();

J>                    for (; ; )
J>                        list.Add(new byte[1024 * 1024]);
J>                }
J>                catch (OutOfMemoryException)
J>                {
J>                    Console.WriteLine("OutOfMemoryException caught");
J>                }
J>            }
J>        }
J>    }
J>}
J>

J>Прекрасно работает. Кому верить?

using System;
using System.Runtime;
public static class Program {
  public static void Main() {
    try {
      // Logically reserve 1.5 GB of memory
      using (MemoryFailPoint mfp = new MemoryFailPoint(1500)) {
      // Perform memory-hungry algorithm in here
      } // Dispose will logically free the 1.5 GB of memory
    }
    catch (InsufficientMemoryException e) {
    // The memory could not be reserved
    Console.WriteLine(e);
    }
   }
}

class Connection
{
    private Connection(Socket socket)
    {
        // Perform initialization
    }
    
    static public Create(Socket socket)
    {
        try
        {
            return new Connection(socket);            
        }
        catch
        {
            socket.Close();
            throw;
        }    
    }
}

class Connection : IDisposable
{
    private Socket _socket;
    
    public Connection(Socket socket)
    {
        // 1
        _socket = socket;
        // 2
    }
    
    public void Dispose()
    {
        // dispose stage 1
        _socket.Close();
        // dispose stage 2
    }
}

class Foo
{
    private void OnAccept(IAsyncResult ar)
    {
        socket = _listener.EndAccept(ar);
        new Connection(socket);
    }
}

    private void OnAccept(IAsyncResult ar)
    {
        using (socket = _listener.EndAccept(ar))
        {
            new Connection(socket);
            socket = null;
        }
    }

Socket socket = null;

try
{
    socket = _listener.EndAccept(ar);
    new Connection(socket);
}
finally
{
    if (socket != null)
        socket.Close();
}

class Connection : IDisposable
{
    private Socket _socket;
    
    public Connection(Socket socket)
    {
        try
        {
          // 1
          _socket = socket;
          // 2
        }
        catch
        {
          socket.Close();
          throw;
        }
    }
    
    public void Dispose()
    {
        // dispose stage 1
        if(_socket != null)
          _socket.Close();
        // dispose stage 2
    }
}

new Connection(socket);

J>>>    private void OnAccept(IAsyncResult ar)
J>>>    {
J>>>        socket = _listener.EndAccept(ar);
J>>>        new Connection(socket);
J>>>    }
J>>>

Где Вы здесь увидели номер порта?

public StreamWriter(Stream stream)

public override void Close()

public TcpClient EndAcceptTcpClient(IAsyncResult asyncResult)
{
        // Details skipped.
    Socket socket2 = socket.EndAccept(asyncResult);   
    return new TcpClient(socket2);
}

public TcpClient EndAcceptTcpClient(IAsyncResult asyncResult)
{
        // Details skipped.
    Socket socket2 = socket.EndAccept(asyncResult);   
    return new TcpClient(socket2);
}

1. Приложение завершится, при этом ось закроет сокет
   
2. Приложение не завершится, где-то выше по стеку исключение будет поймано и как-то обработано. Тогда при следующей же сборке мусора будет найден объект типа Socket, на который нет ни одной ссылки из корней. Этот объект будет собран GC, у объекта будет вызван файнализатор. У поля объекта m_Handle так же будет вызван завершитель. Никакие ресурсы никуда не утекут.

J>Кто ж спорит, но иногда-все таки это нужно — если приложение асинхронное. Мы все-таки в реальном мире живем, и следовать умным правилам не всегда получается

Внимание! Если конструктор MemoryFailPoint не генерирует исключе-
ние, запрошенная память была логически зарезервирована и можно
выполнять алгоритм, требующий много памяти. Однако учтите, что
физически память не была выделена. Это значит, что лишь немного
повысилась вероятность успешного выполнения алгоритма и получения
необходимой памяти. Класс MemoryFailPoint не может гарантировать, что
алгоритм получит необходимую память, даже если конструктор не
сгенерировал исключение. Этот класс призван лишь помочь разработчику
сделать приложение более надежным.

J>>>Но даже если это произошло мы не должны бросать открытый файл открытым. Вот собственно весь пойнт моих рассуждений в этой ветке

using(var file = OpenLargeFile()) {
  // …
}//using

new TcpClient(socket2);

Starting with the .NET Framework version 2.0, a StackOverflowException object cannot be caught by a try-catch block and the corresponding process is terminated by default.