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

Question

通常，当附加调试器时，Visual Studio 2010 会在未处理的异常处停止，即使“异常”对话框的“抛出”列中没有异常类型的标记。这里的关键字是unhandled;表示对话框只指处理过的异常。

但是，在以下最小示例中，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

由于您在异常设置中只看到一个“Thrown”复选框，我怀疑您在调试设置中启用了“.Net Framework Source Stepping”。如果启用“仅我的代码”（禁用“.Net Framework Source Stepping”），您应该在异常设置对话框中获得“用户未处理”和“抛出”复选框，并且您还将在调试器中捕获异常。

胜利的截图：

Answer 2

这是我目前发现的：

1. 如果在“调试”->“异常”对话框中没有明确检查异常，并且“选项”->“调试”->“仅启用我的代码”（EJMC）被不选中，则抛出异常在任何回调中不会与 First Chance Exception (FCE) 中断

2. 如果在 Debug->Exceptions 对话框中没有明确检查异常并且 EJMC 已检查，则在 TCPListener 的回调中抛出的异常将中断FCE，但不会在 Socket 的回调中与 FCE 中断

   一个。抛出的异常不会在 Socket 的回调中与 FCE 中断，即使调用了 TCPListener 的阻塞 AcceptSocket()（因此没有侦听器的回调）。

3. 如果System.InvalidOperationException（或System）在Debug->Exceptions中被选中，那么在任何回调中抛出的适当异常将中断使用 FCE，无论是否检查 EJMC。

4. 无论回调是指定为 lambda 还是在显式用户函数中，上述情况都是正确的

如果在 Debug->Exceptions 中没有明确检查异常，我不知道为什么 VS 不会在套接字回调中使用 FCE 中断（是什么使套接字回调与侦听器回调不同）。

Answer 3

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

我们已调查此问题并确定 CLR 中存在错误 v4.0 导致了这种情况。该过程确实会引发异常（您可以 例如，使用 catch 处理程序捕获它）但调试器没有 正确通知未处理的异常。这导致进程 似乎在调试器没有任何指示的情况下退出 发生了。我们已经调查了可能的修复，但是所有的 修复程序有破坏其他功能的中等风险。因为它 在产品周期中很晚，我们决定不解决这个问题更安全 问题和风险产生新的错误。我们将继续跟踪此问题 作为我们下一个发布周期的一部分。

问题仅限于转义托管代码的异常，其中 该线程是使用一些特定的 API 调用创建的：
新的 System.Threading.Timer()
ThreadPool.UnsafeQueueNativeOverloapped
ThreadPool.BindHandle
ThreadPool.RegisterWaitForSingleObject。

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