为什么 - Visual Studio 2010中没有在Socket.BeginReceive()回调内未处理的异常停止? [英] Visual Studio 2010 doesn’t stop at an unhandled exception inside a Socket.BeginReceive() callback - why?

查看:518
本文介绍了为什么 - Visual Studio 2010中没有在Socket.BeginReceive()回调内未处理的异常停止?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

通常情况下,当附加调试器,Visual Studio 2010中停在一个未处理的异常,即使异常对话框不具备对勾标记在抛出列中的异常类型。关键字这里是未处理的;只有表示,对话是指处理的异常

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.

然而,在下面的小例子,Visual Studio 2010中不停止在异常对我来说,即使它出现在即时窗口作为一个第一次机会异常:

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:

编辑:第一个小例子,我贴在固定的我收到的第一个答案,但遗憾的是下面的例子中仍然表现出的问题:

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

如果你运行它,连接到它运行远程登录本地主机8080 键,然后输入任何字符到远程登录,希望你会看到我所看到的:节目刚中止默默地

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.

为什么Visual Studio中似乎有苦难言例外?我可以得到它在异常突破,因为它通常会呢?

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

(有趣的是,抛 BeginAcceptSocket 回调内不会被逮住一样,在一个正常的线程异常,并启动 Thread.Start 。我只能通过抛出了 BeginReceive 回调内重现该问题。)

(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.)

推荐答案

这是在CLR版本一个已知的bug 4.反馈文章<一个href="https://connect.microsoft.com/VisualStudio/feedback/details/535917/invalidoperationexception-kills-process-in-net-4-throws-in-3-5"相对=nofollow>在这里。可能的解决方法是改变框架目标3.5版。我只是引用反馈响应的相关部分:

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:

我们已经研究了这个问题,并确定没有在CLR中的错误   V4.0导致此。这个过程不会抛出异常(可以   与catch处理例如捕获它),但调试器不   适当通知的未处理的异常。这导致过程   出现退出没有任何迹象从大约调试器是什么   发生了。然而,我们已经调查潜在的修复,所有的   修复了断裂等功能的中等风险。因为它   已经很晚了,在产品周期中,我们决定这是不是安全的解决这个问题   问题和风险创造新的bug。我们将继续跟踪此问题   作为我们下一个发行周期的一部分。

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.

这个问题仅限于逃避管理code,其中的例外   该线程是使用一些特定的API调用创建:
  新   System.Threading.Timer()
  ThreadPool.UnsafeQueueNativeOverloapped
  ThreadPool.BindHandle
  ThreadPool.RegisterWaitForSingleObject。

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()在这种特定情况下。

It is RegisterWaitForSingleObject() in this specific case.

这篇关于为什么 - Visual Studio 2010中没有在Socket.BeginReceive()回调内未处理的异常停止?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