【问题标题】:ObjectDisposedException: Safe handle has been closedObjectDisposedException:安全句柄已关闭
【发布时间】:2014-01-09 14:41:17
【问题描述】:

所以这是一个很小的问题,但有很大的解释。正如标题所指出的,我收到一个未处理的异常,告诉我我的安全句柄已关闭。我可能需要做的是用越来越多的代码编辑这篇文章几次,以帮助我诊断问题所在。

我正在使用 POS for .NET 为我的 RFID 和 MSR 设备创建服务对象。虽然我的设备是相同的,但我有 2 个不同的虚拟 COM 端口芯片可以与这些设备通信。一个来自 Silicon labs,另一个来自 FTDI。我想使用 POS for .NET 的即插即用功能,所以我给了它我的硬件 ID。因为它是即插即用的,所以我可以使用完整的硬件路径,然后我可以使用对 PInvoke 的调用创建一个 SafeFileHandle,并使用该 SafeFileHandle 创建一个 FileStream。 FTDI 芯片不允许我像那样直接与设备对话,所以我必须获取设备的友好名称,然后使用互斥锁来拉出 COM 端口,然后创建一个 SerialPort 实例。这一步效果很好。作为仅供参考,我尝试使用两种芯片的友好名称来获取 COM 端口,而 Silicon Labs 的一个(出于某种奇怪的原因)没有使用 SetupAPI.GetDeviceDetails 使用 Ports GUID 列出。我不确定那个,因为在设备管理器中,Silicon labs Device Class Guid 是端口 GUID。

因为 SerialPort 和 FileStream 都有一个 Stream 对象,所以我决定使用它来读取和写入该端口。问题在于,如果我向 MSR 设备发送 RFID 命令,则 MSR 设备不会回复任何内容。因此,如果我使用此代码 int fromReader = ReaderStream.ReadByte(); 我的线程被阻塞。这是一个阻塞调用,至少需要 1 个字节才能继续。所以我环顾四周,似乎唯一的解决方案是使用单独的线程并设置超时。如果发生超时,则中止线程。

        Thread t = new Thread(new ThreadStart(ReadFromStream));
        t.Start();
        if (!t.Join(timeout))
        {
            t.Abort();
        }

(t.Abort 被 try/catch 包围无济于事,因为它没有解决我删除它的问题)

ReadFromStream 是 RFID 设备中的抽象方法。这是其中一种实现方式

    protected override void ReadFromStream()
    {
        var commandLength = USN3170Constants.MIN_RESPONSE_LENGTH;
        var response = new System.Collections.Generic.List<byte>(USN3170Constants.MIN_RESPONSE_LENGTH);
        for (int i = 0; i <= commandLength; i++)
        {
            int fromReader = ReaderStream.ReadByte();
            if (fromReader == -1) break; //at end of stream
            response.Add((byte)fromReader);

            if (response.Count > USN3170Constants.DATA_LENGTH_INDEX && response[USN3170Constants.DATA_LENGTH_INDEX] > 0)
            {
                commandLength = response[USN3170Constants.DATA_LENGTH_INDEX] + 3;
            }
        }

        streamBuffer = response.ToArray();
    }

int fromReader = ReaderStream.ReadByte(); 被 try/catch 包围。它唯一捕获的就是 aborted 线程异常,所以我把它拿出来了)

上面的代码是我怀疑问题所在。不过,奇怪的是,我有一个单元测试,我觉得它很好地模仿了 Microsoft 测试应用程序。

(仅供参考 QUADPORT 是 FTDI 芯片组)

    PosExplorer posExplorer;
    DeviceCollection smartCardRWs;
    [Test]
    public void TestQuadPortOpen()
    {
        posExplorer = new PosExplorer();
        smartCardRWs = posExplorer.GetDevices(DeviceType.SmartCardRW, DeviceCompatibilities.CompatibilityLevel1);
        //if using quadport one item is the MSR and the other is the RFID
        //because of that one of them will fail. Currently the first Device in the collection is the the RFID, and the second is MSR
        Assert.GreaterOrEqual(smartCardRWs.Count, 2);
        //Hardware Id: QUADPORT\QUAD_SERIAL_INTERFACE
        foreach(DeviceInfo item in smartCardRWs)
        {
            Assert.AreEqual("QUADPORT\\QUAD_SERIAL_INTERFACE", item.HardwareId);
        }

        SmartCardRW rfidDevice = (SmartCardRW)posExplorer.CreateInstance(smartCardRWs[0]);
        SmartCardRW msrDevice = (SmartCardRW)posExplorer.CreateInstance(smartCardRWs[1]);

        rfidDevice.Open();
        Assert.AreNotEqual(ControlState.Closed, rfidDevice.State);
        rfidDevice.Close();

        try
        {
            msrDevice.Open();
            Assert.Fail("MSR Device is not a RFID Device");
        }
        catch
        {
            Assert.AreEqual(ControlState.Closed, msrDevice.State);
        }

        rfidDevice = null;
        msrDevice = null;
    }

当我运行该测试时,我没有收到 SafeFileHandle 异常。事实上测试通过了。

