企业官网建设流程全解析

简介：面向Windows串口驱动开发者的过滤驱动示例工程，围绕串口驱动过滤与简单串口过滤驱动展开，适合内核驱动入门者或需要拦截、监控串口I/O的驱动工程师参考。资源共5个文件，压缩包约121KB，包含KMDF Driver1.sln解决方案、vcxproj工程文件、main.cpp驱动源码，以及已编译的serialport.dll和Hyper Terminal.exe可执行程序，便于直接对照源码理解过滤驱动结构并快速验证效果。已有383人浏览学习。该示例完整展示了上滤驱动与下滤驱动的分层设计、I/O请求流转和数据拦截思路，借助串口工具可实测驱动收发数据是否正常，既可用于学习WDM/KMDF驱动框架，也可作为串口监控、数据修改等二次开发的基础模板，适合在Visual Studio 2017和WinDbg环境下继续调试和扩展，对于理解串口驱动栈及驱动过滤机制均很有帮助。

1. 串口驱动过滤：在设备栈上加一道“透明旁路”，比应用层Hook省心十倍

很多人以为串口驱动就是个“装上能认、连上能发”的黑匣子：CH340 串口驱动装好、FTDI 串口驱动连上，就万事大吉。等到想抓一份收发数据做协议分析，或者想在不改硬件、不占 COM 口的情况下往串口数据流里做点手脚，才发现应用层 Hook 既不靠谱又会抢占端口。简单串口过滤驱动的思路，是在串口设备栈中间加一层自己的代码，不改厂商驱动、不动硬件、不占用串口，把所有读写 IRP 都“过一遍手”。你要的数据捕获、协议注入、透明转发、按需开关，全都能从这一层里长出来。这篇文章不聊理论模型，只聊怎么从零把它跑起来。

2. 用 WDK 在本地跑通最小串口过滤驱动：环境、工程与第一条 IRP

2.1 WDK 版本与 VS 版本怎么选：别被默认选项带偏

开发环境是第一个容易翻车的地方。我一般用 Visual Studio 2022 社区版配最新版 WDK，版本不一定要追新，关键是 WDK 必须和对齐的 Windows SDK 匹配。之前见过不少人从旧项目里拖来一份驱动源码，编译能过，一加载就报STATUS_REVISION_MISMATCH，查半天才发现是 WDK 头文件版本和系统不匹配。

选版本时记住一条：目标是 Win10/Win11，就选和当前已安装 SDK 同版本的 WDK；目标是老 Server 系统，反而要往后退几个版本。装上之后，在 VS 项目属性里把 Target Platform 设为 Windows 10/11，驱动工程会自动带上一整套默认参数。这里不用刻意背版本号，只需要在项目里记一下你用的是哪一版 SDK，将来排错的时候少走很多弯路。

调试通道我建议一步到位：装 WinDbg，配好双机调试或 VMware 串口调试。没有第二台机器时，也可以打开“本地内核调试”做简单验证，但本地内核调试看不到完整的设备栈信息，遇到蓝屏抓现场还是得靠双机。

2.2 工程骨架：一个能编译、能加载、能卸载的最小过滤驱动

“简单”二字体现在工程结构上。一个最小过滤驱动只需要三样东西：一个过滤设备对象、一个被挂接的目标设备对象、一组 IRP 分发函数。不需要实现 PnP 的 AddDevice，不需要处理电源 IRP，只需要你把过滤设备挂在目标串口设备栈顶上。

先定义一个扩展结构，用来保存上下文：

