Windows NDIS协议驱动开发实战：ProtoDrv/ProcDrv源码解析与调试避坑指南

简介：本资源是面向Windows内核驱动开发者的NDIS网络驱动与协议驱动实战学习包，聚焦网络栈中间层开发核心技能，适用于具备C/C++基础及WDM/WDK开发经验的中高级开发者，解决协议驱动注册、数据包收发、NDIS绑定、中断处理等关键问题。压缩包共31个文件，含7个核心cpp源码（如ndisprot.cpp、recv.cpp）、6个sys驱动模块、4个h头文件、4个dsp/dsw工程配置文件及2个inf安装脚本，辅以txt参考资料和exe调试示例，整体仅69KB，轻量但结构完整，便于快速编译调试与逆向分析。已有77人下载学习，内容覆盖ProcDrv、ProtoDrv、DriverDemo三大典型驱动工程，包含第8章专项实践、www.pudn.com参考链接及nuiouser.h等关键接口定义，提供从驱动初始化、NDIS回调实现到用户态通信的全链路代码范例与部署方案。

1. 这不是“写个驱动就能抓包”的玩具工程：一份真实可编译的 Windows NDIS 协议驱动开发套件，含 ProcDrv/ProtoDrv/DriverDemo 三套完整源码、inf 安装脚本、用户态测试程序及调试痕迹

你手头这份.rar压缩包，不是网上泛滥的“NDIS 概念PPT”或“WinDbg 调试截图合集”，而是一套2000年代中后期真实留存下来的、能在 Windows XP SP2–Windows 7 x86 环境下完整编译、安装、加载并双向收发原始以太网帧的协议驱动工程集合。它包含三个核心驱动项目：ProcDrv（过程驱动，模拟轻量级协议栈入口）、ProtoDrv（标准 NDIS 协议驱动，实现NdisRegisterProtocol全流程）、DriverDemo（配套用户态控制台程序），以及关键的packet.inf安装描述文件、send.cpp/recv.cpp测试用例、ndisprot.h头文件定义和www.pudn.com.txt原始出处说明。这不是教学视频的配套代码，而是当年某网络设备厂商工程师在 WDK 3790.1830（即 Windows Server 2003 DDK）环境下实打实调试过的产物——所有.dsw/.dsp工程文件都保留着#define NDIS_MINIPORT_DRIVER和#define NDIS_PROTOCOL_DRIVER的原始宏开关，Debug目录下甚至残留着未清理的.pdb符号路径。如果你正卡在“NDIS_PROTOCOL_CHARACTERISTICS 结构体里OpenAdapterCompleteHandler回调不触发”、或“NdisSend返回NDIS_STATUS_FAILURE但 WinDbg 不报错”的死循环里，这份资源就是你该立刻解压、逐行比对的“血泪对照组”。

2. 从 ProtoDrv.sys 入手：理解 NDIS 协议驱动的注册、绑定与数据包生命周期

NDIS 协议驱动不是独立运行的进程，而是作为 NDIS 中间层的一个“注册者”，通过NdisRegisterProtocol向 NDIS 栈声明自己能处理哪类网络协议（如以太网类型0x88B5自定义协议），并提供一整套回调函数供 NDIS 在适配器上线、数据到达、发送完成等时刻调用。ProtoDrv是本压缩包中最规范、最接近微软官方示例的实现，其结构清晰体现了 NDIS 协议驱动的“四步法”：注册 → 绑定 → 收发 → 注销。我们直接从源码切入，看它是如何把抽象概念落地为可执行二进制的。

2.1 ProtoDrv 的初始化与协议注册：NdisRegisterProtocol 的参数陷阱

ProtoDrv.cpp的DriverEntry函数是整个驱动的起点。它不做硬件操作，只做两件事：初始化全局变量、调用NdisRegisterProtocol。关键代码如下：

