我有一个小程序，它通过SerialPort发送短信。它可以连续工作7-8天，每天发送数百条消息。但有时它会在发送消息时挂起，只有硬件重置才能解决它
当调制解调器正在等待消息(显示"> "字符串)，而我发送了消息时，就会出现问题。当调制解调器接收到CTRL+Z (ASCII#26)字符时，它应该发回一个"OK"。但我从未收到过此响应，从那时起，每次写入尝试都以System.TimeoutException: The write timed out结束。例外
我可以捕捉到异常，但我无法解决问题(除了硬件重置)。从第一次超时异常开始，串行端口将无法工作，甚至超级终端也无法工作。我有机会尝试了两种不同的调制解调器，但它们都能产生相同的效果。(不同的调制解调器，但相同的电脑。)我没有办法在类似生产的环境中，在不同的机器上测试10天。
我使用了一个串行监视器软件，它还显示串行端口(或调制解调器)发回一个写入超时错误。当我初始化串行端口时，我将WriteTimeout属性设置为100(ms)。根据调制解调器制造商的说法，我必须使用硬件握手。
我只发送简单的文本消息(没有PDU，不超过160个字符)。
我已经找到了这个关于写超时和硬件握手的话题。我可以提高写入超时值，但我想知道为什么这个问题只是偶尔发生。我想知道这是否是我的问题。。。
我使用的是C#4.0，该程序运行在Windows 2008 64位服务器上。
有什么想法吗？
更新根据丹尼斯的提示，我们找到了解决方案。看门狗部分是我自己的软件，检测超时异常。当这种情况发生时，程序将向专用硬件发送命令，以切换调制解调器的电源。起初，这个专用硬件是一个中继卡，但我们发现了一个特殊的扩展线，可以通过RS-232、USB或以太网进行控制。(打开和关闭插头。)
对于经常使用GSM调制解调器的人来说，这是一个众所周知的问题。一般来说，您可以在软件级别上注意这一点，而硬件重置是唯一有效的方法。
如果你去看任何一台通过GSM newtork工作的ATM，你会发现那里有一个小型看门狗设备，它只用于一件事——进行硬件重置(它关闭电源，而不是打开电源)。