所以我不知道如何追踪这个错误。由于我将在我也在创建的另一个程序中使用此服务对象,因此我可能最终会在该程序中使用此测试中的此代码。但是我觉得微软测试应用程序或多或少是“黄金标准”。真的吗……应该不会吧。但它确实对我的目的有用,所以我觉得这是我的代码问题,而不是他们的问题。

关于如何缩小范围的任何技巧?仅供参考,我尝试使用调试器,但在打开代码中不会发生错误。我还走过了更新状态计时器,它也没有抛出错误。一旦我点击继续,我就会得到异常。我打开了 Just My Code and Loaded Symbols,它告诉我“此模块的调试信息中缺少源信息”

【问题讨论】:

  • 我不清楚这个问题(我读了整件事)。您在哪一行得到主题中描述的错误?什么是阅读器流?我在处理 PInvoke 和线程方面有相当多的经验(以及令人头疼的问题),所以我很乐意提供帮助,但我需要澄清一下。此外,我多次被告知(当我问类似问题时)Thread.Abort() 是个坏主意。您可能会不惜一切代价尝试避免这种情况。
  • @Brandon ReaderStream 是一个流。在这种情况下,它是来自 SerialPort 的 SerialStream。如果可能的话,我很乐意在聊天中与您讨论这个问题
  • 我愿意,而且我认为 SO 有聊天功能,但我从未使用过。给我一个链接或邀请,我会尽我所能提供帮助
  • @Brandon 不确定这是否是正确的做法,但这里是房间 chat.stackoverflow.com/rooms/43614/safefilehandle-troubles

标签: c# multithreading pos-for-.net safehandle


【解决方案1】:

这个问题(尤其是对 SerialPort 实例的引用)听起来很像 http://connect.microsoft.com/VisualStudio/feedback/details/140018/serialport-crashes-after-disconnect-of-usb-com-port 中记录的问题。

据我了解,在非永久性 SerialPort(例如与 USB 设备关联的端口)的情况下,当端口意外“消失”时,与其关联的底层 Stream 将被处置。如果在随后调用 SerialPort.Close 时端口上有活动的读取或写入操作可能会导致您提到的异常,但是该异常发生在 Microsoft 的代码中运行在不同的线程上,并且无法从您的内部捕获代码。 (您绑定到 AppDomain 上的 UnhandledException 事件的任何“最后机会”异常处理程序仍会看到它。)

链接文档中似乎有两种基本的解决方法。在这两种情况下,打开端口后,您都会为打开的端口存储对 BaseStream 实例的引用。然后一种解决方法会禁止对该基本流进行垃圾收集。另一个在基本流上显式调用 Close,捕获在该操作期间引发的任何异常,然后在 SerialPort 上调用 Close。

编辑: 对于它的价值,在 .NET 框架 V4.5 下,似乎 Microsoft Connect 站点上记录的解决方法都没有完全解决问题,尽管它们可能会降低频率它与它一起发生。 :-(

【讨论】:

  • 我现在在 .NET 4.5 上遇到了这个问题,我在 SO 上找到的解决方法没有改变行为。如果我在连接和交换数据后立即移除 USB 设备,它总是会因 SafeHandle 异常而崩溃。不幸的是,热插拔应该是这个设备的一个功能......
【解决方案2】:

当我使用线程从 SerialPort 读取时,我遇到了同样的错误。在线程上调用中断偶尔会导致无法捕获的 ObjectDisposedException。经过数小时的调试和仔细阅读:

https://blogs.msdn.microsoft.com/bclteam/2006/10/10/top-5-serialport-tips-kim-hamilton/

我意识到问题是这样的: NET 2.0(及更高版本)不会让您摆脱某些事情,例如尝试通过中断访问 SerialPort 的线程来取消 SerialPort 读取。

因此,在调用 Thread.Interrupt() 之前,您必须关闭 COM...这将导致 ReadByte 操作出现可捕获的异常。

或者您可以使用 SerialPort 上的 ReadTimeout 属性来避免使用线程来设置超时。

【讨论】:

    【解决方案3】:

    我想发布我在尝试从串行端口(由 Moxa RS232 驱动的虚拟 com 到以太网)读取时遇到类似问题的案例。 由于我没有机会捕捉到 ObjectDisposedException,唯一的解决方案是增加最初设置为 -1 的 ReadTimeout 属性(连续读取)。 在我的情况下,将 ReadTimeout 设置为 100 毫秒 解决了这个问题。

    编辑
    这不是最终的解决方案:如果您在读取尝试期间关闭应用程序,您可能会得到相同的无法捕获的异常。 我最终的解决方案是直接在FormClosing事件中杀死应用程序的进程:

    private void MyForm_FormClosing(object sender, FormClosingEventArgs e)
        {
            Process p = Process.GetCurrentProcess();
            p.Kill();
        }
    

    【讨论】:

      【解决方案4】:

      请看这个:

      https://github.com/jcurl/SerialPortStream

      我用 RJPC.IO.Ports 替换了 System.IO.Ports,修复了初始化中的几个参数差异,所有问题都因这个问题而消失了。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2014-12-15
        • 2021-11-02
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多