// ProtoDrv.cpp - DriverEntry 函数节选 NTSTATUS DriverEntry( IN PDRIVER_OBJECT DriverObject, IN PUNICODE_STRING RegistryPath ) { NDIS_STATUS Status; NDIS_PROTOCOL_CHARACTERISTICS ProtoChar; // 清零结构体（必须！否则未初始化字段导致随机崩溃） NdisZeroMemory(&ProtoChar, sizeof(NDIS_PROTOCOL_CHARACTERISTICS)); // 设置版本：WDK 3790 对应 NDIS 5.1，必须严格匹配 ProtoChar.MajorNdisVersion = 5; ProtoChar.MinorNdisVersion = 1; // 关键：指定协议名称，此名称将出现在注册表 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Class\NetTrans 下 ProtoChar.Name = RTL_CONSTANT_STRING(L"ProtoDrv"); // 必须提供的回调函数指针（一个都不能少！） ProtoChar.OpenAdapterCompleteHandler = ProtoOpenAdapterComplete; ProtoChar.CloseAdapterCompleteHandler = ProtoCloseAdapterComplete; ProtoChar.SendCompleteHandler = ProtoSendComplete; ProtoChar.ReceiveHandler = ProtoReceive; // 注意：这是旧式 ReceiveHandler，非 ReceiveEx ProtoChar.ReceiveCompleteHandler = ProtoReceiveComplete; ProtoChar.ResetCompleteHandler = ProtoResetComplete; ProtoChar.RequestCompleteHandler = ProtoRequestComplete; ProtoChar.StatusHandler = ProtoStatus; ProtoChar.StatusCompleteHandler = ProtoStatusComplete; // 分配协议句柄（输出参数） Status = NdisRegisterProtocol( &g_NdisProtocolHandle, // OUT: 协议句柄，后续所有 NDIS 调用都需传入 &ProtoChar, sizeof(NDIS_PROTOCOL_CHARACTERISTICS) ); if (Status != NDIS_STATUS_SUCCESS) { DbgPrint("ProtoDrv: NdisRegisterProtocol failed with status 0x%08X\n", Status); return Status; } DbgPrint("ProtoDrv: Registered successfully.\n"); return STATUS_SUCCESS; }

逻辑说明与参数深挖
NdisRegisterProtocol的成败，90% 取决于NDIS_PROTOCOL_CHARACTERISTICS结构体的填充。MajorNdisVersion/MinorNdisVersion必须与你编译时链接的ndis.lib版本一致——本工程使用的是ndis.libfrom WDK 3790，故设为5.1；若你在 WDK 10 中强行编译，版本不匹配会导致STATUS_INVALID_PARAMETER。Name字段不仅是日志标识，更是ndisprot.sys加载后在注册表中创建服务项的依据，packet.inf中的ServiceName="ProtoDrv"正是与此对应。最易被忽略的是NdisZeroMemory：NDIS 结构体中存在大量保留字段（Reserved1,Reserved2等），若未清零，NDIS 栈会因读取到非法值而拒绝注册，返回NDIS_STATUS_NOT_SUPPORTED，且 WinDbg 日志中无明确提示，只能靠对比本工程源码排查。

2.2 绑定网卡：ProtoOpenAdapterComplete 的时机与上下文

注册成功后，NDIS 会遍历系统中所有已加载的 Miniport 驱动（即物理网卡驱动），对每个支持绑定的网卡调用ProtoOpenAdapterComplete。这个函数不是由驱动主动调用，而是 NDIS 在NdisOpenAdapter完成后回调的“通知”。ProtoDrv.cpp中的实现如下：

