简介针对 NDIS 6.0 驱动开发中 miniport 示例稀缺的问题这份资源以 Realtek 8111/8168/8169/8110 等 PCI 千兆以太网控制器为对象提供了一套完整的 miniport 驱动实例源代码适合希望从零编写 NDIS 小端口驱动或研究网卡驱动框架的底层开发人员。资源包共 69 个文件压缩后约 615KB主体是 3 个 zip 源码包分别对应 LSO 巨帧支持、PM 电源管理支持及 release 发布版本另含 25 个 gif、15 个 png、7 个 htm、16 个 js 等文件主要为参考页面、图示与脚本资料。目前已有 1240 人学习下载。读者通过该实例可以快速理解 NDIS 6.0 miniport 驱动的初始化流程、数据收发路径、硬件寄存器配置和电源管理等关键模块并对照 Realtek 流行千兆网卡控制器进行移植或二次开发弥补 DDK 自带 E100BEX 之外缺少现成参考实现的短板尤其适合驱动初学者与网卡开发人员按图索骥边看边改。1. NDIS 小端口驱动在干什么写网卡驱动前先把模型看对NDIS 小端口驱动miniport driver是 Windows 网络栈里离硬件最近的一层专门负责管理以太网卡控制器收发队列、中断、链路状态、电源管理这些寄存器操作都要在小端口里完成。上层 TCP/IP 协议栈不关心你的芯片长什么样它只通过 NDIS 提供的 NET_BUFFER 接口把数据交给你再由你搬运到硬件。给一款新的 PCIe 以太网卡写 Windows 驱动本质上就是把 NDIS 的回调函数一一实现。这篇笔记的目标读者是刚接手网卡驱动的开发者以及打算评估自制驱动成本的技术负责人看完能理解 NDIS 驱动模型是什么、工程怎么搭、数据路径怎么走还有哪些坑绕不开。2. 用 WDK 把 miniport 工程跑起来DriverEntry 与适配器注册2.1 为什么选 NDIS 小端口模型而不是自己写 WDM 驱动你当然可以用 WDM 或 KMDF 直接枚举 PCIe 设备、自己申请中断、自己向协议栈暴露网络接口但这样做等于把 NDIS 已经做好的调度、电源管理、即插即用、WOL、SR-IOV、虚拟机队列这些事情全部重造一遍。我一般建议除非是超低延迟专用卡需要绕过 NDIS 的层叠结构普通以太网卡的 Windows 驱动都走 NDIS 小端口模型。在 NDIS 6.x 之前驱动里到处是NDIS_MAC之类的旧宏收发路径也混乱。从 Windows Vista 开始 NDIS 6.0 全面转向以NET_BUFFER_LIST为中心的收发模型驱动只需要实现一小组成员函数比如初始化、发送、返回、OID 请求、重置、暂停、唤醒。NDIS 会在合适的时机回调你你的代码只需要在回调里完成硬件操作。对硬件厂商来说这个模型最大的好处是你不需要关心上层是谁在发包也不用担心收到的是 IPv4 还是 IPv6NDIS 全帮你拆好了。2.2 从空项目到 DriverEntry注册特征结构体建工程时直接在 Visual Studio 里选择 WDK 的 NDIS Miniport Driver 模板编译器会帮你链接 NDIS 库也自动带上 NDIS 6.x 的版本宏。如果你的 WDK 版本较新但模板没更新注意把项目属性里的NDIS_VERSION设成0x0600以上否则会用旧的 NDIS 5.x 接口编译后面一堆 API 对不上。DriverEntry 的核心工作只有一件填一个NDIS_MINIPORT_DRIVER_CHARACTERISTICS结构体交给 NDIS 注册。这类注册代码基本是固定套路下面这段是我常用的骨架// DriverEntry.cpp #include ntddk.h #include ndis.h NDIS_HANDLE g_NdisDriverHandle NULL; NTSTATUS DriverEntry( _In_ PDRIVER_OBJECT DriverObject, _In_ PUNICODE_STRING RegistryPath) { NDIS_MINIPORT_DRIVER_CHARACTERISTICS Chars; NDIS_STATUS status; NdisZeroMemory(Chars, sizeof(Chars)); Chars.Header.Type NDIS_OBJECT_TYPE_MINIPORT_DRIVER; Chars.Header.Size NDIS_SIZEOF_MINIPORT_DRIVER_CHARACTERISTICS_REVISION_2; Chars.Header.Revision NDIS_MINIPORT_DRIVER_CHARACTERISTICS_REVISION_2; Chars.InitializeHandler MiniportInitializeEx; Chars.HaltHandler MiniportHaltEx; Chars.ShutdownHandler MiniportShutdown; Chars.OidRequestHandler MiniportOidRequest; Chars.SendNetBufferListsHandler MiniportSendNetBufferLists; Chars.ReturnNetBufferListsHandler MiniportReturnNetBufferLists; Chars.CancelSendHandler MiniportCancelSend; Chars.CheckForHangHandlerEx MiniportCheckForHangEx; Chars.ResetHandlerEx MiniportResetEx; Chars.DevicePnPEventNotifyHandler MiniportDevicePnPEventNotify; Chars.UnloadHandler MiniportUnload; status NdisMRegisterMiniportDriver( DriverObject, RegistryPath, Chars, NULL, // MiniportDriverHandle使用默认行为 g_NdisDriverHandle); if (status ! NDIS_STATUS_SUCCESS) { return status; } return STATUS_SUCCESS; }注册只把驱动对象的回调表给 NDIS真正的设备资源初始化要等 PnP 后续触发MiniportInitializeEx。注意Chars.Header.Size必须和 Revision 匹配填小了 NDIS 直接拒绝注册。这个字段是最容易被忽略的新手经常只填 Type 就把结构体传进去结果NdisMRegisterMiniportDriver返回NDIS_STATUS_BAD_VERSION。2.3 MiniportInitializeEx 里该做什么当系统检测到网卡设备时NDIS 调用你的MiniportInitializeEx。这是驱动里第一个真正跟硬件打交道的函数。我习惯按这个顺序处理先分配适配器上下文再读注册表参数然后映射 PCIe BAR、配置 DMA最后注册适配器并设置中断。NDIS_STATUS MiniportInitializeEx( NDIS_HANDLE NdisAdapterHandle, NDIS_HANDLE MiniportDriverContext, PNDIS_MINIPORT_INIT_PARAMETERS MiniportInitParameters) { PADAPTER pAdapter NULL; NDIS_STATUS status NDIS_STATUS_SUCCESS; // 1. 分配适配器上下文必须放在第一步 pAdapter (PADAPTER)ExAllocatePoolWithTag( NonPagedPoolNx, sizeof(ADAPTER), ptam); if (pAdapter NULL) { return NDIS_STATUS_RESOURCES; } NdisZeroMemory(pAdapter, sizeof(ADAPTER)); pAdapter-NdisAdapterHandle NdisAdapterHandle; pAdapter-State ADAPTER_STATE_INITIALIZING; // 2. 从注册表读取参数环形队列大小、MSI-X 向量数等 status ReadAdapterParameters(pAdapter, MiniportInitParameters); if (status ! NDIS_STATUS_SUCCESS) { goto cleanup; } // 3. 扫描 PCIe Capability映射 BAR 寄存器 status MapHardwareResources(pAdapter); if (status ! NDIS_STATUS_SUCCESS) { goto cleanup; } // 4. 正式注册适配器之后 NDIS 才会把 OID 和收发回调派发下来 status NdisMRegisterMiniportAdapter( NdisAdapterHandle, pAdapter, pAdapter-NdisMiniportHandle, NDIS_SIZEOF_MINIPORT_ADAPTER_REVISION_1); if (status ! NDIS_STATUS_SUCCESS) { goto cleanup; } // 5. 先注册硬件中断再打开接收队列 status ConfigureInterrupt(pAdapter); if (status ! NDIS_STATUS_SUCCESS) { goto cleanup; } // 6. 上报能力集线速、MTU、校验和卸载等 SetAdapterCapabilities(pAdapter); return NDIS_STATUS_SUCCESS; cleanup: if (pAdapter-NdisMiniportHandle ! NULL) { NdisMDeregisterMiniportAdapter(pAdapter-NdisMiniportHandle); } // 释放 BAR 映射和适配器内存 FreeAdapterResources(pAdapter); ExFreePoolWithTag(pAdapter, ptam); return status; }这个函数里的顺序是长期实践的总结先分配内存是因为后面任何一步失败都要走清理逻辑如果一开始没分配好清理路径会解引用空指针。MapHardwareResources里用MmMapIoSpace映射 BAR记得在 cleanup 里调用MmUnmapIoSpace把映射释放掉否则驱动重装时会内存泄漏。NdisMRegisterMiniportAdapter必须在中断配置之前做因为中断描述符要挂在适配器上下文上。我在这个阶段踩过最狠的坑是 PCIe 多功能设备的 BAR 映射同一颗芯片上既有以太网控制器又有 USB 控制器PCIe 配置空间里 BAR0 是控制器的BAR2 才是网卡的。如果只按 BAR0 去读 MAC 寄存器初始化不报错但因为控制逻辑完全不对收发路径在一个小时后随机挂掉。建议初始化时就把所有 BAR 的类型打印出来确认哪一块是网卡寄存器空间再往里写。3. 收发数据路径NBL 的所有权和 OID 请求处理方式3.1 先理解 NET_BUFFER_LIST 这一层抽象NDIS 6 的收发单元是NET_BUFFER_LIST简称 NBL。一个 NBL 指向一个或多个NET_BUFFER每个NET_BUFFER又挂着一串 MDL。对驱动的发路径而言协议栈把组装好的 NBL 链表丢进你的MiniportSendNetBufferLists对收路径来说你在 DPC 里把硬件的 DMA 缓冲填好再通过NdisMIndicateReceiveNetBufferLists把数据交给 NDIS。你不需要关心 MDL 里的虚拟地址是否连续只要用NdisGetDataBuffer或直接操作 MDL 把数据搬到 DMA 描述符指向的物理地址。收发路径最关键的一条规则是所有权切换。发送时NBL 从协议驱动转交给你你在把数据完全交给硬件之前有责任保存这些 NBL 的引用等你从 Tx 中断里确认硬件发送完成调用NdisMSendNetBufferListsComplete把 NBL 还给上层此时你不能再碰它。很多人第一次写驱动时在这个交接上翻车最常见的表现是发送完成中断后还去读 NBL 的状态字段然后蓝屏。3.2 发送MiniportSendNetBufferLists 实现要点发送回调可以是异步的也就是说函数返回后 NBL 还没发完也没关系只要你已经通过NdisMSendNetBufferListsComplete通知 NDIS 完成时间并且确保同一 NBL 最终只 complete 一次。下面是一个带 pending 队列的发送处理范例VOID MiniportSendNetBufferLists( NDIS_HANDLE MiniportAdapterContext, PNET_BUFFER_LIST NetBufferLists, NDIS_PORT_NUMBER PortNumber, ULONG SendFlags) { PADAPTER pAdapter (PADAPTER)MiniportAdapterContext; PNET_BUFFER_LIST nbl NetBufferLists; PNET_BUFFER_LIST next; // 遍历协议栈传进来的 NBL 链表 while (nbl ! NULL) { next NET_BUFFER_LIST_NEXT_NBL(nbl); NET_BUFFER_LIST_NEXT_NBL(nbl) NULL; // 适配器已暂停掉电或重置中直接归还 NBL if (pAdapter-State ADAPTER_STATE_PAUSED) { nbl-Status NDIS_STATUS_PAUSED; NdisMSendNetBufferListsComplete( pAdapter-NdisMiniportHandle, nbl, NDIS_SEND_FLAGS_DISPATCH_LEVEL); nbl next; continue; } // 队列已满放入 pending 队列等待下发 if (GetFreeTxDescriptorCount(pAdapter) 0) { nbl-Status NDIS_STATUS_PENDING; EnqueuePendingNbl(pAdapter, nbl); nbl next; continue; } // 映射到硬件描述符返回成功表示硬件接管 if (MapNblToTxRing(pAdapter, nbl) FALSE) { nbl-Status NDIS_STATUS_FAILURE; NdisMSendNetBufferListsComplete( pAdapter-NdisMiniportHandle, nbl, NDIS_SEND_FLAGS_DISPATCH_LEVEL); } // MapNblToTxRing 成功时NBL 由 Tx 完成中断负责 complete nbl next; } }这段代码要解决两个问题一是暂停状态下不能进发送队列否则后面重启时 NBL 链会断二是硬件 ring 满时不能直接丢包应该挂进驱动自己的 pending 队列等 Tx 中断清出空闲描述符时再补发。NDIS_STATUS_PENDING不是错误它表示数据还没完成NDIS 不会帮你释放这个 NBL你自己要在后续补 complete。我在实现发送时反复提醒自己的原则回调返回前、函数里任何一条分支都要保证 NBL 要么已经被 complete要么还在驱动可控制的队列里。没有什么“我先看看能不能发发不出去就不管了”的操作。3.3 接收中断到 DPC再到 NdisMIndicateReceiveNetBufferLists以太网卡在收到包后会触发中断。NDIS 小端口驱动的标准做法是在MiniportInterrupt里只做状态读取和中断判定实际的数据搬运放到 DPC 中。原因很简单中断回调运行在高 IRQL不能调用 NDIS/RDBSS 之类的分页代码也不能做耗时的 DMA 清理。你的中断回调先识别中断源然后用NdisMQueueDpc排队。BOOLEAN MiniportInterrupt( NDIS_HANDLE MiniportAdapterContext, VOID *InterruptContext, PULONG InterruptStatus) { PADAPTER pAdapter (PADAPTER)MiniportAdapterContext; // 读中断状态寄存器立即清掉硬件中断 pending ULONG statusReg READ_REGISTER_ULONG(pAdapter-Regs-IntStatus); WRITE_REGISTER_ULONG(pAdapter-Regs-IntMask, DISTRIBUTION_MASK); *InterruptStatus 0; // 按中断位分别触发 DPC而不是在中断里直接处理 if (statusReg INT_RX_DONE) { *InterruptStatus | NDIS_INTERRUPT_RECEIVE; NdisMQueueDpc(pAdapter-NdisMiniportHandle, INT_RX_DONE, NULL, NULL); } if (statusReg INT_TX_DONE) { *InterruptStatus | NDIS_INTERRUPT_SEND; NdisMQueueDpc(pAdapter-NdisMiniportHandle, INT_TX_DONE, NULL, NULL); } if (statusReg INT_LINK_CHANGE) { *InterruptStatus | NDIS_INTERRUPT_LINK_CHANGE; NdisMQueueDpc(pAdapter-NdisMiniportHandle, INT_LINK_CHANGE, NULL, NULL); } return TRUE; }INT 状态寄存器的清零要趁早有些控制器不读状态就不会清中断晚一点清会导致相同中断反复触发。使用 MSI-X 时每个 vector 有独立的中断处理函数不用再靠读一个共享状态寄存器去分拣但 DPC 分配策略要按队列数提前规划。到 DPC 里的接收逻辑就顺了先从 ring 中取出已完成 DMA 的描述符把上层可以送走的NET_BUFFER填好最后调用NdisMIndicateReceiveNetBufferLists。这里一个常见建议是把多个描述符聚合到一个 NBL 里返回减少 NDIS 层的函数调用次数小包多的情况下吞吐差距很明显。接收到的 nbl 需要时用NdisMIndicateReceiveNetBufferLists传入NDIS_RECEIVE_FLAGS_DISPATCH_LEVEL标志DPC 里这个标志必须带否则 NDIS 会认为你在低 IRQL调度逻辑会产生额外开销甚至引发断言。3.4 OID 请求查询和设置的同步与异步OIDObject Identifier是上层请求驱动的命令通道。协议栈和用户态的ipconfig、netsh都会通过 OID 来读网卡信息或设置参数。实现MiniportOidRequest时最简单的做法是所有 OID 同步完成即函数返回时就给出最终状态。但不是所有 OID 都能同步比如设置 RSS 密钥时要重置接收队列硬件需要几十微秒这时候直接同步返回没问题但某些网卡的重置动作要做几十毫秒在 DPC 级别的调用上下文里同步等待就可能死锁所以需要抛出NDIS_STATUS_PENDING之后在独立线程里完成请求再调用NdisMOidRequestComplete。NDIS_STATUS MiniportOidRequest( NDIS_HANDLE MiniportAdapterContext, PNDIS_OID_REQUEST NdisRequest) { PADAPTER pAdapter (PADAPTER)MiniportAdapterContext; switch (NdisRequest-RequestType) { case NdisRequestQueryInformation: return MiniportQueryInformation(pAdapter, NdisRequest); case NdisRequestSetInformation: return MiniportSetInformation(pAdapter, NdisRequest); default: return NDIS_STATUS_NOT_SUPPORTED; } } NDIS_STATUS MiniportQueryInformation( PADAPTER pAdapter, PNDIS_OID_REQUEST NdisRequest) { ULONG oid NdisRequest-DATA.QUERY_INFORMATION.Oid; PVOID buf NdisRequest-DATA.QUERY_INFORMATION.InformationBuffer; ULONG bufLen NdisRequest-DATA.QUERY_INFORMATION.InformationBufferLength; ULONG bytesWritten 0; switch (oid) { case OID_GEN_CURRENT_PACKET_FILTER: if (bufLen sizeof(ULONG)) { // 缓冲区太短必须先返回太短并给出需要的长度 NdisRequest-DATA.QUERY_INFORMATION.BytesNeeded sizeof(ULONG); return NDIS_STATUS_BUFFER_TOO_SHORT; } *(PULONG)buf pAdapter-PacketFilter; bytesWritten sizeof(ULONG); break; case OID_GEN_MEDIA_SUPPORTED: if (bufLen sizeof(ULONG)) { NdisRequest-DATA.QUERY_INFORMATION.BytesNeeded sizeof(ULONG); return NDIS_STATUS_BUFFER_TOO_SHORT; } *(PULONG)buf NDIS_MEDIUM_802_3; bytesWritten sizeof(ULONG); break; default: return NDIS_STATUS_NOT_SUPPORTED; } NdisRequest-DATA.QUERY_INFORMATION.BytesWritten bytesWritten; return NDIS_STATUS_SUCCESS; }OID 处理中最容易被忽略的是BytesNeeded和BytesWritten这两个字段。如果缓冲长度不够返回NDIS_STATUS_BUFFER_TOO_SHORT时必须设置BytesNeeded上层会根据这个值重新分配更大的缓冲区。如果只是随手返回失败但不填长度Windows 自带的网络组件会认为查询失败有时会默默退回到默认配置导致网卡显示“已识别网络”但拿不到 IP。你排查到最后根本不知道是哪个 OID 在作怪建议在 WPP 日志里把每个 OID 和返回状态都打印出来这个习惯能省掉大量联调时间。4. 避坑现场NDIS 小端口驱动最常见的 5 个翻车点4.1 NBL 所有权混乱导致发送完成后被二次释放现象驱动在长时间大流量吞吐后蓝屏蓝屏代码指向ndis.sys或NETIO.SYS堆栈里能看到NdisMSendNetBufferListsComplete后续调用。原因发送路径中你在MiniportSendNetBufferLists里把一个 NBL 同时放进了 pending 队列又因为逻辑分支提前调用了NdisMSendNetBufferListsComplete。当下层完成中断再次 complete 同一个 NBL 时上层协议驱动还在等这个 buffer于是内存被释放两次可能当场崩溃也可能内存被破坏后几个小时后爆发。解决给每个 NBL 的发送状态用唯一的跟踪结构管理。我在ADAPTER里维护一张表以 NBL 地址做索引发送时先记录状态complete 后清掉索引每次 complete 前先查这张表发现已经 complete 过就直接报NDIS_STATUS_INTERNAL_ERROR并断掉发送链路。这样问题会第一时间暴露而不是让你远程翻日志猜半天。4.2 在 DPC 里等了自旋锁以外的任何锁现象网卡在中断风暴或大流量时表现为“打着打着就断流”!analyze看到 DPC 线程卡在某个KeAcquireSpinLock或KeWaitForSingleObject上。原因接收 DPC 的执行上下文是 DISPATCH_LEVEL在这层调用KeWaitForSingleObject等一个事件等于让当前 CPU 进入不可调度的等待。如果等待的事件又是发送完成中断补发的线程持有的就会形成 DPC 等待线程、线程等中断的死锁现场。解决DPC 里不能做的事情就搬到系统工作线程或直接用 NDIS 的NdisQueueIoWorkItem。我通常维护一个轻量级的“接收后处理”队列把需要复杂逻辑的帧缓存在驱动内部然后在工作线程里慢慢喂给上层。处理速度慢一点没关系但绝不会因为等待而让系统整个挂住。4.3 中断风暴没按电平触发规则处理现象安装驱动后 CPU 占用率飙到 90% 以上任务管理器里看到% DPC Time一直很高网络断断续续。原因很多 PCIe 以太网控制器支持 Legacy INTx这玩意是电平触发。中断处理后如果还有优先级更高的中断源挂在同样的物理中线上你必须一次性处理完再写中断结束寄存器否则硬件会认为中断没被吃掉反复进入同一个中断服务程序就成风暴了。边沿触发的 MSI-X 就没这问题但旧平台不一定开了 MSI-X。解决驱动在初始化时优先尝试启用 MSI-X。若回退到 INTx每次在MiniportInterrupt里把该硬件支持的所有中断源状态都检查一遍处理完所有 pending 事件后再清状态。不要只检查一个源就返回 TRUE如果该源和另一个源共享物理中断向量另一个源的 pending 会导致风暴。另外检查pAdapter-InterruptStatus是否全部清空后再触发 DPC否则把 DPC 排进队也没用。4.4 OID 查询从不检查缓冲区大小导致上层能力识别错乱现象网卡驱动安装后系统“网络和共享中心”显示识别为“未识别的网络”Get-NetAdapter里速度和 MAC 都是空。用 NDISTest 跑基础查询也是大片失败。原因OID_GEN_VENDOR_DESCRIPTION、OID_802_3_CURRENT_ADDRESS这类 OID 查询通常要求缓冲区至少是结构体大小。你图省事直接把状态寄存器里的数据写到InformationBuffer而 NDIS 因为缓冲长度不足在NdisMOidRequestComplete时直接丢弃了数据但驱动没有返回BUFFER_TOO_SHORT上层按失败处理。这不是崩溃级错误但会让系统对网卡能力判断失败IP 分配等联动功能全部失效。解决在MiniportQueryInformation里对每个 OID 先判断InformationBufferLength是否满足结构体要求不满足就填BytesNeeded并返回NDIS_STATUS_BUFFER_TOO_SHORT。绝对不能出现“缓冲区不够但还往里面写”的情况哪怕你只是写一个字节都可能越界破坏 NDIS 内部内存。4.5 适配器暂停和重启时没拦住收发路径现象拔掉网线或执行禁用操作时驱动不蓝屏但重新插上网线后网卡无法恢复停止响应需要重启电脑。系统日志里能看到NDIS警告“miniport did not pause correctly”。原因MiniportPause回调执行时NDIS 会等待驱动停止上报接收数据和发送队列。如果你的发送回调在收到ADAPTER_STATE_PAUSING后没有把新的发送请求主动 complete或没有停止接收指示DMA 还在继续跑NDIS 的暂停协调等待超时整个适配器进入不健康状态。解决用适配器状态机统一收口。我在MiniportInitializeEx后把状态设为RUNNINGMiniportPause里立即把状态切成PAUSING并在所有发送路径的入口检查state ! RUNNING时直接 complete。接收 DPC 里也要判断状态如果是暂停中就不再上报新的 NBL而是把 NBL 归还给接收池。重新启动时只有等MiniportRestart回调发出之后才切回RUNNING避免 DMA 重新开启的瞬间收到旧数据。5. 验证与调试WPP 日志、Driver Verifier 与收发压测手段5.1 把 WPP 追踪接进 miniport调试网卡驱动最怕的是“用户说会断流但你的机器上怎么跑都不复现”。这时候光靠 DebugPrint 太粗加驱动里每行输出又影响性能。WPP 软件跟踪是 NDIS 驱动开发最常见的日志方案它在编译时把字符串格式做成了静态元数据运行时只在有追踪级别开启时才写日志开销比DebugPrint低得多可以留到 release 版本。要启用 WPP在工程里加一个 trace.h 头文件并用WPP_CONTROL_GUIDS定义 GUID 和事件位。然后在 DriverEntry 里调用WPP_INIT_TRACING(DriverObject, RegistryPath)卸载时调用WPP_CLEANUP。示例// trace.h #pragma once #define WPP_CONTROL_GUIDS \ WPP_DEFINE_CONTROL_GUID( \ MiniPortTraceGuid, \ (a75f1188, 8c82, 4d18, 9e46, 1d5d136a7cfc), \ WPP_DEFINE_BIT(TRACE_LEVEL_INIT) \ WPP_DEFINE_BIT(TRACE_LEVEL_IO) \ WPP_DEFINE_BIT(TRACE_LEVEL_OID) \ ) // 在任意 .cpp 里 #include trace.h // 编译时用 WPP 预处理器生成 // WPP_INIT_TRACING(DriverObject, RegistryPath);实际使用时我习惯为每个关键路径定义WPP_LEVEL_ENTER、WPP_LEVEL_VERBOSE之类的宏。比如发送路径的日志只在 TRACE_LEVEL_IO 开启时才输出OID 查询走 TRACE_LEVEL_OID。这样线上复现问题时让客户用tracelog.exe -start DriverTrace -guid #xxxxxxxx开启指定 GUID 的跟踪再复现一次断流抓回的.etl文件里就能看到中断、NBL、OID 的完整时间线。比起嘴对嘴问客户“你刚才做了什么操作”这种日志是唯一可靠的调试手段。5.2 Driver Verifier让隐蔽状态错误提前炸出来Windows 的 Driver Verifier 对 NDIS 驱动特别有价值它能在以下场景强制失败错误的 IRQL 调用、内存池越界、DMA 描述符错误、还有 NBL 泄漏。对网卡驱动如果你在发送路径上漏了NdisMSendNetBufferListsCompleteVerifier 会在驱动卸载时直接报DRIVER_LEFT_PENDING_IRPS之类的错误快速暴露问题。常见做法是用verifier /standard /driver myndis.sys开启标准验证然后重启。如果你的驱动要从远程调试先把内核调试器接好再开 Verifier因为被验证的驱动一旦出问题会立刻中断没有调试器就只能靠重启后的 bugcheck 转储去分析效率差很多。Verifier 的最大代价是性能明显下降所以只在自测阶段开做长稳测试时关掉。5.3 用 pktmon 和压测脚本确认实际吞吐驱动写完不能只在断点里看寄存器要从系统层面确认包真的从网卡进来了。Windows 自带 pktmon 可以在 NDIS 层抓包验证数据路径是否完整。配合ping -f -l 1400 -n 10000之类的内网压测命令能快速判断驱动收包是否掉包。注意确认驱动安装后网卡是“已启用”状态并且链路速率显示正确。# 查看当前网卡状态和速率 Get-NetAdapter | Format-Table Name, InterfaceDescription, Status, LinkSpeed # 用 pktmon 抓 NDIS 层流量抓完停止生成 etl pktmon start --etw -c -m real-time # 复现压测 ping -f -l 1400 -n 10000 192.168.1.1 # 停止并解析 pktmon stop pktmon etl2txt --in PktMon.etl --out PktMon.txt注意 pktmon 抓的是系统 NDIS 路径不是网卡硬件内部。如果 pktmon 里看不到任何包说明驱动根本没把 NBL 上报如果能看到但用户态还是丢包问题大概率在上层协议栈或应用不在 miniport。这个区分能帮你砍掉一半的排查方向。另外ping 的内网网关地址一定在本地测试网段内不要拿公网地址做高并发压测结果受反病毒软件和路由环境影响很难定位驱动层问题。6. 从能跑到好用RSS 队列与硬件卸载的进阶配置驱动稳定跑通基本收发后下一步是让它在多核服务器上不成为瓶颈。最简单有效的一步是开启 RSSReceive Side Scaling。RSS 让网卡按四元组哈希把收到的连接分散到多个 CPU 队列避免所有中断和 DPC 都挤在同一个核上。配置点有两个一是MiniportInitializeEx里用NDIS_RECEIVE_SCALE_CAPABILITIES上报队列数和哈希类型二是在设置 OID_GEN_RECEIVE_SCALE_CAPABILITIES 时正确填写哈希密钥并下发到硬件。很多国产网卡驱动只做了单队列一旦跑到几百 Mbps 就出现单核 DPC 打满的现象开启 RSS 后多核分摊同样的一颗 CPU 往往能多跑出 30% 到 50% 的吞吐。硬件校验和卸载Checksum Offload和 Large Send OffloadLSO也是跑满带宽的关键。当一个 64KB 的上层大包需要被拆成 42 个 1500B 的帧时CPU 平均每包要处理几十次校验计算和分片逻辑。硬件把这些做了驱动要做的只是调用NdisSetOffloadCapabilities上报能力然后在发送路径里忽略上层已经设置好的 Checksum 字段。但这里有个边界不是所有包都适合硬件分片比如带安全协议的小包如果也被硬件接管反而会增加中断次数。我一般用注册表项控制默认 offload 开关内网大包场景全开转发设备场景只开 RSS 不开 LSO这样用户可以在不换驱动的情况下按部署环境调整。最后提一个验证技巧开启 RSS 后不要只看任务管理器的 CPU 总量要看Get-NetAdapterRss显示的当前处理器列表是否覆盖了你期望的核数以及用Get-NetAdapterStatistics看各个队列的接收计数器是否接近均衡。我自己写过一版驱动RSS 哈希函数一直返回同一个队列吞吐数据却看起来正常直到看队列计数器才发现 CPU0 占满了其他核闲着。后来为每个队列单独记录接收字节数才在自测脚本里第一个暴露问题。好的驱动不是调完参数就完事而是给自己留一双能看到内部状态的“眼睛”——WPP 日志、队列计数器、Verifier这几样配合好了后续维护和换硬件平台适配都会省心很多。希望帮到你。本文还有配套的精品资源点击获取