简介这份资源提供Windows平台下虚拟串口的完整源代码面向从事驱动开发、串口通信模拟及内核过滤驱动学习的VC/.NET开发者可用于研究虚拟串口设备的枚举、读写与IOCTL交互机制。压缩包共77个文件约182KB以C与C源文件、头文件、makefile和sources构建脚本为核心辅以sys驱动文件、inf安装信息、dsp/dsw工程文件及日志、说明文档覆盖总线枚举、过滤驱动、读写与PnP处理等模块目录结构清晰便于按功能定位代码。资源中附有设备名处理说明、超级终端收发文件日志及Win32应用接口文档能帮助读者理解虚拟串口从驱动到应用层的完整链路。目前已有1484人学习下载适合具备一定Windows API与驱动基础、希望深入掌握虚拟串口实现原理的开发者参考借鉴。1. 虚拟串口不是玄学从一根 USB 线到两个进程的对话很多人第一次接触「Windows 下虚拟串口的源代码」是因为手头只有一台电脑却要调试两个本该通过串口通信的程序。真实串口要插线、要配对、要占用物理 COM 口而虚拟串口驱动能在系统里凭空造出一对互相连通的 COM 口——往 COM3 写COM4 就能读到。这背后不是魔法是 Windows 驱动模型里一个叫「虚拟串口驱动」的内核组件在转发数据。这个方向适合三类人做工业上位机、需要模拟下位机响应的嵌入式工程师写自动化测试、要批量造串口设备的测试开发以及想搞懂 Windows 驱动通信机制、拿串口当切入点的系统程序员。它解决的核心问题是在没有物理硬件的情况下让串口通信链路完整跑起来并且你能改源码、加日志、控时序。接下来我按「先跑通、再改源码、最后排坑」的顺序把这条链路拆开讲。2. 虚拟串口驱动到底在系统里做了什么2.1 从 CreateFile 到 IRP一次写操作为什么能跨进程到达Windows 下应用程序打开串口走的是CreateFile(\\\\.\\COM3, ...)拿到句柄后调WriteFile。这个调用最终变成内核里的一个 IRPI/O Request Packet交给负责 COM3 的驱动栈处理。真实串口的驱动栈底部是硬件抽象层而虚拟串口驱动的做法是在驱动里拦截这个 IRP不往下发给硬件而是直接把它转交给「配对端口」的读队列。所以虚拟串口驱动的本质是一个中间层驱动它注册成串口设备但内部维护两个端口对象和两条队列。写 IRP 进 A 口队列驱动把它挂到 B 口的读等待队列上B 口上阻塞的ReadFile就被唤醒。整个过程不经过任何物理线路延迟通常在微秒级比真实串口还快。理解这一点很关键源码里你看到的不是「模拟波特率」而是「模拟 IRP 流转」。波特率、数据位这些参数在虚拟驱动里往往只是记录状态并不真正控制时序——这也是为什么虚拟串口能跑出远超 115200 的吞吐。2.2 选型WDM、KMDF 还是用户态模拟动手前先定路线三条路差别很大。第一条是WDM 传统驱动直接处理 IRP控制力最强但代码量大电源管理、即插即用都要自己写新手容易在 IRP 完成例程上翻车。第二条是KMDFKernel-Mode Driver Framework微软把 WDM 的样板代码封装成对象队列、锁、电源都有框架兜底。写虚拟串口我一般推荐这条源码量能压到 WDM 的一半以下且WdfIoQueue天然适合做读写队列。第三条是用户态模拟用命名管道加一个 COM 口重定向层或者干脆用两个命名管道冒充串口。它不需要签名、不需要测试模式但很多依赖真实串口 IOCTL 的程序会识别失败。路线开发难度是否需要签名兼容性适用场景WDM高是最好学习 IRP 机制KMDF中是好生产级虚拟串口用户态低否一般快速验证、纯应用层测试选 KMDF 的话你需要 Visual Studio 加 WDKWindows Driver Kit并且目标机器要开启测试签名模式否则驱动加载会被系统拒绝。这一步没有后悔药先确认环境再写代码。2.3 最小可跑通的 KMDF 虚拟串口骨架下面这段是驱动入口和队列创建的核心骨架省略了头文件和 INF重点看结构。// 驱动入口创建控制设备对象 NTSTATUS DriverEntry(PDRIVER_OBJECT DriverObject, PUNICODE_STRING RegistryPath) { WDF_DRIVER_CONFIG config; WDF_DRIVER_CONFIG_INIT(config, EvtDeviceAdd); // 设备添加回调 return WdfDriverCreate(DriverObject, RegistryPath, WDF_NO_OBJECT_ATTRIBUTES, config, WDF_NO_HANDLE); } // 设备添加创建两个串口设备并配对 NTSTATUS EvtDeviceAdd(WDFDRIVER Driver, PWDFDEVICE_INIT DeviceInit) { WDFDEVICE device; NTSTATUS status WdfDeviceCreate(DeviceInit, WDF_NO_OBJECT_ATTRIBUTES, device); if (!NT_SUCCESS(status)) return status; // 创建默认 I/O 队列串行处理请求 WDF_IO_QUEUE_CONFIG queueConfig; WDF_IO_QUEUE_CONFIG_INIT_DEFAULT_QUEUE(queueConfig, WdfIoQueueDispatchSequential); queueConfig.EvtIoRead EvtIoRead; // 读请求回调 queueConfig.EvtIoWrite EvtIoWrite; // 写请求回调 queueConfig.EvtIoDeviceControl EvtIoDeviceControl; // IOCTL 处理 WDFQUEUE queue; return WdfIoQueueCreate(device, queueConfig, WDF_NO_OBJECT_ATTRIBUTES, queue); }逻辑说明DriverEntry只做一件事注册EvtDeviceAdd。真正的设备创建在EvtDeviceAdd里WdfIoQueueCreate建了一个顺序队列意味着同一时刻只处理一个请求避免读写竞争。参数上WdfIoQueueDispatchSequential适合串口这种天然串行的设备如果你要支持并发多线程访问可以换成WdfIoQueueDispatchParallel但那样就得自己加锁保护端口状态。写回调EvtIoWrite里要做的是取出写缓冲区找到配对端口的读队列把数据投递过去。读回调EvtIoRead则相反如果配对端口没有数据就把当前读请求挂起等写请求来唤醒。这个「挂起—唤醒」是虚拟串口源码里最容易写错的地方后面避坑章节会细说。3. 把源码编译成能加载的驱动环境、INF 与签名3.1 搭建 WDK 编译环境与项目配置先装 Visual Studio带 C 桌面开发负载再装对应版本的 WDK。两者版本要匹配否则项目模板里找不到「Kernel Mode Driver, Empty (KMDF)」。新建项目后在项目属性里确认三处Driver Settings→Target OS Version选 Windows 10 或更高Driver Settings→Target Platform选 DesktopInf2Cat的Use Local Time设为 Yes避免时区导致的签名时间戳问题。编译产物是一个.sys文件加一个.inf文件。.sys是驱动本体.inf告诉系统怎么安装、注册哪些设备。很多人编译过了却装不上问题几乎都出在 INF。3.2 INF 文件里必须写对的三个字段INF 是安装脚本虚拟串口要伪装成串口设备关键在[Manufacturer]和[Models]段。[Manufacturer] %VendorName%DeviceList, NTamd64 [DeviceList.NTamd64] %DeviceName%Install, root\VirtualSerial [Install.NT] CopyFilesDriverCopyFiles [Install.NT.Services] AddServiceVirtualSerial, 0x00000002, SerialService [SerialService] DisplayName %ServiceName% ServiceType 1 ; 内核驱动 StartType 3 ; 手动启动便于调试 ErrorControl 1 ServiceBinary %12%\VirtualSerial.sys逻辑说明root\VirtualSerial是硬件 ID用root\前缀表示这是根枚举设备不需要真实硬件。StartType3是手动启动调试阶段别设成自动否则蓝屏后重启又自动加载容易陷入循环。ServiceBinary里的%12%是系统目录占位符不要写死路径。参数上ServiceType1表示内核驱动ErrorControl1表示出错时记录日志但不阻止启动。如果你希望驱动加载失败时系统直接报错可以设成 3但调试期不建议。3.3 测试签名与加载两条命令搞定驱动没签名系统默认拒绝加载。开发机开启测试模式# 以管理员身份运行开启测试签名模式 bcdedit /set testsigning on # 重启后生效然后创建并安装测试证书 makecert -r -pe -ss PrivateCertStore -n CNTestCert TestCert.cer signtool sign /v /s PrivateCertStore /n TestCert /t http://timestamp.example.com VirtualSerial.sys逻辑说明bcdedit /set testsigning on让系统接受测试签名重启后桌面右下角会出现测试模式水印这是正常的。makecert生成自签名证书signtool把证书签进.sys。注意时间戳服务器地址要换成可用的否则签名会因无时间戳而失效。装驱动用devcon或设备管理器「添加过时硬件」手动选择 INF。装完后在设备管理器里应该能看到两个新的 COM 口用串口调试助手打开一个发数据另一个能收到链路就通了。4. 读写队列与 IOCTL源码里最容易翻车的三处4.1 读请求挂起与唤醒的正确姿势虚拟串口最核心的逻辑是A 口ReadFile时如果没数据请求不能直接完成要挂起B 口WriteFile时把数据交给 A 口挂起的读请求并完成它。// 写回调把数据转交给配对端口的读队列 VOID EvtIoWrite(WDFQUEUE Queue, WDFREQUEST Request, size_t Length) { PVOID buffer; WDFREQUEST readReq; // 取出写缓冲区 WdfRequestRetrieveInputBuffer(Request, Length, buffer, NULL); // 从配对端口的挂起读队列取一个等待中的读请求 NTSTATUS status WdfIoQueueRetrieveNextRequest(g_PeerReadQueue, readReq); if (NT_SUCCESS(status)) { // 有等待的读请求直接填充数据并完成 PVOID outBuf; WdfRequestRetrieveOutputBuffer(readReq, Length, outBuf, NULL); RtlCopyMemory(outBuf, buffer, Length); WdfRequestCompleteWithInformation(readReq, STATUS_SUCCESS, Length); WdfRequestCompleteWithInformation(Request, STATUS_SUCCESS, Length); } else { // 没有读请求等待把写请求挂到待处理队列 WdfRequestForwardToIoQueue(Request, g_PendingWriteQueue); } }逻辑说明WdfIoQueueRetrieveNextRequest从配对端口的读队列里取一个挂起的请求取到就拷贝数据并完成双方。取不到说明对端还没读这时不能丢数据要把写请求转发到待处理队列等对端来读时再取。参数上Length是本次写请求的字节数拷贝时要用min(Length, 对端缓冲区大小)否则会越界。这里有个血泪经验WdfRequestCompleteWithInformation的第三个参数必须填实际传输字节数填 0 的话上层WriteFile会认为没写成功很多程序会因此卡死。4.2 IOCTL 处理波特率、线路控制与握手信号串口程序除了读写还会发一堆 IOCTL 查询和设置波特率、数据位、握手信号。虚拟驱动不真正控制硬件但必须正确回应否则程序会认为串口不可用。VOID EvtIoDeviceControl(WDFQUEUE Queue, WDFREQUEST Request, size_t OutLen, size_t InLen, ULONG IoControlCode) { NTSTATUS status STATUS_SUCCESS; size_t info 0; switch (IoControlCode) { case IOCTL_SERIAL_SET_BAUD_RATE: // 记录波特率到设备上下文不真正生效 g_BaudRate *(PULONG)GetInputBuffer(Request); break; case IOCTL_SERIAL_GET_BAUD_RATE: *(PULONG)GetOutputBuffer(Request) g_BaudRate; info sizeof(ULONG); break; case IOCTL_SERIAL_SET_HANDFLOW: // 握手信号同样只记录状态 break; default: status STATUS_INVALID_DEVICE_REQUEST; break; } WdfRequestCompleteWithInformation(Request, status, info); }逻辑说明IOCTL_SERIAL_SET_BAUD_RATE只把值存进全局变量GET时原样返回这样程序读到的波特率和它设的一致不会报错。IOCTL_SERIAL_SET_HANDFLOW涉及 RTS/CTS 握手虚拟串口通常直接忽略但必须返回成功否则打开串口的程序会失败。参数上GetInputBuffer和GetOutputBuffer要按 IOCTL 的传输方式METHOD_BUFFERED 等正确取取错会蓝屏。4.3 设备上下文与并发保护两个端口共享状态波特率、配对关系、待处理队列多线程访问时必须保护。KMDF 里常用WDFSPINLOCK或WDFWAITLOCK。// 在设备添加时初始化锁 WDF_OBJECT_ATTRIBUTES attrs; WDF_OBJECT_ATTRIBUTES_INIT_CONTEXT_TYPE(attrs, DEVICE_CONTEXT); WdfDeviceCreate(DeviceInit, attrs, device); // 访问共享状态前加锁 WdfWaitLockAcquire(g_StateLock, NULL); g_BaudRate newRate; WdfWaitLockRelease(g_StateLock);逻辑说明WDFWAITLOCK允许在 PASSIVE_LEVEL 等待适合读写回调这种可能阻塞的场景WDFSPINLOCK用于 DISPATCH_LEVEL不能阻塞。虚拟串口的读写回调通常在 PASSIVE_LEVEL用等待锁更安全。参数上锁的粒度要小只包住共享变量操作不要把整个数据拷贝包进去否则并发性能会掉。5. 避坑与排查虚拟串口源码调试的五个真实翻车点5.1 现象驱动装上了但设备管理器里出现黄色感叹号原因INF 里的硬件 ID 和驱动里WdfDeviceCreate注册的 ID 不一致或者ServiceBinary路径写错。解决用pnputil /enum-drivers查看驱动是否注册成功再用设备管理器「属性 → 详细信息 → 硬件 ID」核对两边必须完全一致。路径统一用%12%占位符不要写绝对路径。5.2 现象打开 COM 口成功但一读就卡死原因读请求挂起后写请求没有正确唤醒它或者WdfRequestCompleteWithInformation的字节数填了 0。解决在写回调里加DbgPrint打印取到的读请求句柄确认WdfIoQueueRetrieveNextRequest返回成功完成时字节数填实际拷贝长度。另外检查读队列是不是被设成了WdfIoQueueDispatchSequential且没有及时重新入队导致后续读请求进不来。5.3 现象两个端口能通但大数据量时丢包原因待处理队列没有上限或者写请求转发后没有在合适时机取回。解决给待处理队列设一个最大深度超过就返回STATUS_BUFFER_OVERFLOW让上层重试同时在读回调里优先从待处理队列取数据而不是只等新写请求。参数上队列深度按实际吞吐调一般 16 到 64 够用。5.4 现象系统蓝屏错误码 IRQL_NOT_LESS_OR_EQUAL原因在 DISPATCH_LEVEL 访问了分页内存或者用了错误的锁。解决检查所有DbgPrint和内存拷贝是否在正确 IRQL读写回调里避免直接访问用户态缓冲区必须用WdfRequestRetrieveInputBuffer这类框架函数。锁统一用WDFWAITLOCK别在可能阻塞的地方用自旋锁。5.5 现象程序能打开串口但一发 IOCTL 就失败原因IOCTL 的传输方式没匹配或者GetInputBuffer在 METHOD_NEITHER 下取错。解决对照IOCTL_SERIAL_*的定义确认传输方式METHOD_BUFFERED 用WdfRequestRetrieveInputBufferMETHOD_NEITHER 要自己处理Parameters.DeviceIoControl.Type3InputBuffer。不确定就先只处理 SET/GET BAUD RATE 两个最常用的跑通再扩。6. 进阶用 WDF 对象生命周期管理避免句柄泄漏写到后面你会发现虚拟串口源码的难点不在读写逻辑而在对象生命周期。KMDF 里每个WDFREQUEST、WDFQUEUE、WDFDEVICE都有引用计数漏掉一次WdfObjectDelete或错误完成请求就会句柄泄漏跑几天后系统资源耗尽。我的习惯是所有请求只在两个地方完成——要么在回调里直接WdfRequestComplete要么转发到队列后由队列的清理回调统一处理。绝不在多个分支里各写一次完成那样迟早重复完成导致蓝屏。下面这个模式我一直在用// 统一的请求完成封装避免重复完成 VOID CompleteRequestSafe(WDFREQUEST Request, NTSTATUS Status, size_t Info) { // 先标记请求已被处理防止重复完成 if (InterlockedExchange(g_RequestFlags[WdfRequestGetId(Request)], 1) 0) { WdfRequestCompleteWithInformation(Request, Status, Info); } }逻辑说明用一个标志数组按请求 ID 记录是否已完成InterlockedExchange保证原子性。参数上WdfRequestGetId在 KMDF 里能拿到请求的唯一标识但要注意请求完成后 ID 可能复用所以标志数组要及时清理。这个封装不是万能的但能挡住大部分重复完成的低级错误。验证方法上我一般用verifier加/standard开启驱动验证器跑一轮读写压力测试看有没有泄漏报告。再配合!wdfkd.wdfhandle调试扩展查看对象引用计数正常情况请求完成后计数应该归零。这套组合拳下来虚拟串口驱动能稳定跑几周不掉链子。最后说个教训我早期写虚拟串口时为了图快把读请求直接完成而不挂起结果上层程序轮询读CPU 直接飙到 100%。后来老老实实按「挂起—唤醒」模型写CPU 占用降到接近零。虚拟串口这东西快不是本事稳才是。希望帮到你。本文还有配套的精品资源点击获取