c# - Visual Studio 2010 不会在 Socket.BeginReceive() 回调中出现未处理的异常时停止 - 为什么？

Question

通常，当附加调试器时，Visual Studio 2010 会在未处理的异常处停止，即使“异常”对话框的“抛出”列中没有异常类型的勾号也是如此。这里的关键词是unhandled;表示dialog仅指已处理的异常。

但是，在下面的最小示例中，Visual Studio 2010 并没有在我的异常处停止，即使它作为第一次机会异常出现在立即窗口中也是如此:

编辑: 我发布的第一个最小示例由我收到的第一个答案修复，但不幸的是，以下示例仍然存在问题:

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();
        }
    }
}

如果你运行它，通过运行 telnet localhost 8080 连接到它，然后在 telnet 中输入任何字符，希望你会看到我所看到的:程序只是默默地中止。

为什么 Visual Studio 显然吞下了这个异常？我可以让它像往常一样在出现异常时中断吗？

(有趣的是，在 BeginAcceptSocket 回调中抛出确实会被捕获，以 Thread.Start 启动的普通线程中的异常也是如此。我只能重现该问题扔进 BeginReceive 回调。)

Answer 1

这是 CLR 版本 4 中的一个已知错误。反馈文章 is here .一种可能的解决方法是将框架目标更改为版本 3.5。我只是引用反馈响应的相关部分:

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.

在这种特定情况下是 RegisterWaitForSingleObject()。