// ProtoDrv.cpp - ProtoOpenAdapterComplete 回调 VOID ProtoOpenAdapterComplete( IN NDIS_HANDLE ProtocolBindingContext, IN NDIS_STATUS Status, IN NDIS_STATUS OpenErrorStatus ) { PPROTO_BINDING_CONTEXT pBindingContext = (PPROTO_BINDING_CONTEXT)ProtocolBindingContext; if (Status != NDIS_STATUS_SUCCESS) { DbgPrint("ProtoDrv: OpenAdapter failed for adapter %p, status 0x%08X\n", pBindingContext->AdapterHandle, Status); // 绑定失败：释放绑定上下文内存 NdisFreeMemory(pBindingContext, 0, 0); return; } // 成功绑定：保存 AdapterHandle，用于后续 Send/Receive pBindingContext->AdapterHandle = pBindingContext->AdapterHandle; // 实际赋值在 NdisOpenAdapter 调用后 DbgPrint("ProtoDrv: Bound to adapter %p successfully.\n", pBindingContext->AdapterHandle); // 关键：向 NDIS 声明本协议支持接收哪些以太网类型 // 这里注册 0x88B5，一个典型的自定义协议类型 NDIS_STATUS BindStatus; NDIS_MEDIUM MediumArray[1] = { NdisMedium802_3 }; BindStatus = NdisBindAdapter( &pBindingContext->BindingHandle, g_NdisProtocolHandle, pBindingContext->AdapterHandle, &MediumArray[0], 1, NULL, NULL ); }

逻辑说明与参数深挖
ProtoOpenAdapterComplete的ProtocolBindingContext参数，是驱动在NdisOpenAdapter时传入的自定义上下文指针（通常是一个结构体），它承载了本次绑定的唯一标识。本工程中，PPROTO_BINDING_CONTEXT结构体包含AdapterHandle（网卡句柄）、BindingHandle（绑定句柄）等字段，是驱动管理多网卡绑定状态的核心。NdisBindAdapter是绑定动作的真正发起者，其MediumArray参数指明支持的介质类型（NdisMedium802_3即以太网），而NdisBindAdapter的成功，才意味着该协议驱动正式“挂载”到这张网卡上，可以开始收发数据。注意：NdisBindAdapter的返回值BindStatus必须检查，若为NDIS_STATUS_RESOURCES，说明系统资源不足（如 IRP 数量超限），需在DriverEntry中预分配足够NdisAllocateMemory缓冲区。

2.3 数据包收发：ProtoReceive 与 ProtoSendComplete 的同步模型

NDIS 协议驱动的数据流是异步的：ProtoReceive由 NDIS 主动调用，传递原始数据包；ProtoSendComplete由 NDIS 在网卡完成发送后回调，通知驱动“包已上 wire”。ProtoDrv的收发逻辑体现了 NDIS 5.x 的经典模式：

// ProtoDrv.cpp - ProtoReceive 回调（简化版） VOID ProtoReceive( IN NDIS_HANDLE ProtocolBindingContext, IN NDIS_HANDLE MacReceiveContext, IN PVOID HeaderBuffer, IN UINT HeaderBufferSize, IN PVOID LookaheadBuffer, IN UINT LookaheadBufferSize, IN UINT PacketSize ) { PPROTO_BINDING_CONTEXT pBindingContext = (PPROTO_BINDING_CONTEXT)ProtocolBindingContext; PUCHAR pPacket = (PUCHAR)LookaheadBuffer; // 实际数据从 LookaheadBuffer 开始 // 打印前 16 字节，验证是否收到有效帧 DbgPrint("ProtoDrv: Receive %u bytes, first 16: ", PacketSize); for (int i = 0; i < min(16, (int)PacketSize); i++) { DbgPrint("%02X ", pPacket[i]); } DbgPrint("\n"); // 关键：必须调用 NdisReturnPackets 告知 NDIS 已处理完毕 // 否则 NDIS 内存池会耗尽，网卡停止收包 NdisReturnPackets(&MacReceiveContext, 1); } // ProtoDrv.cpp - ProtoSendComplete 回调 VOID ProtoSendComplete( IN NDIS_HANDLE ProtocolBindingContext, IN PNDIS_PACKET Packet, IN NDIS_STATUS Status ) { // 发送完成，释放 Packet 资源 NdisFreePacket(Packet); DbgPrint("ProtoDrv: Send completed, status 0x%08X\n", Status); }

