ObjectDisposedExecption after closing a .NET SerialPort(关闭 .NET SerialPort 后的 ObjectDisposedExecption)
问题描述
我正在使用 .NET 4 SerialPort 对象与连接到 COM1 的设备通信.
I am using a .NET 4 SerialPort object to talk to a device attached to COM1.
设备完成后,我在 SerialPort 上调用 Close.我不叫 Dispose,但我相信 Close 和 Dispose 在这里是同义词.
When I am done with the device, I call Close on the SerialPort. I do not call Dispose, but I believe that Close and Dispose are synonymous here.
通常这很好用.
然而,有时我会在一段时间后收到以下异常(我看到的时间范围从 5 毫秒到 175 毫秒):
Sometimes, however, I get the following exception some time later (The times I've seen range from 5 ms to 175 ms):
System.ObjectDisposedException: Safe handle has been closed
at System.Runtime.InteropServices.SafeHandle.DangerousAddRef(Boolean& success)
at System.StubHelpers.StubHelpers.SafeHandleAddRef(SafeHandle pHandle, Boolean& success)
at Microsoft.Win32.UnsafeNativeMethods.GetOverlappedResult(SafeFileHandle hFile, NativeOverlapped* lpOverlapped, Int32& lpNumberOfBytesTransferred, Boolean bWait)
at System.IO.Ports.SerialStream.EventLoopRunner.WaitForCommEvent()
at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()
我的代码都不在这个堆栈上.
None of my code is on this stack.
我发现 http://blog.zachsaw.com/2010/07/serialport-ioexception-workaround-in-c.html,但那里的解决方案不起作用.进一步检查,问题是 IOException
,而不是 ObjectDisposedException
.
I found http://blog.zachsaw.com/2010/07/serialport-ioexception-workaround-in-c.html, but the solution there did not work. On further inspection, the issue there is an IOException
, not an ObjectDisposedException
.
关于当 USB 转串口设备被拔出但 COM1 是板载的,所以它不会意外消失时观察到的问题的帖子太多了.
There are a plethora of posts concerning issues observed when a USB-to-serial device is unplugged, but COM1 is onboard, so it isn't vanishing unexpectedly.
这里的问题也不是我的问题;SerialPort 在其使用期间保持活动状态,并且仅在我与设备通话完毕时才关闭.(完成后,设备处于不会传输任何进一步数据的状态.)
The problem here is also not my issue; the SerialPort is kept alive for the duration of its use, and is closed only when I am done talking to the device. (Once I am done, the device is in a state where it will not transmit any further data.)
SLaks建议在SafeHandle.Dispose
,确定我什么时候处理不应该的东西,但我敲了几十次那个断点.当我完成使用串行设备时,我对 SerialPort.Close
的一次调用会调用三次,其余大约一半在 GC 线程中.其余部分似乎与 WPF UI 元素有关.
SLaks suggests setting a breakpoint on the entrance to SafeHandle.Dispose
, to determine when I'm disposing something I shouldn't be, but I strike that breakpoint dozens of times. Three times are called by my single call to SerialPort.Close
, when I am done using the serial device, and about half the rest are in the GC thread. The remainder seem to be related to WPF UI elements.
我现在不知所措.我从这里去哪里?
I am now at a loss. Where do I go from here?
有没有办法确定哪个 SafeHandle 属于哪个对象,这样我就可以确定我不会意外处置它?
除了关闭之外,还有什么咒语需要正确关闭 SerialPort 吗?
Is there a way to determine which SafeHandle belongs to which object, so I can be certain I'm not disposing it unexpectedly?
Is there some incantation other than Close I need to properly shut down a SerialPort?
推荐答案
我也遇到过这个问题,自从我开始使用以下两个规则后就再也没有遇到过.
I've had this issue too, and since I started using the following two rules I've never seen it again.
- 始终调用 Close(),然后调用 Dispose().
- 永远不要重复使用 SerialPort 对象,当需要重新打开端口时始终创建一个新对象.
我知道,它们不是什么新闻,但它一直在为我工作.
I know, they aren't much news, but its been working for me.
这篇关于关闭 .NET SerialPort 后的 ObjectDisposedExecption的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持编程学习网!
本文标题为:关闭 .NET SerialPort 后的 ObjectDisposedExecption
基础教程推荐
- 将 Office 安装到 Windows 容器 (servercore:ltsc2019) 失败,错误代码为 17002 2022-01-01
- rabbitmq 的 REST API 2022-01-01
- 有没有办法忽略 2GB 文件上传的 maxRequestLength 限制? 2022-01-01
- 如何在 IDE 中获取 Xamarin Studio C# 输出? 2022-01-01
- MS Visual Studio .NET 的替代品 2022-01-01
- 如何激活MC67中的红灯 2022-01-01
- c# Math.Sqrt 实现 2022-01-01
- 将 XML 转换为通用列表 2022-01-01
- SSE 浮点算术是否可重现? 2022-01-01
- 为什么Flurl.Http DownloadFileAsync/Http客户端GetAsync需要 2022-09-30