4
有點歷史：我們有一個應用程序，最初是在多年前編寫的（1998年是PVCS中的第一個日期，但該應用程序比它早了大約5年，因爲它最初是DOS程序）。此應用程序通過串行與一個硬件進行通信。當我們到達Windows XP時，我們開始在短時間內收到關於應用程序死機的報告。看起來，串行通信只是「死亡」，應用程序仍處於卡住狀態。從這種情況中恢復的唯一方法是重新啓動應用程序。串行通信在WinXP中死亡
我可以找到關於這個問題的唯一信息顯然是Windows消息系統會錯過收到的信息，緩衝區會填滿，系統會卡住。這段信息留在舊文檔中，但沒有證據可以支持。它還提到這隻在高波特率（115200+）時才很普遍。
解決方案是爲客戶提供USB->串行轉換器以及硬件。
今天：我們正在研究一個新版本的硬件，它可以在網絡和串口上運行。所以爲了讓我能夠使用網絡代碼，減去我們使用的設備的實際硬件。它還在用戶（即：我的）機器上安裝虛擬通信端口。
現在我已經得到了與應用程序集成的網絡代碼，看起來NetCom設備表現出與物理通信一樣的行爲。這是不受歡迎的，因爲我需要該應用運行時間超過30秒。
Google變成我們體驗到的零問題。
我想知道：
- 有沒有人經歷過這個？如果是的話，你是如何解決/解決問題的？
- 對於文檔的原作者是否正確以及我能做些什麼來測試理論，有沒有人有任何建議？
不幸的是，我不能發佈代碼，因爲串行代碼與系統的其他部分緊密結合，但如果您有關於它的問題，我可以回答有關它的問題。
更新：
- 的代碼使用Win32通訊程序編寫的 - 所以我使用的CreateFile，ReadFile的。還有對GetOverlappedResult的明智調用。
- 它本身沒有掛，只是通訊停止。您可以訪問菜單，單擊按鈕，但是沒有任何東西可以與連接的硬件進行交互。使用realterm你可以看到沒有數據進出。
- 我認爲對windows消息的引用是這個問題是windows內部的。數據已經到達，但核心已經錯過了，因此沒有告訴系統的其餘部分。
- 不使用流量控制。
- 編寫'簡單'測試很困難，因爲代碼緊密耦合，底層協議相當複雜，需要大量工作。
我同意 - DOS代碼是越野車，並且win32 apis應該正常工作。 – Tim 2009-02-19 14:35:30
我已經更新了主要描述。 – 2009-02-19 14:44:58
重疊的IO確實使用事件（事實上相當多）。全部都是手動重置。我會檢查他們是否都正確重置。 不幸的是，我不能修改連接的另一端。我確實得到了ping數據包，雖然沒有增加計數器。 – 2009-02-19 15:20:33