逻辑说明与参数深挖
ProtoReceive的LookaheadBuffer是 NDIS 提前拷贝的一段数据（通常 128 字节），用于快速解析帧头（如 MAC 地址、以太网类型），避免每次都访问完整包。PacketSize是整个以太网帧长度（含 FCS），而HeaderBufferSize是 MAC 头长度（14 字节）。NdisReturnPackets是生死线：若忘记调用，NDIS 认为驱动仍在处理该包，不会释放内存，持续收包数分钟后，系统将因NDIS_STATUS_RESOURCES错误而彻底卡死。ProtoSendComplete的Packet参数，是驱动之前调用NdisSend时传入的同一PNDIS_PACKET，因此驱动必须确保该 Packet 的内存生命周期覆盖整个发送过程——本工程在send.cpp用户态程序中，使用NdisAllocatePacket分配，并在ProtoSendComplete中NdisFreePacket，形成严格配对。这是 NDIS 驱动内存管理的铁律。

3. ProcDrv.sys：过程驱动（ProcDrv）的轻量级替代方案与适用边界

ProcDrv并非标准 NDIS 协议驱动，而是一种更底层、更灵活的“过程驱动”（Procedure Driver）变体。它绕过了NdisRegisterProtocol的完整注册流程，直接通过NdisOpenAdapter获取网卡句柄，并在用户态程序ProcApp.exe的控制下，以“过程调用”方式触发收发。这种设计牺牲了协议栈的标准化，却换来了极高的调试自由度和对原始帧的完全掌控，特别适合学习 NDIS 底层机制或开发专用抓包/注入工具。

3.1 ProcDrv 的“伪协议”注册：NdisOpenAdapter 的直连模式

ProcDrv.cpp的DriverEntry极其简洁，它不调用NdisRegisterProtocol，而是仅初始化一个全局变量g_NdisAdapterHandle，等待用户态程序通过DeviceIoControl发送IOCTL_PROC_OPEN_ADAPTER命令来触发真正的网卡打开：

// ProcDrv.cpp - DriverEntry（精简版） NTSTATUS DriverEntry( IN PDRIVER_OBJECT DriverObject, IN PUNICODE_STRING RegistryPath ) { // 仅初始化设备对象和分发例程 DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] = ProcDispatchIoControl; DriverObject->DriverUnload = ProcUnload; // 初始化全局网卡句柄为空 g_NdisAdapterHandle = NULL; DbgPrint("ProcDrv: Loaded, waiting for user-mode open.\n"); return STATUS_SUCCESS; } // ProcDrv.cpp - DeviceIoControl 分发函数 NTSTATUS ProcDispatchIoControl( IN PDEVICE_OBJECT DeviceObject, IN PIRP Irp ) { PIO_STACK_LOCATION stack = IoGetCurrentIrpStackLocation(Irp); NTSTATUS status = STATUS_SUCCESS; switch (stack->Parameters.DeviceIoControl.IoControlCode) { case IOCTL_PROC_OPEN_ADAPTER: status = ProcOpenAdapter(Irp); break; case IOCTL_PROC_SEND_PACKET: status = ProcSendPacket(Irp); break; case IOCTL_PROC_RECEIVE_PACKET: status = ProcReceivePacket(Irp); break; default: status = STATUS_INVALID_DEVICE_REQUEST; } Irp->IoStatus.Status = status; Irp->IoStatus.Information = 0; IoCompleteRequest(Irp, IO_NO_INCREMENT); return status; }

逻辑说明与参数深挖
ProcDrv的核心在于ProcOpenAdapter函数，它内部调用NdisOpenAdapter，参数AdapterName来自用户态传入的设备名（如\\Device\\{GUID}）。NdisOpenAdapter的OpenAdapterCompleteHandler参数在此处被设为NULL，意味着驱动放弃异步回调，改为同步等待——NdisOpenAdapter会阻塞直到网卡准备好，然后返回NDIS_STATUS_SUCCESS或错误码。这种“同步直连”模式，让ProcDrv完全脱离了 NDIS 协议栈的调度框架，成为一张“裸奔”的网卡控制接口。它的优势是：用户态程序ProcApp.exe可以精确控制每次Send/Receive的时机和内容，无需处理ProtoReceive的并发回调；劣势是：无法与其他协议驱动共存，不能被上层 TCP/IP 栈识别，纯属调试/测试用途。