typedef struct _FILTER_EXTENSION { PDEVICE_OBJECT AttachedDevice; // 被挂接的下一层设备对象 BOOLEAN bHookRead; // 是否拦截读 BOOLEAN bHookWrite; // 是否拦截写 } FILTER_EXTENSION, *PFILTER_EXTENSION;

这个结构体在IoCreateDevice时通过DeviceExtensionSize参数传给系统，之后每次进分发函数都能从DeviceObject->DeviceExtension里拿到它。把上下文放到设备扩展里而不是全局变量，是为了将来挂多个串口时不互相干扰。

再看过滤设备的创建和挂接：

NTSTATUS CreateFilterDevice(PDRIVER_OBJECT DriverObject) { PDEVICE_OBJECT filterDevice = NULL; NTSTATUS status; UNICODE_STRING deviceName; PFILTER_EXTENSION pExt; // 过滤设备要有一个内核对象名，方便应用层用 CreateFile 打开来做配置 RtlInitUnicodeString(&deviceName, L"\\Device\\SimpleSerialFilter"); status = IoCreateDevice(DriverObject, sizeof(FILTER_EXTENSION), &deviceName, FILE_DEVICE_UNKNOWN, FILE_DEVICE_SECURE_OPEN, FALSE, &filterDevice); if (!NT_SUCCESS(status)) return status; // 设备对象默认不是缓冲IO也不是直接IO，过滤设备自己收发配置数据时用缓冲IO最省事 filterDevice->Flags |= DO_BUFFERED_IO; filterDevice->Flags &= ~DO_DEVICE_INITIALIZING; pExt = (PFILTER_EXTENSION)filterDevice->DeviceExtension; pExt->AttachedDevice = NULL; pExt->bHookRead = TRUE; pExt->bHookWrite = TRUE; g_FilterDevice = filterDevice; return status; }

FILE_DEVICE_SECURE_OPEN不是安全模块，它只表示“打开设备同时必须能打开设备名路径上的父对象”。DO_DEVICE_INITIALIZING标志必须清除，否则系统不认为这个设备初始化完成。这一步漏了，驱动加载不会报错，但应用层打开你的过滤设备时会一直返回STATUS_DEVICE_NOT_READY。

挂接目标串口的逻辑单独抽一个函数：

NTSTATUS AttachToTarget(PDRIVER_OBJECT DriverObject, PCWSTR TargetSymbolicLink) { UNICODE_STRING targetPath; PFILE_OBJECT fileObject = NULL; PDEVICE_OBJECT targetDevice = NULL; NTSTATUS status; PFILTER_EXTENSION pExt = g_FilterDevice->DeviceExtension; RtlInitUnicodeString(&targetPath, TargetSymbolicLink); // 形如 L"\\??\\COM3" // 通过符号链接拿到目标设备对象，同时拿到一个 FileObject 引用 status = IoGetDeviceObjectPointer(&targetPath, FILE_READ_ATTRIBUTES, &fileObject, &targetDevice); if (!NT_SUCCESS(status)) return status; // FileObject 的引用必须释放，否则目标设备永远不能被正确卸载 ObDereferenceObject(fileObject); // 把过滤设备挂到目标设备栈的顶层 status = IoAttachDeviceToDeviceStack(g_FilterDevice, targetDevice); if (!NT_SUCCESS(status)) return status; pExt->AttachedDevice = IoGetAttachedDevice(targetDevice); return status; }

IoGetDeviceObjectPointer返回的fileObject对象引用是很多入门者容易漏掉的。你不释放它，短时间看不出问题，但目标串口被拔掉时，那个 FileObject 会让设备对象不能完全释放，重插之后过滤驱动可能挂在一个已经死亡的设备栈上。

卸载例程正好做对称操作：

VOID DriverUnload(PDRIVER_OBJECT DriverObject) { PFILTER_EXTENSION pExt; if (g_FilterDevice) { pExt = (PFILTER_EXTENSION)g_FilterDevice->DeviceExtension; if (pExt->AttachedDevice) IoDetachDevice(pExt->AttachedDevice); IoDeleteDevice(g_FilterDevice); } }

IoDetachDevice和IoDeleteDevice的顺序不能反。先删过滤设备再摘挂接，系统可能在摘除过程中访问到一个已经不存在的设备对象，当场蓝屏。

2.3 加载与卸载的正确姿态：sc 命令、测试签名与 WinDbg

驱动编译出来是.sys文件，加载方式我建议用 sc 命令，开发期最直接：

sc create SimpleSerialFilter type= kernel binPath= C:\Drivers\SimpleSerialFilter.sys sc start SimpleSerialFilter sc stop SimpleSerialFilter sc delete SimpleSerialFilter

注意type= kernel的等号后面必须带一个空格，这是 sc 命令的老毛病。binPath路径最好用绝对路径，省得系统按相对路径去\SystemRoot\system32里找。

开发机没有正式签名证书，记得先打开测试签名：

bcdedit /set testsigning on

改完重启生效。测试签名期间不建议在这台机器上跑关键业务，因为系统对所有驱动都会放宽签名校验，风险自担。

加载不上去时先用 WinDbg 看崩溃点，或者用!drvobj SimpleSerialFilter查看驱动对象；看设备栈用!devstack \Device\Serial0。这套组合拳能解决九成“加载失败”的问题。

3. 把过滤逻辑写进 IRP 分发：拦截读写请求的完整路径

3.1 挂到设备栈之后，最先要处理的三个 IRP 类型

串口过滤驱动真正要关心的 IRP 只有三类：IRP_MJ_WRITE、IRP_MJ_READ和IRP_MJ_DEVICE_CONTROL。前两个携带实际收发数据，是过滤的重点；第三个携带串口配置，包括波特率、停止位、流控等，过滤驱动原则上必须原样透传。

最典型的反面教材是：为了省事，给IRP_MJ_DEVICE_CONTROL也挂一个完成例程，结果把IOCTL_SERIAL_SET_BAUD_RATE的返回状态改了，应用层设置波特率失败，串口数据全乱。我的规矩很简单：IOCTL 一律用IoSkipCurrentIrpStackLocation直接放行，不碰它。

分发函数的注册在 DriverEntry 里完成：

for (i = 0; i < IRP_MJ_MAXIMUM_FUNCTION; i++) DriverObject->MajorFunction[i] = DispatchPassThrough; DriverObject->MajorFunction[IRP_MJ_READ] = DispatchRead; DriverObject->MajorFunction[IRP_MJ_WRITE] = DispatchWrite; DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] = DispatchDeviceIoControl; DriverObject->DriverUnload = DriverUnload;

DispatchPassThrough是那个只用IoSkipCurrentIrpStackLocation加IoCallDriver的默认函数。其余所有 IRP 类型都不拦截，这是“简单”过滤驱动的正确打开方式。

3.2 写一个能抓到串口收发内容的 Dispatch 函数

先看写方向，也就是发送方向的拦截。应用层 WriteFile 下发数据时，IRP 从上往下经过我们的过滤驱动，再送到真正的串口驱动。如果你只关心“发出去的数据”，在下发前直接读缓冲区就够了，但我建议统一挂完成例程，这样读方向也能用同一套代码，减少维护成本。

NTSTATUS DispatchWrite(PDEVICE_OBJECT DeviceObject, PIRP Irp) { PFILTER_EXTENSION pExt = (PFILTER_EXTENSION)DeviceObject->DeviceExtension; PIO_STACK_LOCATION irpSp = IoGetCurrentIrpStackLocation(Irp); // 把当前栈位置复制到下一层，否则下层读到空的 IRP 栈位置 IoCopyCurrentIrpStackLocationToNext(Irp); // 挂完成例程，三个 TRUE 分别表示成功、失败、取消时都要回调 IoSetCompletionRoutine(Irp, WriteCompletion, pExt, TRUE, TRUE, TRUE); return IoCallDriver(pExt->AttachedDevice, Irp); }

这段代码里，IoCopyCurrentIrpStackLocationToNext必须放在IoSetCompletionRoutine之前，因为它会覆盖当前 IRP 栈位置的内容，如果你先挂了回调再复制，回调信息会被一并覆盖掉。完成例程的Context传pExt，而不是传DeviceObject，是因为完成例程执行时 IRQL 可能在DISPATCH_LEVEL，从这个上下文里查设备扩展最安全。

3.3 从 CompletionRoutine 把数据抄出来：缓冲区归属与生命周期

完成例程是过滤驱动最容易写崩的地方。它运行在DISPATCH_LEVEL，意味着你只能调用Dispatch级别的函数，不能碰PASSIVE_LEVEL的 API，不能等锁，不能做耗时操作。简单做法是：在完成例程里把数据录成调试输出，或者拷贝到预分配的非分页缓冲里，交给更高 IRQL 的 DPCTimer 再导出到应用层。

NTSTATUS WriteCompletion(PDEVICE_OBJECT DeviceObject, PIRP Irp, PVOID Context) { PFILTER_EXTENSION pExt = (PFILTER_EXTENSION)Context; PVOID buffer = NULL; ULONG length = 0; ULONG i; if (pExt->bHookWrite && NT_SUCCESS(Irp->IoStatus.Status)) { length = (ULONG)Irp->IoStatus.Information; if (length > 0) { // 先处理 DIRECT_IO，再退回 BUFFERED_IO if (Irp->MdlAddress) { buffer = MmGetSystemAddressForMdlSafe(Irp->MdlAddress, NormalPagePriority); } else { buffer = Irp->AssociatedIrp.SystemBuffer; } if (buffer) { DbgPrint("[SFilter] TX %u bytes:", length); for (i = 0; i < length && i < 64; i++) DbgPrint("%02X ", ((PUCHAR)buffer)[i]); } } } // 观察型过滤驱动直接放行，不要动 IoStatus return STATUS_SUCCESS; }

这里有个关键细节：数据长度不能用IoGetCurrentIrpStackLocation(Irp)->Parameters.Write.Length，而要用Irp->IoStatus.Information。下层驱动可能只写入了部分字节，比如缓冲区满时实际写入长度比请求长度短，你用请求长度去拷贝，读出来的后半段就是未初始化内存。

缓冲区选型也是老生常谈：目标设备是DO_DIRECT_IO时，数据在 MDL 里，要用MmGetSystemAddressForMdlSafe；目标是DO_BUFFERED_IO时，数据在SystemBuffer。两种都可能在真实串口驱动里出现，所以代码里两个分支都留着，别省。

读方向完全对称，只需要把DispatchWrite换成DispatchRead，完成例程里打印RX。挂串口过滤驱动时，读写的完成例程必须都返回STATUS_SUCCESS，除非你故意要挂起某个 IRP 实现流控。不要为了“多看一会儿数据”就返回STATUS_MORE_PROCESSING_REQUIRED，后面专门讲这个坑。

4. 按 COM 口做目标过滤：设备栈类型、符号链接与 IOCTL 配置

4.1 目标串口怎么找：从 \Device\Serial0 到 USB 转串口的设备栈差异

传统 PC 串口的内核设备名一般是\Device\Serial0、\Device\Serial1，比较简单，在 DriverEntry 里硬编码IoAttachDevice到\\Device\\Serial0也能跑。但现实是，绝大多数人用的是 CH340、FTDI 这类 USB 转串口，它们在系统里枚举出来的设备名是\Device\USBPDO-xxx那一串，还会动态生成 COM 端口符号链接。你硬编码Serial0，USB 转串口插上来时过滤驱动啥都拦不到。

正确的做法是：运行时通过 COM 符号链接去找目标设备对象。应用层拿到当前可用的 COM 口编号后，把字符串传给过滤驱动，驱动内部调用IoGetDeviceObjectPointer解析并挂接。

// 伪代码：应用层传进来一个 UNICODE_STRING "\\??\\COM3" // 过滤驱动不能直接用 IoAttachDevice 处理符号链接，必须走 IoGetDeviceObjectPointer PCWSTR TargetSymbolicLink = L"\\??\\COM3"; status = AttachToTarget(DriverObject, TargetSymbolicLink);

USB 转串口的设备栈比传统串口多了一层 USB 设备栈，\Device\USBPDO-xxx之上是 USB 功能驱动，再往上才是串口类驱动。过滤驱动挂接时，IoAttachDeviceToDeviceStack会把你挂到当前设备栈的栈顶，也就是串口类驱动之上。这个位置是正确的，因为你要拦的是串口读写 IRP，而不是 USB 总线层的 URB。

调试时用!devstack看栈结构是最直观的方法。打开 WinDbg，输入!devstack \Device\Serial0，能看到设备栈从下到上每一层设备对象和所属驱动。挂接成功后，最顶上多出来的那层就是你的过滤设备。

4.2 让过滤驱动按需开关：IOCTL 输入过滤/输出过滤/透传三种模式

生产环境的过滤驱动不能永远无条件拦截，否则出了事你连后悔药都没有。我通常会做三个模式：只拦截发送、只拦截接收、透传不拦截。应用层通过用户态 IOCTL 下发配置。

驱动端定义：

#define IOCTL_SERIAL_FILTER_SET_MODE \ CTL_CODE(FILE_DEVICE_UNKNOWN, 0x800, METHOD_BUFFERED, FILE_ANY_ACCESS) typedef struct _FILTER_MODE { BOOLEAN bEnable; // 总开关 BOOLEAN bHookRead; // 拦截读 BOOLEAN bHookWrite; // 拦截写 UCHAR Reserved; // 对齐保留，别问为什么，问就是结构体对齐的血泪 } FILTER_MODE;

应用层打开\\.\SimpleSerialFilter，用DeviceIoControl下发结构体。驱动端在DispatchDeviceIoControl里复制参数后存到设备扩展里：

NTSTATUS DispatchDeviceIoControl(PDEVICE_OBJECT DeviceObject, PIRP Irp) { PFILTER_EXTENSION pExt = (PFILTER_EXTENSION)DeviceObject->DeviceExtension; PIO_STACK_LOCATION irpSp = IoGetCurrentIrpStackLocation(Irp); FILTER_MODE mode; NTSTATUS status = STATUS_SUCCESS; if (irpSp->Parameters.DeviceIoControl.IoControlCode == IOCTL_SERIAL_FILTER_SET_MODE) { if (irpSp->Parameters.DeviceIoControl.InputBufferLength < sizeof(FILTER_MODE)) { status = STATUS_BUFFER_TOO_SMALL; } else { RtlCopyMemory(&mode, Irp->AssociatedIrp.SystemBuffer, sizeof(FILTER_MODE)); pExt->bHookRead = mode.bEnable && mode.bHookRead; pExt->bHookWrite = mode.bEnable && mode.bHookWrite; status = STATUS_SUCCESS; Irp->IoStatus.Information = 0; } IoCompleteRequest(Irp, IO_NO_INCREMENT); return status; } // 其它串口 IOCTL 一律透传 IoSkipCurrentIrpStackLocation(Irp); return IoCallDriver(pExt->AttachedDevice, Irp); }

这里要特意说明：FILTER_MODE是 4 字节，结构体对齐后大小正好是 4，Reserved字段用来避免未来加字段时破坏兼容性。很多新手在这个结构体里放一个BOOLEAN加一个ULONG，编译成 8 字节，应用层和驱动层有一边用了不同的打包方式，DeviceIoControl的数据就全对不上。

4.3 设备栈漂移与 PnP 状态机：为什么插拔一次就丢了过滤

USB 转串口是即插即用设备，每次插拔，系统都会重新枚举整个设备栈，之前挂接的过滤设备对象会被拆除。如果你的驱动只在启动时挂一次，拔线重插之后，过滤就静默失效，收发数据再也不经过你这一层。

这是很多“简单串口过滤驱动”翻车最狠的地方：单次挂接在测试机上一切正常，换到现场设备频繁插拔就丢数据。解决办法有三个，按复杂程度递增：

第一种是应用层监听WM_DEVICECHANGE，发现 COM 口重新到达后，重新向过滤驱动发一次绑定指令，让驱动重新挂接。这个办法最省事，也适合“简单”过滤驱动的定位。

第二种是写一个独立的 PnP 通知回调，在驱动里用IoRegisterPlugPlayNotification监听串口设备类的新增事件，发现设备到达时自动挂接。这个办法最可靠，但代码量会明显增加。

第三种是走 INF 安装文件，把过滤驱动写成目标串口设备的 Upper Filters，让系统在设备栈重建时自动带上你的驱动。这条路最正规，但需要写 INF、处理硬件 ID 匹配、还要签驱动，复杂度直接上一个量级。想清楚自己的目标再决定，别一上来就追求“正规军”。

5. 串口过滤驱动避坑手册：5条能让你蓝屏重启的教训

5.1 完成例程“失踪”：STATUS_MORE_PROCESSING_REQUIRED 不能随便 return

现象：过滤驱动挂上之后，串口能打开，但一收发数据就卡死，ReadFile 永远不返回，WriteFile 也像掉进黑洞。

原因：在完成例程里返回了STATUS_MORE_PROCESSING_REQUIRED，又没有自己再调IoCompleteRequest把这个 IRP 继续完成。I/O 管理器拿到这个状态码后，认为你有后续处理要接管 IRP，于是不再推进完成流程。IRP 卡在中间，发起读写的线程等不到完成信号，自然永不了工。

解决：观察型过滤驱动，完成例程一律返回STATUS_SUCCESS。只有当你要做“挂起、等数据拼接完再继续下发”这类流控逻辑时，才动用STATUS_MORE_PROCESSING_REQUIRED，而且必须保证后续有某种路径把这个 IRP 补完。

5.2 Buffer 全是零或错位：Information 字段才是真正的长度

现象：驱动日志里能抓到数据，但内容对不上。发送方向的数据和实际写入的字节顺序差一位，接收方向偶尔冒出 0x00 填充。

原因：用了Parameters.Read.Length或Parameters.Write.Length作为拷贝长度。这个字段表示请求的长度，不代表实际完成长度。串口驱动在缓冲不足、超时、被取消等场景下，实际完成长度更短，你按请求长度拷贝，多读出来的部分就是缓冲区里的旧数据或零。

解决：一律用Irp->IoStatus.Information作为拷贝长度，并且先判断NT_SUCCESS(Irp->IoStatus.Status)。只有状态成功时 Information 才是可靠的有效数据长度。

5.3 卸载即崩溃：IoDetachDevice 和引用计数的顺序不能反

现象：驱动运行期间没问题，一sc stop系统就蓝屏，dump 经常指向IopDeleteDevice或IoDetachDevice。

原因：DriverUnload 里先IoDeleteDevice删掉了过滤设备，又去IoDetachDevice摘挂接。摘挂接时系统还要访问过滤设备的扩展结构去更新设备栈链，设备对象已经没了，直接访问释放内存。

解决：先IoDetachDevice摘除挂接，再IoDeleteDevice删除过滤设备本体。摘除挂接后要确保没有 IRP 还在设备栈里流转，稳妥的做法是加一个引用计数，等所有挂接的 IRP 都返回后再卸载。简单场景下，先 Detach 再 Delete 就够。

5.4 CH340/FTDI 设备栈差异：挂到错误设备对象上就没数据

现象：过滤驱动在传统串口上抓包一切正常，换成 CH340 串口驱动或 FTDI 串口驱动后，日志里一个字节都看不到。

原因：USB 转串口枚举出的 COM 口设备对象在 USB 设备栈之上，真正跑串口读写 IRP 的驱动是串口类驱动。如果你按传统\Device\Serial0硬编码挂接，USB 转串口根本不走那条链，过滤驱动自然拦不到。

解决：目标设备一律用IoGetDeviceObjectPointer从 COM 符号链接解析，USB 转串口和传统串口都用同一套逻辑。挂接后先用 WinDbg 的!devstack确认你挂到了有数据流转的那条栈上，而不是 USB 栈底层。

5.5 DbgPrint 看不到输出：先确认调试通道和 DbgView 权限

现象：过滤驱动代码看着没毛病，IRP 也流转了，但 DbgPrint 的输出就是看不见，以为驱动没加载。

原因：内核调试器没连接时，DbgPrint 默认不上调试输出通道。很多人开了 DbgView 但没勾选 Capture Kernel，或者没以管理员权限运行，内核输出根本进不来。

解决：WinDbg 双机调试最直接；没有双机环境时，用 DbgView 要勾选 Capture Kernel，并确保以管理员身份运行。加载测试签名驱动之前，先把调试通道调通，否则后边排查全是猜。

6. 用应用层打桩验证过滤结果：一条完整数据链路的自检方法

6.1 写一个串口收发打桩程序，与过滤日志逐字节对比

驱动写完不能只靠“打开串口没蓝屏”来判断成功。我的习惯是用一个可控的收发打桩程序，发固定 pattern，再用回环线把 TX 和 RX 短接，让驱动日志里同时出现发送和接收两个方向的数据，逐字节对比。

using (var com = new SerialPort("COM3", 115200, Parity.None, 8, StopBits.One)) { com.Open(); byte[] tx = { 0x01, 0x02, 0x03, 0x04, 0xAA, 0x55, 0x00, 0xFF }; com.Write(tx, 0, tx.Length); Thread.Sleep(200); byte[] rx = new byte[tx.Length]; int read = com.Read(rx, 0, tx.Length); Console.WriteLine($"Read {read} bytes"); }

打桩程序的意义在于可控：固定串口参数，固定数据模式，不发随机流，这样驱动日志里的 RX 和 TX 才能对上。回环线是必须的，没有回环线 Read 会一直阻塞超时，你分不清是驱动丢包还是物理链路就没通。

对比时别只看长度，要看每个字节的值。驱动日志用十六进制打印，应用层打桩程序也用十六进制输出，两边对齐一眼就能看出过滤驱动有没有篡改数据。第一次跑通之后，再换不同长度、不同波特率、带流控的场景做回归。

6.2 把过滤驱动做成“帧观察器”的三个进阶方向

跑通收发拦截之后，这个过滤驱动就能往前走了。最常见的三个方向是按帧切割：在完成例程里识别帧头帧尾，把一堆裸字节拼成完整帧再导出；透明改包：对特定字节序列做替换，做到应用层无感知的数据改写；以及协议仿真：在过滤层把下发的 IRP 拦下来，直接回复伪造数据，实现不插真实设备的仿真测试。这三个方向都用得着过滤驱动的核心能力：看得见双向数据、站得住设备栈中间。

以前我在应用层用 Hook 抓串口数据那套方案，遇到占用串口的程序基本就废了，还得猜对方 API 调用的时机。把简单串口过滤驱动做出来后，问题一次性解决：不管谁来操作 COM 口，读写都得从我这层过。这个方案已经替我省过两次现场排查的冤枉路，希望帮到你。

本文还有配套的精品资源，点击获取