Question

Normally, when the debugger is attached, Visual Studio 2010 stops at an unhandled exception even if the Exceptions dialog doesn’t have the tickmark for the exception type in the “Thrown” column. The keyword here is unhandled; said dialog refers only to handled exceptions.

However, in the following minimal example, Visual Studio 2010 does not stop at the exception for me, even though it appears in the Immediate Window as a first-chance exception:

EDIT: The first minimal example I posted was fixed by the first answer I received, but unfortunately the following example still exhibits the problem:

using System;
using System.Net.Sockets;

namespace SocketTest
{
    class Program
    {
        static void Main(string[] args)
        {
            var listener = new TcpListener(8080);
            listener.Start();
            AsyncCallback accepter = null;
            accepter = ar =>
            {
                var socket = listener.EndAcceptSocket(ar);
                var buffer = new byte[65536];
                AsyncCallback receiver = null;
                receiver = ar2 =>
                {
                    var bytesRead = socket.EndReceive(ar2);
                    throw new InvalidOperationException();
                    socket.BeginReceive(buffer, 0, buffer.Length, SocketFlags.None, receiver, null);
                };
                socket.BeginReceive(buffer, 0, buffer.Length, SocketFlags.None, receiver, null);
                listener.BeginAcceptSocket(accepter, null);
            };
            listener.BeginAcceptSocket(accepter, null);

            Console.WriteLine("Feel free to connect to port 8080 now.");
            Console.ReadLine();
        }
    }
}

If you run this, connect to it by running telnet localhost 8080 and then type any character into telnet, hopefully you will see what I see: the program just aborts silently.

Why does Visual Studio apparently swallow this exception? Can I get it to break at the exception as it usually does?

(Interestingly, throwing inside the BeginAcceptSocket callback does get caught, as does an exception in a normal thread started with Thread.Start. I can only reproduce the issue by throwing inside the BeginReceive callback.)

Answer 1

This is a known bug in CLR version 4. The feedback article is here. A possible workaround is to change the framework target to version 3.5. I’ll just quote the relevant portion of the feedback response:

We have investigated the issue and determined there is a bug in CLR
v4.0 which causes this. The process does throw the exception (you can
catch it with a catch handler for example) but the debugger was not
properly notified of the unhandled exception. This causes the process
to appear to exit without any indication from the debugger about what
happened. We have investigated potential fixes, however all of the
fixes had moderate risk of breaking other functionality. Because it
was very late in product cycle we decided it was safer not to fix this
issue and risk creating new bugs. We will continue to track this issue
as part of our next release cycle.

The issue is restricted to exceptions that escape managed code where
the thread was created using a few specific API calls:
new
System.Threading.Timer()
ThreadPool.UnsafeQueueNativeOverloapped
ThreadPool.BindHandle
ThreadPool.RegisterWaitForSingleObject.

It is RegisterWaitForSingleObject() in this specific case.