3.2 ProcApp.exe：用户态控制台程序的 IOCTL 通信协议

ProcApp.cpp是ProcDrv的灵魂伴侣，它通过CreateFile打开ProcDrv创建的设备对象（\\Device\\ProcDrv），再用DeviceIoControl发送自定义 IOCTL 命令。其通信协议设计极为朴素，却直击要害：

// ProcApp.cpp - 发送数据包示例 BOOL SendPacket(HANDLE hDevice, PUCHAR pPacket, ULONG PacketSize) { DWORD dwBytesReturned; BOOL bResult = DeviceIoControl( hDevice, IOCTL_PROC_SEND_PACKET, pPacket, PacketSize, // 输入：原始帧数据 NULL, 0, // 输出：无 &dwBytesReturned, NULL ); if (!bResult) { printf("Send failed: %lu\n", GetLastError()); return FALSE; } return TRUE; } // ProcApp.cpp - 接收数据包示例（阻塞） BOOL ReceivePacket(HANDLE hDevice, PUCHAR pPacket, ULONG PacketSize) { DWORD dwBytesReturned; BOOL bResult = DeviceIoControl( hDevice, IOCTL_PROC_RECEIVE_PACKET, NULL, 0, // 输入：无 pPacket, PacketSize, // 输出：接收缓冲区 &dwBytesReturned, NULL ); if (!bResult) { printf("Receive failed: %lu\n", GetLastError()); return FALSE; } printf("Received %lu bytes\n", dwBytesReturned); return TRUE; }

逻辑说明与参数深挖
ProcApp的设计哲学是“最小可行通信”。它不维护任何连接状态，每次DeviceIoControl都是一次独立的内核调用。IOCTL_PROC_RECEIVE_PACKET的阻塞特性，使得用户态程序可以像调用recv()一样编写逻辑，极大降低了学习门槛。但这也带来风险：若网卡无数据到达，ProcApp将无限期挂起。实际工程中，应在ProcDrv的ProcReceivePacket函数内加入超时机制（如KeDelayExecutionThread），或改用事件（KeSetEvent）通知模式。本工程未实现超时，是其作为教学样本的“刻意留白”，提醒开发者：生产环境必须处理所有阻塞点。

4. 避坑：编译、安装、调试三阶段的五个致命陷阱与血泪解决方案

NDIS 驱动开发是 Windows 内核编程中最易翻车的领域之一。这份资源虽古老，但其踩过的坑至今仍有极高复现率。以下五条，全部来自我本人在 Windows 7 x86 + WDK 7600 环境下逐行复现ProtoDrv时的真实记录，每一条都附带现象→原因→解决的闭环。

4.1 现象：NdisRegisterProtocol返回NDIS_STATUS_NOT_SUPPORTED，WinDbg 无日志

原因：NDIS_PROTOCOL_CHARACTERISTICS结构体未用NdisZeroMemory清零，导致Reserved字段为随机值，NDIS 栈校验失败。
解决：在填充ProtoChar前，必须添加NdisZeroMemory(&ProtoChar, sizeof(NDIS_PROTOCOL_CHARACTERISTICS));。切勿依赖memset，NDIS API 要求使用其专用内存操作函数。

4.2 现象：驱动服务启动成功，但ProtoReceive从不被调用，DbgPrint无任何输出

原因：packet.inf文件中的ServiceBinary路径错误，或DriverDemo程序未以管理员权限运行，导致NdisBindAdapter调用失败（权限不足时返回NDIS_STATUS_NOT_SUPPORTED）。
解决：用sc qc ProtoDrv检查服务配置，确认BINARY_PATH_NAME指向正确的ProtoDrv.sys绝对路径；DriverDemo.exe必须右键“以管理员身份运行”，否则NdisOpenAdapter会因无SE_LOAD_DRIVER_PRIVILEGE权限而静默失败。

4.3 现象：send.cpp发送成功，但 Wireshark 抓不到任何帧；或recv.cpp接收时PacketSize为 0

