程序调试时发现，使用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串口控件无此问。估计是其底层程序注意到了此问题并妥善地解决了。