1. 为什么一个虚拟串口工具值得单独写一篇安装实录
搞嵌入式开发、工控调试或者串口通信测试的人,对 com0com 这个名字应该不陌生。它做的事情说起来很简单:在 Windows 系统里创建一对(或多对)虚拟串口,让两个本来需要物理串口线连接的软件,通过这对虚拟端口直接对话。比如你手头没有硬件,但需要调试上位机软件和串口设备之间的通信协议,com0com 就能凭空给你造出一对 COM 口,一个负责发,一个负责收,数据在系统内部直接流转,省去了插线、接线、找驱动这一堆麻烦事。
但 com0com 在 Windows 10 和 Windows 11 上的安装,远没有它的功能听起来那么轻巧。尤其是 3.0.0.0 这个版本,很多人在设备管理器里看到那个黄色的感叹号,点开属性一看——“该设备的驱动程序未被安装(代码 28)”或者“该设备无法启动(代码 10)”,然后就卡住了。这不是你操作有问题,而是 Windows 从 Win10 开始对驱动签名强制校验,而 com0com 3.0.0.0 的驱动签名证书在较新的系统上会被判定为不受信任。再加上 64 位系统对内核驱动的签名要求更严格,32 位时代的老办法直接失效。
这篇文章就是围绕这个核心痛点展开的。我会把 com0com 3.0.0.0 在 Windows 10/11 上的完整安装流程拆成三个关键步骤,重点解决设备感叹号和驱动签名冲突这两个拦路虎。同时也会补充一些实际调试中遇到的坑,比如端口号冲突、setupc 命令行工具的使用、以及安装后如何验证虚拟串口对是否真正工作。适合所有需要在 Windows 环境下做串口通信开发、测试、调试的工程师和技术爱好者阅读,不管你是第一次接触虚拟串口,还是之前装过但被签名问题劝退,这篇内容都能给你一套可复现的方案。
2. com0com 的核心机制与版本选型分析
2.1 虚拟串口对的工作原理
com0com 的核心是一个内核态驱动加上一个用户态配置工具。内核驱动负责创建虚拟的串口设备对象,用户态工具(setupc.exe 或者图形界面的 setupg.exe)负责管理这些端口的配对关系。当你创建一对端口比如 COM10 和 COM11 时,驱动会在系统里注册两个虚拟串口设备,然后在这两个设备之间建立一条内部的数据通道。任何往 COM10 写入的数据,会立刻从 COM11 读出来,反过来也一样。
这个机制的关键在于,它模拟的是标准的 16550 UART 串口行为,包括波特率、数据位、停止位、校验位这些参数。但因为是虚拟的,实际通信速率不受物理限制,波特率设置只影响软件层面的时序模拟,不影响实际吞吐。这一点在调试时很重要:你设 9600 和设 115200,数据传得一样快,但某些对时序敏感的上位机软件可能会因为波特率设置不同而表现出不同的超时行为。
2.2 为什么选 3.0.0.0 这个版本
com0com 的版本迭代不算快,3.0.0.0 是一个比较成熟的稳定版,支持 64 位 Windows,也提供了签名驱动。但问题在于,这个版本的驱动签名证书在 Windows 10 的某些更新之后被列入了不信任列表,导致安装时系统直接拒绝加载驱动。这不是 com0com 独有的问题,很多老牌开源驱动的签名证书都遇到过类似情况。
那为什么不用更新的版本?实际上 com0com 的后续版本在功能上没有太大变化,主要是签名和兼容性维护。但很多教程和项目文档都是基于 3.0.0.0 写的,而且这个版本的 setupc 命令行工具功能完整,脚本化配置很方便。所以掌握 3.0.0.0 的安装方法,基本上就覆盖了绝大多数使用场景。
2.3 32 位与 64 位的选择陷阱
这里有一个很容易踩的坑:com0com 的安装包分 32 位和 64 位,但并不是说你的系统是 64 位就一定要装 64 位版本。关键在于你的目标应用程序是 32 位还是 64 位。虚拟串口驱动本身是内核态的,必须和系统架构匹配,所以 64 位系统必须装 64 位驱动。但 setupc 这个配置工具,如果你要用它来给 32 位应用配置端口,可能需要用 32 位的 setupc。
实际经验是:64 位 Windows 10/11 上,直接装 64 位版本的 com0com,然后用它自带的 64 位 setupc 配置端口,绝大多数情况都能正常工作。只有当你遇到某些老旧的 32 位串口调试软件无法识别虚拟端口时,才需要考虑是不是架构匹配问题。
3. 三步解决安装与签名冲突的完整实操
3.1 第一步:获取正确的安装包并预处理
首先你得拿到 com0com 3.0.0.0 的安装包。官方发布在 SourceForge 上,文件名通常是com0com-3.0.0.0-x64-fre-signed.zip或者类似的名字。注意看文件名里的signed字样,这是带签名的版本。还有一个unsigned版本,那个是给测试签名模式用的,普通安装不要用。
下载下来之后,不要急着双击安装。先做一件事:把安装包解压到一个没有中文路径、没有空格的目录下,比如C:\com0com\。为什么?因为 com0com 的安装程序在注册驱动时会调用系统命令,如果路径里有中文或空格,某些情况下会导致驱动注册失败,设备管理器里就会出现那个经典的感叹号。
解压后你会看到几个关键文件:
setup.exe:图形化安装程序setupc.exe:命令行配置工具com0com.sys:内核驱动文件com0com.cat:驱动签名目录文件setupg.exe:图形化端口配置工具
注意:如果你之前装过其他版本的 com0com,务必先在设备管理器里卸载干净,并删除
C:\Windows\System32\drivers\com0com.sys文件,否则新旧驱动混在一起,问题会更难排查。
3.2 第二步:处理驱动签名冲突的三种方案
这是整个安装过程中最关键的一步。Windows 10/11 默认要求所有内核驱动必须有受信任的签名,而 com0com 3.0.0.0 的签名证书可能不在系统的信任列表里。你有三个选择:
方案一:临时禁用驱动签名强制(推荐用于测试环境)
在 Windows 设置里找到“恢复”->“高级启动”->“立即重新启动”,重启后进入“疑难解答”->“高级选项”->“启动设置”->“重启”,然后按数字键 7 选择“禁用驱动程序强制签名”。系统重启后,驱动签名校验会暂时关闭,这时候再安装 com0com,驱动就能正常加载。
这个方案的缺点是每次重启后签名强制会恢复,如果你重启电脑,虚拟串口可能又会出现感叹号。所以适合临时调试,不适合长期使用。
方案二:导入证书到受信任的根证书颁发机构
打开 com0com 安装目录,找到com0com.cat文件,右键选择“安装证书”,然后选择“将所有的证书都放入下列存储”->“受信任的根证书颁发机构”。导入完成后,再安装驱动,系统就会认为这个签名是可信的。
这个方案的好处是一劳永逸,重启后依然有效。但需要注意,导入根证书是一个敏感操作,只在你完全信任 com0com 这个开源项目的前提下才这么做。导入之后可以在证书管理器里随时删除。
方案三:使用测试签名模式(不推荐)
在管理员命令提示符下运行bcdedit /set testsigning on,然后重启。系统会进入测试签名模式,桌面右下角会显示水印。这个模式下所有签名校验都放宽,但安全性降低,而且水印会影响日常使用。除非你有特殊需求,否则不建议用这个方案。
实际操作中,我一般先用方案一快速验证功能,确认没问题后再用方案二做持久化。这样既安全又省事。
3.3 第三步:安装驱动并验证端口对
签名问题解决后,安装就简单了。以管理员身份运行setup.exe,一路下一步。安装程序会自动注册驱动并创建默认的端口对(通常是 COM10 和 COM11,如果被占用会自动往后顺延)。
安装完成后,打开设备管理器,展开“端口(COM 和 LPT)”分类,你应该能看到类似“com0com - serial port emulator (COM10)”和“com0com - serial port emulator (COM11)”两个设备,而且没有黄色感叹号。
如果还是有感叹号,右键点击设备,选择“属性”,查看“设备状态”里的错误代码。如果是代码 10,说明驱动加载失败,大概率是签名问题没解决干净;如果是代码 28,说明驱动文件没找到,检查C:\Windows\System32\drivers\com0com.sys是否存在。
验证端口对是否真正工作的最简单方法:打开两个串口调试助手(比如 PuTTY 或者 SSCOM),一个打开 COM10,一个打开 COM11,波特率都设成 9600。在 COM10 的窗口里输入字符,COM11 的窗口应该立刻显示出来。反过来也一样。如果数据能双向流通,说明虚拟串口对已经正常工作了。
4. 常见问题排查与独家避坑经验
4.1 设备感叹号问题速查表
| 错误代码 | 含义 | 可能原因 | 解决方法 |
|---|---|---|---|
| 代码 10 | 设备无法启动 | 驱动签名不受信任 | 禁用签名强制或导入证书 |
| 代码 28 | 驱动未安装 | 驱动文件缺失或路径错误 | 重新安装,检查 sys 文件 |
| 代码 52 | 签名验证失败 | 证书被吊销或过期 | 导入证书到受信任存储 |
| 代码 39 | 驱动损坏 | 驱动文件损坏或版本冲突 | 卸载后清理残留再重装 |
4.2 端口号冲突与重映射技巧
com0com 默认从 COM10 开始分配端口号,但你的系统里可能已经有其他设备占用了 COM10。这时候安装程序会自动跳到下一个可用端口,但有时候跳得不彻底,导致端口对不连续。比如创建了 COM10 和 COM12,中间隔了一个 COM11。
这种情况可以用 setupc 命令行工具手动调整。以管理员身份打开命令提示符,进入 com0com 安装目录,运行:
setupc.exe list这会列出当前所有的端口对。然后你可以用:
setupc.exe change CNCA0 PortName=COM20 setupc.exe change CNCB0 PortName=COM21把端口号改成你想要的。CNCA0 和 CNCB0 是端口对的内部标识,list 命令会显示出来。
实操心得:改端口号之前,先在设备管理器里把对应的虚拟串口设备禁用,改完再启用,否则可能出现端口号改了但设备管理器没刷新的情况。
4.3 与 USB 转串口设备的共存问题
很多人的电脑上同时有 USB 转串口设备(比如 CH340、CP2102、FT232)和 com0com 虚拟串口。这两者本身不冲突,但有一个坑:USB 转串口设备插拔时,系统会重新枚举串口,有时候会把 com0com 的虚拟端口号挤掉。
解决办法是给 com0com 的端口对分配一个比较高的端口号,比如 COM50 和 COM51,这样就不容易被 USB 设备占用。另外,在设备管理器的“端口设置”里,把 com0com 端口的“高级”选项中的“COM 端口号”锁定,也能减少冲突。
4.4 卸载不干净导致的重复安装失败
com0com 的卸载有时候会留下残留,导致再次安装时驱动注册失败。彻底清理的步骤是:
- 在设备管理器里卸载所有 com0com 设备,勾选“删除此设备的驱动程序软件”
- 删除
C:\Windows\System32\drivers\com0com.sys - 删除
C:\Windows\System32\DriverStore\FileRepository\下所有以 com0com 开头的文件夹 - 删除注册表项
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\com0com - 重启电脑
做完这些再重新安装,基本不会出问题。
4.5 在 Docker 容器和虚拟机中的使用限制
有人问过 com0com 能不能在 Docker 容器里用。答案是:不能直接用。com0com 是 Windows 内核驱动,Docker 容器共享的是宿主机的内核,但 Windows 容器对内核驱动的支持非常有限。如果你需要在容器里做串口通信测试,更实际的做法是在宿主机上创建 com0com 虚拟串口对,然后把其中一个端口映射到容器里,或者用网络串口转发工具(比如 ser2net 的 Windows 替代品)把串口数据转成 TCP 流。
虚拟机里的情况类似。VMware 和 VirtualBox 都支持把宿主机的串口映射到虚拟机,你可以在宿主机上建好 com0com 端口对,然后把其中一个端口作为虚拟机的串口设备。这样虚拟机里的系统就能通过这个端口和宿主机上的另一个端口通信。
5. 进阶用法:setupc 脚本化配置与自动化部署
5.1 用命令行批量创建端口对
如果你需要在多台机器上部署相同的虚拟串口配置,图形界面一个个点太慢了。setupc 支持脚本化操作,可以写一个批处理文件,一次性创建多对端口。
比如创建一个批处理setup_ports.bat:
@echo off cd /d C:\com0com setupc.exe install PortName=COM20 PortName=COM21 setupc.exe install PortName=COM22 PortName=COM23 setupc.exe install PortName=COM24 PortName=COM25 setupc.exe list pause以管理员身份运行这个批处理,就会自动创建三对虚拟串口。install命令的参数格式是PortName=COMx PortName=COMy,分别对应端口对的两端。
5.2 端口参数的高级配置
setupc 还支持设置端口的详细参数,比如波特率、数据位、流控等。虽然虚拟串口对这些参数不敏感,但某些上位机软件会检查这些设置。配置命令示例:
setupc.exe change CNCA0 EmuBR=yes EmuOverrun=yesEmuBR=yes表示模拟波特率,EmuOverrun=yes表示模拟溢出行为。这两个参数在调试对时序敏感的应用时很有用。
5.3 开机自动配置的实现
如果你希望每次开机都自动确保虚拟串口存在,可以把 setupc 命令放到任务计划程序里,设置成开机触发、以最高权限运行。这样即使系统更新导致驱动重新加载,端口配置也能自动恢复。
注意:任务计划里的命令要用完整路径,并且工作目录要设置成 com0com 的安装目录,否则 setupc 找不到驱动文件。
6. 实际调试场景中的经验分享
6.1 串口协议调试的典型工作流
我平时调试串口协议的标准流程是这样的:先在 com0com 里建一对端口,COM20 和 COM21。然后用一个串口调试助手打开 COM20,模拟设备端;用另一个调试助手或者自己写的测试程序打开 COM21,模拟上位机端。这样就能在不接硬件的情况下,完整测试协议解析、超时重试、数据校验这些逻辑。
等软件逻辑调通了,再把 COM20 换成真实的物理串口,接上硬件做联调。因为虚拟串口和物理串口在软件层面表现一致,切换过去基本不需要改代码。
6.2 波特率不匹配的排查思路
虽然虚拟串口对波特率不敏感,但如果你发现数据传输出错,还是要检查两端的波特率设置是否一致。有些串口库在打开端口时会强制设置波特率,如果两端设置不同,某些库可能会报错或者丢数据。
排查方法很简单:在设备管理器里查看 com0com 端口的属性,确认“端口设置”里的波特率。然后在你的应用程序里确认打开端口时设置的波特率。两边保持一致,问题基本就能解决。
6.3 数据丢失与缓冲区设置
虚拟串口的缓冲区默认大小可能不够,如果你传输大量数据,可能会出现丢包。可以在设备管理器的端口属性里,把“高级”选项中的“接收缓冲区”和“传输缓冲区”调大,比如都设成 8192 或者 16384。
另外,如果你的应用程序读取速度跟不上写入速度,也会导致缓冲区溢出。这种情况下,要么加快读取频率,要么在应用层加流控。
6.4 与其他虚拟串口工具的对比
市面上还有一些其他的虚拟串口工具,比如 Virtual Serial Port Driver、Eltima 的 Virtual COM Port 等。com0com 的优势是开源免费、驱动稳定、命令行工具强大。缺点是安装麻烦,签名问题需要手动处理。如果你只是偶尔用一下,不想折腾签名,可以考虑用商业工具,但那些通常要收费。对于长期做嵌入式开发的工程师来说,花半小时把 com0com 装好,后面省下的时间远不止这点。
7. 写在最后的一些个人体会
com0com 这个工具我从 Windows XP 时代就开始用,一路看着它在 Win7、Win10、Win11 上的兼容性变化。3.0.0.0 这个版本在 Win10/11 上的签名问题,本质上不是 com0com 的错,而是整个 Windows 驱动签名体系在收紧。理解了这个背景,你就知道为什么不能简单地“下一步下一步”装完,而是要先处理签名信任。
我自己的习惯是:新机器上先导入证书到受信任根存储,然后装 com0com,最后用 setupc 脚本批量创建端口对。这套流程走下来,基本不会遇到感叹号问题。如果遇到,就按第 4 节的排查表一步步查,90% 的情况都能解决。
还有一个小心得:装好之后,把 com0com 的安装目录和 setupc 命令的用法记在一个文本文件里,放在项目文档中。下次换电脑或者重装系统,直接照着做,不用再重新踩一遍坑。这个习惯帮我省了很多重复劳动,也推荐给你。