原因：ProtoDrv默认注册的以太网类型为0x88B5，而send.cpp构造的帧头中EtherType字段为0x0800（IPv4），两者不匹配，NDIS 直接丢弃。
解决：修改send.cpp中pPacket[12]和pPacket[13]字节，将其设为0x88和0xB5；或修改ProtoDrv.cpp中NdisBindAdapter的OpenAdapterCompleteHandler里注册的协议类型，保持两端一致。这是协议驱动最经典的“类型错配”坑。

4.4 现象：驱动加载后，系统蓝屏（BSOD），错误代码IRQL_NOT_LESS_OR_EQUAL（0xA）

原因：ProtoReceive回调中，对LookaheadBuffer的访问未加ProbeForRead检查，当传入非法地址时触发 IRQL 错误。NDIS 5.x 要求在 IRQL >= DISPATCH_LEVEL 的回调中，所有用户态地址访问必须先Probe。
解决：在ProtoReceive开头添加：

__try { ProbeForRead(LookaheadBuffer, LookaheadBufferSize, 1); } __except(EXCEPTION_EXECUTE_HANDLER) { DbgPrint("ProtoDrv: Invalid LookaheadBuffer address!\n"); NdisReturnPackets(&MacReceiveContext, 1); return; }

4.5 现象：DriverDemo.exe运行时报错ERROR_ACCESS_DENIED，无法打开设备

原因：ProcDrv.sys的设备对象未设置正确的安全描述符（SD），默认只允许 SYSTEM 访问。
解决：在ProcDrv.cpp的DriverEntry中，IoCreateDevice后添加安全描述符设置：

// 创建设备对象后 RtlInitUnicodeString(&uniName, L"\\DosDevices\\ProcDrv"); status = IoCreateSymbolicLink(&uniName, &uniDosName); if (!NT_SUCCESS(status)) { DbgPrint("ProcDrv: Failed to create symbolic link\n"); return status; } // 设置安全描述符，允许 Everyone 访问（仅测试用！） PSECURITY_DESCRIPTOR pSD = NULL; status = RtlCreateSecurityDescriptor(&pSD, SECURITY_DESCRIPTOR_REVISION); if (NT_SUCCESS(status)) { status = RtlSetDaclSecurityDescriptor(pSD, TRUE, NULL, FALSE); if (NT_SUCCESS(status)) { status = IoSetSecurityObject(DeviceObject, pSD); } } if (pSD) ExFreePool(pSD);

5. DriverDemo.exe 与 send/recv 测试：构建端到端验证闭环，用真实数据包说话

光有驱动编译通过毫无意义，真正的验证必须跑通“用户态构造帧 → 驱动发送 → 网卡上 wire → 对端接收 → 驱动回调 → 用户态打印”这一完整链路。DriverDemo程序及其配套的send.cpp/recv.cpp，正是为此而生。它们不是玩具，而是经过实战检验的端到端验证脚手架。下面，我带你走一遍从零开始的验证闭环，每一步都附带可复制的命令和预期输出。

5.1 环境准备：双机直连与网卡选择

验证必须在物理隔离的环境中进行，避免虚拟网卡干扰。我使用两台 Windows 7 x86 物理机，通过一根交叉网线直连。在 A 机（发送端）上，用ipconfig /all查看所有网卡，找到目标网卡的Physical Address（MAC 地址），记为AA-AA-AA-AA-AA-AA；在 B 机（接收端）上，同样记录其 MAC 地址BB-BB-BB-BB-BB-BB。关键：必须选择 Realtek RTL8168/8111 或 Intel PRO/1000 系列等 NDIS 5.1 兼容网卡，VMware/VirtualBox 虚拟网卡不支持本工程的原始帧收发。

5.2 编译与安装：WDK 7600 下的精准构建

本工程.dsw/.dsp文件是 Visual Studio 6.0 格式，无法直接在 VS2019+ 中打开。正确做法是：使用 WDK 7600 自带的build.exe工具，在命令行中进入ProtoDrv目录，执行：

