程序調試時發現，使用CreateFile()打開COM4時正常，打開COM10時卻總是失敗。這兩個端口均爲虛擬COM口，通過藍牙仿真串口完成數據收發，除了命名不同外，本質上並無任何不同。
而MSDN上對使用CreateFile()打開設備函數卻失敗返回並無詳細解釋，百思不得其解。上網百度一下找到了相關資料，原來是：
Win32 API函數CreateFile()除了可打開普通文件外，還可以打開設備，比如可用於打開串口，獲得串口句柄。
使用CreateFile()函數打開串口時文件共享模式應設置爲0（表示獨佔），創建參數設置爲OPEN_EXISTING，模板必須設置爲NULL。
如果爲COM1至COM9，可使用“COM1”-“COM9”作爲文件名傳遞給CreateFile()函數，函數可成功返回。但是，如果操作對象爲COM10及以上的端口，以此方式命名文件名調用CreateFile()函數會返回INVALID_HANDLE_VALUE，表示端口無法打開。
產生這種奇怪現象的原因是：微軟預定義的標準設備中含有“COM1”-“COM9”。所以，“COM1”-“COM9”作爲文件名傳遞給函數時操作系統會自動地將之解析爲相應的設備。但對於COM10及以上的串口，“COM10”之類的文件名系統只視之爲一般意義上的文件，而非串行設備。
爲了增加對COM10及以上串行端口的支持，微軟規定，如果要訪問這樣的設備，應使用這樣的文件名（以COM10爲例）：\\.COM10
所以，對於COM10及以上的串口，CreateFile()的調用樣式應調整如下：
CreateFile(
"\\\\.\\COM10", // 定義串口名
fdwAccess, // 存取模式（讀寫）
0, // 共享模式：必須設置爲0，表示設備獨佔使用
NULL, // 保密性
OPEN_EXISTING, // 必須設置爲OPEN_EXISTING
0, // 文件屬性，如果是異步模式，可設置爲
NULL // 模版，串口設備必須設置爲NULL
);
需要注意的是：這套命名規範同樣適用於COM1-COM9。
參考處：http://support.microsoft.com/?id=115831
另，MSCOMM串口控件無此問。估計是其底層程序注意到了此問題並妥善地解決了。