串行通信在 WinXP 中消失
一点历史：我们有一个应用程序，最初是多年前编写的（1998 年是 PVCS 的第一个日期，但该应用程序比那年早大约 5 年，因为它最初是一个 DOS 程序）。 该应用程序通过串行与硬件进行通信。 当我们使用 Windows XP 时，我们开始收到应用程序在运行一小段时间后死亡的报告。 似乎串行通信刚刚“死亡”，并且应用程序处于卡住状态。 从这种情况中恢复的唯一方法是重新启动应用程序。
我能找到的关于这个问题的唯一信息显然是 Windows 消息系统会错过收到的信息，缓冲区会填满并且系统会卡住。 这段信息保留在旧的 Word 文档中，但没有证据支持这一点。 它还提到这仅在高波特率（115200+）下普遍存在。
解决方案是为客户提供 USB-> 串行转换器以及硬件。
今天：我们正在开发新版本的硬件，它将通过网络和串行端口运行。 因此，为了让我能够处理网络代码，减去我们使用的实际硬件 VSCOM NetCom113 设备。 它还在用户（即我的）计算机上安装虚拟通信端口。
现在我已经将网络代码与应用程序集成，看来 NetCom 设备表现出与物理通信相同的行为。 这是不可取的，因为我需要应用程序运行超过 30 秒。
谷歌发现我们遇到的问题为零。
我想知道：
- 以前有人经历过这种情况吗？ 如果是这样，您采取了什么措施来解决/解决该问题？
- 有人对文档的原作者是否正确以及我可以做些什么来测试该理论有任何建议吗？
不幸的是，我无法发布代码，因为串行代码与系统的其余部分紧密结合，但如果您对此有疑问，我可以回答有关它的问题。
更新：
- 代码是使用 Win32 Comm 例程编写的 - 所以我使用 CreateFile、ReadFile。 还有对 GetOverlappedResult 的明智调用。
- 它本身并不是挂起，只是通讯停止了。 您可以访问菜单，单击按钮，但无法与连接的硬件进行交互。 使用 realterm 您可以看到没有数据传入或传出。
- 我认为对Windows消息的引用是问题是Windows内部的。 数据已经到达，但内核错过了它，因此没有告诉系统的其他部分。
- 不使用流量控制。
- 编写“简单”测试很困难，因为代码紧密耦合，底层协议非常复杂，需要大量工作。
A bit of history: We have an application, which was originally written many years ago (1998 is the first date in PVCS but the app is about 5 years older than that as it originally was a DOS program). This application communicates with a piece of hardware via serial. When we got to Windows XP we started receiving reports of the app dying after a short time of running. It seems that the serial comms just 'died' and the app was left in a stuck state. The only way to recover from this situation was to restart the application.
The only information I can find regarding this problem was apparently the Windows Message system would miss that information was received, the buffer would fill and the system would get stuck. This snippet of information was left in a old word document, but there's no evidence to back this up. It also mentions that this is only prevalent at high baud rates (115200+).
The solution was to provide customers with USB->Serial converters along with the hardware.
Today: We are working on a new version of the hardware that will run across a network as well as serial ports. So to allow me to work on the network code, minus the actual hardware we are using a VSCOM NetCom113 device. It also installs a virtual comm port on the users (ie: mine) machine.
Now I have got the network code integrated with the app, it appears that the NetCom device exhibits the same behaviour as a physical commport. This is undesirable as I need the app to run longer than ~30 seconds.
Google turns up zero problems that we experience.
I was wondering:
- Has anyone experienced this before? If so what did you do to fix/workaround the problem?
- Does anyone have any suggestions as to whether the original author of the document is correct and what I can do to test the theory?
Unfortunately I can't post code as the serial code is tightly couple with the rest of the system, though if you have questions regarding it I can answer questions about it.
Updates:
- The code is written using Win32 Comm routines - so I am using CreateFile, ReadFile. There's also judicious calls to GetOverlappedResult.
- It's not hanging per se, it's just that the comms stops. You can access the menus, click the buttons, but nothing can interact with the connected hardware. Using realterm you can see that no data is coming in or going out.
- I think the reference to the windows message is that the problem is internal to windows. Data has arrived but the kernal has missed it and thus not told the rest of the system about it.
- Flow control is not used.
- Writing a 'simple' test is difficult due the the fact that the code is tightly coupled and the underlying protocol is quite complex and would require a lot of work.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您使用的是 DOS 风格的串行代码，还是 Win32 CreateFile 方法？
如果是前者，请非常怀疑：如果可能的话，我会转向后者。
如果是后者，您知道它挂在哪种系统调用上吗？ 您是否正在进行阻塞读取调用？ 或者重叠的 I/O 调用？ 或者等待一个事件？ （我不确定我是否有足够的经验来提供帮助，但这些都是我想到的问题）
您还可以检查队列大小，您可以使用 SetupComm 函数。
我不买“Windows 消息系统”的东西——这听起来很可疑； 您可以编写良好的 Win32 串行 I/O 代码，但不使用 Windows 消息。
编辑：您的重叠 I/O 是否使用事件？ 我似乎记得一些关于自动重置事件偶尔会错过触发的事情...仔细检查重叠的 I/O 调用，看看是否正确处理了可能的结果。 也许有一种方法可以通过自动取消重叠的 I/O 并重新启动另一次读取来使您的代码更加健壮。 （我假设问题出在读取部分，而不是写入部分？）
编辑2：建议：假设win32端丢失了一个字节或数据包，并且您的设备处于死锁状态，因为它们'如果双方都期望对方做出响应，您能否调整串行 I/O 的另一端以定期发送某种类型的带有递增计数器的“ping”数据包？ （并在 PC 端记录 ping 数据包；这样您就可以查看是否错过了任何数据包）
Are you using DOS-style serial code, or the Win32 CreateFile approach?
If the former, be very suspicious: if at all possible I'd convert to the latter.
If the latter, do you know on what kind of system call it's hanging? Are you in a blocking read call? or an overlapped I/O call? or waiting on an event? (I'm not sure I have enough experience to help, but those are the kinds of questions that come to mind)
You might also check into the queue size, which you can set with the SetupComm function.
I don't buy the "Windows Message system" stuff -- it sounds fishy; you can write good Win32 serial i/o code that never uses Windows messages.
edit: does your Overlapped I/O use events? I seem to remember something about auto-reset events occasionally missing their trigger... check your overlapped I/O calls very carefully to see whether you're handling the possible outcomes properly. Perhaps there's a way to make your code more robust by automatically cancelling the overlapped i/o and restarting another read. (I assume the problem is in the read half, not the write half?)
edit 2: A suggestion: assuming the win32 side has missed a byte or packet, and your devices are in deadlock because they're both expecting each other to respond to something, can you tweak the other side of the serial I/O to regularly send some type of "ping" packet with an incrementing counter? (and log the ping packets on the PC side; that way you can see whether you've missed any)
您确定流量控制设置正确吗？ DTR、RTS 等...-
Adam
Are you sure you have your flow control set up correctly? DTR, RTS, etc...
-Adam
我编写过使用 USB/蓝牙串行端口的应用程序，并且从未遇到过问题。 对于蓝牙，我在很长一段时间内看到了 800,000 bps 的比特率（持续）。 大多数人没有正确实施该端口。
我的串口
i have written apps that use usb / bluetooth serial ports and have never had an issue. with bluetooth i have seen bit rates (sustained) of 800,000 bps for long periods of time. most people don't properly implement the port.
My serial port
不确定这是否适合您，但如果您可以使用 C#.NET 重写代码，您就可以访问那里的 SerialPort 类。 它可能会解决你的问题。 我知道许多基于 Win32 API 的硬件 I/O 端口的遗留代码在 XP 中往往会由于时间原因而失败（对 MIDI 有一点经验）。
另外，我不知道您是否可以在Vista中使用Win32串行端口访问方法，因此这可能会阻止未来的MS操作系统能够使用您的代码。
Not sure if this is a possibility for you, but if you could re-write the code using C#.NET you'd have access to the SerialPort class there. It might remedy your problem. I know a lot of legacy code based around the Win32 API for hardware I/O ports tended to fail in XP due to timing (had a small bit of experience with MIDI).
In addition, I don't know if you can use the Win32 method of Serial Port access in Vista, so that might shut out future MS OSes from being able to use your code.