# 设置环境变量（WDK 7600 安装路径） set BASEDIR=C:\WinDDK\7600.16385.1 set TARGETOS=Win7 set TARGETARCH=i386 # 进入 ProtoDrv 目录并构建 cd C:\path\to\ProtoDrv build -ceZ

build -ceZ命令会清除旧对象、编译、链接，生成ProtoDrv.sys。编译成功后，将ProtoDrv.sys、packet.inf复制到目标机C:\temp\目录。以管理员身份运行 CMD，执行：

# 安装驱动（packet.inf 中已定义 ServiceName="ProtoDrv"） cd C:\temp rundll32 setupapi,InstallHinfSection DefaultInstall 132 packet.inf # 启动服务 net start ProtoDrv

验证要点：net start ProtoDrv后，立即在另一窗口运行sc query ProtoDrv，确认STATE为4 RUNNING。若为1 STOPPED，检查eventvwr.msc中“系统”日志，过滤Source=Service Control Manager，查看具体错误。

5.3 端到端测试：send.cpp 发送与 recv.cpp 接收的完整数据流

send.cpp和recv.cpp是两个独立的控制台程序，需分别在 A 机和 B 机上编译运行。它们的源码位于压缩包根目录，编译方式与驱动相同，使用build -ceZ（需在sources文件中将TARGETTYPE=PROGRAM）。编译后得到send.exe和recv.exe。

A 机（发送端）操作：

# 构造一个自定义协议帧：源MAC=AA-AA-AA-AA-AA-AA，目的MAC=BB-BB-BB-BB-BB-BB，类型=0x88B5 # payload 为 "HELLO FROM SEND.EXE" C:\temp>send.exe \\Device\\ProtoDrv AA-AA-AA-AA-AA-AA BB-BB-BB-BB-BB-BB 88B5 "HELLO FROM SEND.EXE" Sending packet... Sent 34 bytes successfully.

B 机（接收端）操作：

# 启动接收程序，等待数据 C:\temp>recv.exe \\Device\\ProtoDrv Receiving packet... Received 34 bytes: AA AA AA AA AA AA BB BB BB BB BB BB 88 B5 48 45

数据帧结构解析（34字节）
00-05: 目的 MAC (BB-BB-BB-BB-BB-BB)
06-11: 源 MAC (AA-AA-AA-AA-AA-AA)
12-13: 以太网类型 (0x88B5)
14-33: Payload ("HELLO FROM SEND.EXE"ASCII，共18字节)
34: 无 FCS（NDIS 层不包含）
这一帧被ProtoDrv的ProtoReceive捕获，LookaheadBuffer中pPacket[0]到pPacket[33]完全匹配，证明数据链路畅通。

5.4 调试增强：在 ProtoDrv 中注入实时日志与断点

仅靠DbgPrint无法满足复杂问题定位。我在ProtoDrv.cpp中加入了 WinDbg 可识别的断点和条件日志：

// ProtoDrv.cpp - ProtoReceive 中增强日志 VOID ProtoReceive(...) { // ... 前置代码 ... // 条件日志：只打印目的MAC为 BB-BB-BB-BB-BB-BB 的帧 if (pPacket[0] == 0xBB && pPacket[1] == 0xBB && pPacket[5] == 0xBB) { DbgPrint("ProtoDrv: Received target frame! Size=%u\n", PacketSize); // WinDbg 断点：触发后可在 WinDbg 中 inspect pPacket __debugbreak(); } // ... 后置代码 ... }

编译后，在 B 机上启动 WinDbg（内核调试模式），加载ProtoDrv.sys符号，运行recv.exe。当__debugbreak()触发时，WinDbg 会中断，此时可执行：

# 在 WinDbg 中查看接收缓冲区 dd pPacket L10 # 查看当前堆栈 k # 继续执行 g

这种“源码级断点+符号调试”的组合，是定位ProtoReceive中内存越界、指针错误的终极手段。从那以后我每次调试 NDIS 驱动，都强制走一遍__debugbreak()+dd检查，哪怕只是确认PacketSize是否合理——这已成为我的肌肉记忆。希望帮到你。

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