简介在Windows XP下开发PCI设备驱动需要同时理解硬件总线机制与内核驱动模型这份资源正为此类系统级开发任务而整理。它面向驱动开发者、嵌入式工程师及操作系统学习者围绕WDM驱动模型、IRP处理、PnP与电源管理、中断服务例程、DMA传输等核心主题提供了从接口识别到安装签名的一整套知识要点与参考实现。压缩包共100个文件约1.53MB其中包含34个bin固件或数据文件、18个头文件、15个cpp源码文件以及INF安装信息、工程文件dsp/dsw和调试产物pdb/obj等基本覆盖了一个PCI驱动项目的源码、配置与编译调试链条。目前已有418人学习。通过梳理设备枚举、资源分配、ISR与DPC协作等关键流程读者可快速建立XP下PCI驱动的整体框架并参照其中的源码与工程结构进行二次开发或实验验证。1. 在Windows XP上开发PCI驱动的现实场景你从仓库翻出一台旧工控机H61主板板载的PCI槽上插着一张数据采集卡系统是Windows XP专业版SP3。开机后设备管理器里“PCI简单通讯控制器”或者“PCI数据捕获和信号处理 感叹号”一直挂在那边VEN和DEV都能看到但系统就是找不到能用驱动。这种卡往往没有官方WinXP驱动想让它跑起来只能自己写。另一个场景是PCI设备供应商提供的固件包里只有几个.bin文件比如PCI001F0.bin、PCI001D2.bin没有.inf也没有.sys你需要从这些二进制快照里反推设备配置空间再写一个WDM驱动把硬件识别出来。这篇文章会按照实际拆项目的过程把PCI驱动的框架、IRP处理、DMA传输、调试和签名一条线走完。适合正在维护旧采集卡/通信卡或者刚接触内核驱动、想知道WDM里那些函数到底怎么拼起来的人。2. WDM驱动框架中的PCI设备识别与配置空间读取2.1 为什么在XP上写PCI驱动优先选WDM而不是KMDFWindows XP下可用的内核驱动模型有WDMWindows Driver Model和KMDFKernel Mode Driver Framework。虽然KMDF在XP上也能运行但PCI类设备尤其是采集卡、多串口卡、非标数据捕获卡现有代码和参考资料绝大多数都基于WDM。原因是WDM让驱动直接面对IRP和IO_STACK_LOCATION硬件交互路径完全透明出问题用WinDbg能看到每个PnP IRP经过哪一层。KMDF把IRP封装成事件回调遇到BAR地址映射错误、共享中断处理错误时栈上信息不容易直接对应到物理资源。另一个选WDM的理由是XP的PnP管理器对PCI设备的资源要求比较严格。NT4时代的驱动直接IoReportResourceUsage分配端口到了XP里必须通过IRP_MN_START_DEVICE传入的CM_RESOURCE_LIST来拿总线号、中断和内存范围。WDM天然按这个流程走KMDF虽然也支持但你在雷区里的操作空间更小。下面所有代码都基于WDM编译环境用Windows Server 2003 SP1 DDK或者Visual Studio 2010Vista DDK在XP目标机上都能跑。2.2 VendorID/DeviceID与INF匹配的底层逻辑每个PCI设备在配置空间0x00处有16位Vendor ID0x02处是16位Device ID0x0C处是Class Code。系统枚举设备后会根据这些ID去搜索匹配的INF文件。INF中PCI硬件的匹配字段是PCI\VEN_XXXXDEV_YYYYSUBSYS_ZZZZZZZZREV_AA其中SUBSYS是子系统厂商和子系统设备IDREV是Revision ID。缺少任何一个Windows XP的硬件向导都可能提示“无法安装这个硬件”。一个典型的多功能PCI设备INF是这样写[Version] Signature$WINDOWS NT$ ClassSystem ClassGuid{4d36e97d-e325-11ce-bfc1-08002be10318} Provider%VendorName% DriverVer01/01/2020,1.0.0.0 [Manufacturer] %VendorName%DeviceList,NT.5.1 [DeviceList.NT.5.1] %PCIDeviceDesc%PCIDrv_DDI, PCI\VEN_1234DEV_5678 [PCIDrv_DDI] CopyFilesPCIDrv.Files [PCIDrv.Files] pci001.sys,,,0x400 [PCIDrv_DDI.Services] AddService PCI001, %SPSVCINST_ASSOCSERVICE%, PCIDrv.Service [PCIDrv.Service] DisplayName PCI001 Driver ServiceType %SERVICE_KERNEL_DRIVER% StartType %SERVICE_DEMAND_START% ErrorControl %SERVICE_ERROR_NORMAL% ServiceBinary %12%\pci001.sysNT.5.1节表示只对Windows 5.1即XP生效。如果把这节名写成NT.5.2在XP上不会匹配。%12%是驱动文件复制到的目录XP下相当于C:\Windows\System32\drivers。AddService后面的%SPSVCINST_ASSOCSERVICE%在setupapi.h里值是0x00000002表示驱动作为设备功能驱动加载。你可以在DDK的setupapi.h里确认这些常量不要硬编码数字可读性差还容易错。2.3 从配置空间读取寄存器驱动里直接访问配置空间最常见的是在AddDevice或者StartDevice之后用HalGetBusDataByOffset读取。这个函数接受总线号、设备功能号、缓冲区、偏移和长度。设备/功能号编码规则是(device 16) | function总线号来自设备对象的DeviceExtension。NTSTATUS PCI_AddDevice(PDRIVER_OBJECT DriverObject, PDEVICE_OBJECT Pdo) { // 分配设备扩展 PDEVICE_EXTENSION devExt (PDEVICE_EXTENSION)DeviceObject-DeviceExtension; ULONG busNum 0, devFunc 0; UCHAR configSpace[256]; // 通过PDO的DevicePropertyBusNumbers获取总线号/设备号/功能号 ULONG propertyLen 0; PDEVICE_NUMBER deviceNumber NULL; IoGetDeviceProperty(Pdo, DevicePropertyBusNumber, sizeof(ULONG), busNum, propertyLen); IoGetDeviceProperty(Pdo, DevicePropertyAddress, sizeof(ULONG), deviceNumber, propertyLen); devFunc (ULONG)deviceNumber; // 地址编码设备号16 | 功能号 // 从配置空间偏移0开始读取256字节 ULONG readLen HalGetBusDataByOffset(PCIConfiguration, busNum, devFunc, configSpace, 0, 256); if(readLen 64) { // 失败可以用KeBugCheckEx记录但AddDevice里一般返回错误 return STATUS_DEVICE_DATA_ERROR; } devExt-VendorID *(USHORT*)configSpace[0]; devExt-DeviceID *(USHORT*)configSpace[2]; return STATUS_SUCCESS; }这里IoGetDeviceProperty的DevicePropertyAddress返回的是DEVICE_NUMBER结构包含设备号和功能号但要确认它是否做了位编码。更稳的还是从IRP_MN_START_DEVICE的资源里拿下文会讲。HalGetBusDataByOffset的PCIConfiguration是0第三个参数的高16位是设备号、低16位是功能号。读取完建议和项目里的.bin文件做一次逐字节比对确认设备空间和调试时保存的镜像完全一致排除EEPROM内容变动。2.4 常见INF匹配失败原因现象可能原因解决方向设备管理器显示“未知设备”VEN/DEV可见INF里NT.5.1误写成NT.5.2检查Manufacturer节名安装时提示“未找到驱动程序”SUBSYS或REV不匹配读配置空间0x2C和0x08比对设备装上了但每次启动都变回未知设备CopyFiles的sys没有复制到drivers目录查看%windir%\setupact.log定位无法启动设备错误码10AddService的StartType设成SERVICE_BOOT_START但依赖包不存在改为SERVICE_DEMAND_STARTINF匹配是PCI驱动最容易卡壳的地方因为设备管理器显示的VEN/DEV不一定和INF完全一致。比如某些CardBus设备REV值不同版本会变。调试时我会在注册表HKLM\SYSTEM\CurrentControlSet\Enum\PCI下看哪个键和INF匹配上了键大而全能直接看到系统记录的所有硬件ID。3. IRP与中断处理PCI驱动的I/O路径关键代码3.1 把IRP派发例程挂进DRIVER_OBJECTDriverEntry的核心任务就是填写DRIVER_OBJECT的MajorFunction表。PCI功能驱动至少需要处理CREATE/CLOSE/READ/WRITE/DEVICE_CONTROL以及PnP。PnP不实现系统会直接拒绝设备启动。NTSTATUS DriverEntry(PDRIVER_OBJECT DriverObject, PUNICODE_STRING RegistryPath) { DriverObject-DriverExtension-AddDevice PCI_AddDevice; DriverObject-MajorFunction[IRP_MJ_CREATE] PCI_CreateClose; DriverObject-MajorFunction[IRP_MJ_CLOSE] PCI_CreateClose; DriverObject-MajorFunction[IRP_MJ_READ] PCI_ReadWrite; DriverObject-MajorFunction[IRP_MJ_WRITE] PCI_ReadWrite; DriverObject-MajorFunction[IRP_MJ_DEVICE_CONTROL] PCI_Ioctl; DriverObject-MajorFunction[IRP_MJ_PNP] PCI_Pnp; DriverObject-MajorFunction[IRP_MJ_POWER] PCI_Power; DriverObject-DriverUnload PCI_Unload; return STATUS_SUCCESS; }这段代码把五个主要入口挂到驱动对象上。IRP_MJ_READ和IRP_MJ_WRITE共用同一个PCI_ReadWrite函数区分在于Parameters.Read.Length和Parameters.Write.Length以及FileObject里的F0标志。对PCI设备来说读写端口或FIFO的方向在硬件手册里有明确说明驱动里用Parameters.Read还是Parameters.Write的主要差异只在于Information字段要写发送还是接收的字节数。特别注意IRP_MJ_POWER也别省。XP下PCI设备可能参与系统待机/休眠如果不处理电源IRP默认返回成功但设备状态不更新恢复后设备处于D3状态无法访问。至少要调用PoStartNextPowerIrp并把IRP往下传。3.2 用METHOD_BUFFERED处理DeviceIoControl应用程序与驱动通信最常用DeviceIoControlXP下METHOD_BUFFERED模式最稳妥因为系统把输入输出数据都放进同一个SystemBuffer驱动不需要处理MDL。但要注意缓冲区长度检查不严格会导致缓冲区溢出或返回STATUS_BUFFER_OVERFLOW。NTSTATUS PCI_Ioctl(PDEVICE_OBJECT DeviceObject, PIRP Irp) { NTSTATUS status STATUS_SUCCESS; PIO_STACK_LOCATION stack IoGetCurrentIrpStackLocation(Irp); ULONG ioctl stack-Parameters.DeviceIoControl.IoControlCode; ULONG inLen stack-Parameters.DeviceIoControl.InputBufferLength; ULONG outLen stack-Parameters.DeviceIoControl.OutputBufferLength; PVOID buf Irp-AssociatedIrp.SystemBuffer; switch(ioctl) { case IOCTL_PCI_READ_IO_PORT: { // 用户传入一个ULONG端口地址驱动读取该端口并返回 if(inLen sizeof(ULONG) || outLen sizeof(ULONG)) { status STATUS_BUFFER_TOO_SMALL; break; } ULONG port *(PULONG)buf; // 只允许读取设备扩展中记录的BAR范围防止任意端口访问 if(port devExt-PortBase || port devExt-PortBase devExt-PortRange) { status STATUS_INVALID_PARAMETER; break; } *(PULONG)buf READ_PORT_ULONG((PULONG)port); break; } case IOCTL_PCI_WRITE_IO_PORT: { // 输入输出都是同一缓冲区位0是端口地址位1是数据 if(inLen 2 * sizeof(ULONG) || outLen sizeof(ULONG)) { status STATUS_BUFFER_TOO_SMALL; break; } PULONG p (PULONG)buf; WRITE_PORT_ULONG((PULONG)p[0], p[1]); *(PULONG)buf p[1]; break; } default: status STATUS_INVALID_DEVICE_REQUEST; break; } Irp-IoStatus.Status status; Irp-IoStatus.Information (status STATUS_SUCCESS) ? outLen : 0; IoCompleteRequest(Irp, IO_NO_INCREMENT); return status; }这段IOCTL处理的逻辑IOCTL_PCI_READ_IO_PORT把用户传入的端口地址当作输入同时把读到的值写回同一个缓冲区。IOCTL_PCI_WRITE_IO_PORT用两个ULONG表示端口和数据。注意这里的端口地址必须经过设备扩展里记录的范围校验否则用户态任意端口读取会造成系统安全漏洞。IoStatus.Information设为outLen时应用层拿到的返回值就是实际输出长度。如果忘记设置DeviceIoControl会提示“系统传入的缓冲区大小无效”。3.3 ISR与DPC如何分担PCI中断PCI设备中断到达后内核调用驱动注册的ISR。ISR运行在DIRQL设备中断级在这个级别上几乎不能调用任何内核API只能做硬件操作和标志写入。正确做法是ISR里清中断、记录状态、插入DPC真正的数据处理在DPC里做。BOOLEAN PCI_Isr(PKINTERRUPT InterruptObject, PDEVICE_OBJECT DeviceObject) { PDEVICE_EXTENSION devExt (PDEVICE_EXTENSION)DeviceObject-DeviceExtension; ULONG intStatus READ_PORT_ULONG((PULONG)(devExt-PortBase INT_STATUS_REG)); // 判断中断是否来自本设备共享IRQ时这一句非常重要 if((intStatus INT_PENDING_BIT) 0) { return FALSE; } // 清中断避免同一次中断反复触发 WRITE_PORT_ULONG((PULONG)(devExt-PortBase INT_CLEAR_REG), intStatus INT_PENDING_BIT); // 记录状态排队DPC devExt-IntStatus intStatus; KeInsertQueueDpc(devExt-Dpc, NULL, NULL); return TRUE; } VOID PCI_Dpc(PKDPC Dpc, PDEVICE_OBJECT DeviceObject, PDEVICE_EXTENSION devExt, PVOID context) { // DPC运行在DISPATCH_LEVEL可以处理FIFO数据但不能睡眠 ULONG data; while(READ_PORT_ULONG((PULONG)(devExt-PortBase FIFO_STATUS_REG)) FIFO_READY) { data READ_PORT_ULONG((PULONG)(devExt-PortBase FIFO_DATA_REG)); // 放入环形缓冲区 devExt-rxBuf[devExt-rxHead (RX_BUFFER_SIZE - 1)] data; devExt-rxHead; } // 唤醒等待用户态读取的线程 KeSetEvent(devExt-RxEvent, IO_NO_INCREMENT, FALSE); }ISR返回值很重要返回FALSE表示这个中断与本设备无关内核会继续通知共享同一个IRQ的其他设备返回TRUE则本轮中断处理完毕。清中断寄存器需要按硬件手册的要求一般写1清除对应位但不同芯片可能相反。DPC里KeSetEvent是允许的因为DPC的运行级别是DISPATCH_LEVEL不能调KeWaitForSingleObject等待事件但可以置位事件来唤醒位于PASSIVE_LEVEL的等待线程。ISR与DPC的职责边界可以简单总结成一张表写驱动时随时对照阶段运行级别可调用API禁止操作ISRDEVICE_LEVELREAD_PORT_WRITE_PORT_KeInsertQueueDpcKeInterlockedxxx内存分配、睡眠、获取自旋锁DPCDISPATCH_LEVELKeSetEventIoCompleteRequestKeAcquireSpinLockDpc等待用户事件、访问分页内存3.4 用户态发出控制命令的完整调用用户态配合测试IOCTL时CreateFile的路径是\\.\PCI001。DeviceIoControl的输入输出缓冲在METHOD_BUFFERED模式下共用所以读端口时要在同一个缓冲区里既传地址又接收结果#include windows.h #include winioctl.h #define IOCTL_PCI_READ_IO_PORT CTL_CODE(0x8000, 0x801, METHOD_BUFFERED, FILE_ANY_ACCESS) int main() { HANDLE h CreateFile(\\\\.\\PCI001, GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); if(h INVALID_HANDLE_VALUE) return 1; ULONG inBuf[2]; ULONG bytesReturned 0; inBuf[0] 0xEC00; // 假设BAR0映射的I/O端口基址 BOOL ok DeviceIoControl(h, IOCTL_PCI_READ_IO_PORT, inBuf, sizeof(ULONG), inBuf, sizeof(ULONG), bytesReturned, NULL); if(ok) { printf(读取端口0x%X返回0x%X\n, inBuf[0], inBuf[0]); } CloseHandle(h); return 0; }这里CTL_CODE的第二个参数也就是Function Code需要驱动和应用层代码一致。0x801是我自己定义的也可以用0x800以上的任意值但不能和系统预定义冲突。缓冲区首地址是inBuf驱动把读到的值写回inBuf[0]应用层直接用同一变量取得结果。这里输入长度和输出长度都写成sizeof(ULONG)因为端口地址和数据各占一个ULONG但驱动里的校验是inLen必须大于等于一个ULONG、outLen大于等于一个ULONG——所以这样写是安全的。4. 从.bin文件到设备枚举DMA传输与硬件调试4.1 PnP StartDevice里的资源提取设备枚举由PnP管理器完成驱动在IRP_MN_START_DEVICE中收到系统翻译好的资源列表。这里的关键点是使用AllocatedResourcesTranslated而不是AllocatedResources。Translated版本把PCI总线地址翻译成CPU能直接访问的物理地址不翻译的话BAR里的地址需要自己再做一次转换很容易出错。NTSTATUS PCI_StartDevice(PDEVICE_OBJECT DeviceObject, PIRP Irp) { PIO_STACK_LOCATION stack IoGetCurrentIrpStackLocation(Irp); PDEVICE_EXTENSION devExt DeviceObject-DeviceExtension; PCM_RESOURCE_LIST translated stack-Parameters.StartDevice.AllocatedResourcesTranslated; PCM_PARTIAL_RESOURCE_LIST list translated-List[0].PartialResourceList; for(ULONG i 0; i list-Count; i) { PCM_PARTIAL_RESOURCE_DESCRIPTOR res list-PartialDescriptors[i]; switch(res-Type) { case CmResourceTypeMemory: devExt-PortBase (ULONG)res-u.Memory.Start.LowPart; devExt-PortRange res-u.Memory.Length; break; case CmResourceTypeInterrupt: devExt-Irq res-u.Interrupt.Vector; devExt-Irql res-u.Interrupt.Level; break; case CmResourceTypePort: // 如果设备用I/O端口BAR0类型可能是PORT而不是MEMORY devExt-PortBase (ULONG)res-u.Port.Start.LowPart; devExt-PortRange res-u.Port.Length; break; } } // 资源获取成功后才连接中断确保ISR能在设备启用的第一时刻运行 IoConnectInterrupt(devExt-InterruptObject, PCI_Isr, DeviceObject, NULL, devExt-Irql, devExt-Irq, FALSE); return STATUS_SUCCESS; }如果BAR0被系统解释为CmResourceTypePort而你代码里只处理CmResourceTypeMemory后续所有READ_PORT操作都会读到一个无效地址。这就是为什么需要检查资源描述符类型而不是默认BAR0是内存映射。4.2 配置DMA传输的MDL与CommonBuffer支持总线主控DMA的PCI设备驱动需要分配一块设备可访问的物理连续缓冲区。常见做法是用AllocateCommonBuffer它返回一个虚拟地址和一个逻辑地址。设备用逻辑地址作为DMA目标驱动用虚拟地址访问数据。PDMA_ADAPTER adapter IoGetDmaAdapter(DeviceObject, deviceDesc); PVOID commonBuffer adapter-DmaOperations-AllocateCommonBuffer( adapter, DMA_BUFFER_SIZE, logicalAddress, FALSE); devExt-CommonBufferVa commonBuffer; devExt-CommonBufferLa logicalAddress; memset(commonBuffer, 0, DMA_BUFFER_SIZE);IoGetDmaAdapter需要先填充DEVICE_DESCRIPTIONMaster必须为TRUEScatterGather如果设备不支持分片就设为FALSEDma32BitAddresses设为TRUE表示设备支持32位地址MaximumLength设置单次DMA最大字节数。如果设置错误AllocateCommonBuffer可能返回NULL或者设备DMA时访问到错误地址。4.3 用.bin快照校验PCI配置空间项目中附带的PCI001F0.bin、PCI001D2.bin这些文件是我调试时用WinDbg导出、或者驱动启动时保存的PCI配置空间快照。文件名里的001F0、001D2是总线号设备号功能号的简写001F0表示Bus 0 Device 0x1F Function 0001D2表示Bus 0 Device 0x1D Function 2。这类文件的标准用法是做配置空间前后一致性校验。在WinDbg里可以用!pci命令查看对应设备的完整配置空间kds !pci 0 0x1F 0输出会显示设备的Vendor ID、Device ID、Command、Status、BAR0到BAR5、Interrupt Line和Interrupt Pin。把输出保存下来与bin文件对比能确认设备是否真的出现在系统里以及BAR地址是否被BIOS正确分配。比如PCI001F0.bin前16字节应该是VendorID DeviceID Command Status Revision ClassCode如果第0x04偏移的Command寄存器里没有打开内存/IO使能读BAR地址会得到全0驱动自然无法工作。在没有WinDbg的场合我一般写一个临时测试驱动在IRP_MN_START_DEVICE里用力HalGetBusDataByOffset读取128字节再把数据转成十六进制字符串输出到调试端口。这样与项目bin文件比对的成本很低也很容易发现硬件寄存器被BIOS改写的问题。4.4 判断BAR地址映射错误的两个标志DMA或者端口读写失败时先看两个现象。第一系统日志里有事件ID 15提示“设备无法访问内存或I/O区域”这基本就是BAR地址没翻译对。第二设备管理器属性里“资源”页签显示“没有分配资源”说明PnP枚举阶段就没拿到有效BAR。如果BAR地址在配置空间读出来是对的但READ_PORT_ULONG返回0xFFFFFFFF大概率是设备处于D3冷电源状态需要先向设备扩展写入电源管理命令唤醒。另外.bin文件里保存了BAR地址的原始值如果和系统分配后的值不同说明BIOS重新布局了资源。此时驱动不能把固定地址硬编码进代码必须用StartDevice传入的Translated资源列表。5. 驱动安装签名与WinDbg调试的落地技巧5.1 在XP上绕过签名强制或生成测试证书Windows XP SP2及以上对驱动签名有默认限制但做法和Win10不一样。你可以重启后按F8选择“禁用驱动程序签名强制”但每次重启后失效适合开发机。要长期安装就生成测试证书并用SignTool签名然后在目标机上把证书导入“受信任的发布者”。用命令makecert -r -pe -ss My -n CNMy PCI Test pci_test.cer SignTool sign /s My /n My PCI Test pci001.sysmakecert生成一个自签名根证书放到当前用户证书存储里。SignTool sign用该证书对.sys做嵌入签名。签名后INF里还要有相应的CatalogFile项或在安装时把cer文件手动导入。否则安装驱动时仍会看到“无法验证发布者”的红色警告。5.2 双机调试环境配置与断点设置PCI驱动崩溃后系统直接重启最好的手段是串口双机调试。目标机在Boot.ini里加一行multi(0)disk(0)rdisk(0)partition(1)\WINDOWSWindows XP Debug /debug /debugportCOM1 /baudrate115200主机用WinDbg按CtrlK选择Serial波特率设置119200注意必须和目标机一致。连接后设置符号路径和断点kds bu PCI001!DriverEntry kds g驱动加载时会在DriverEntry入口断开。这时候查看DriverObject-MajorFunction确认IRP派发表已经正确填充。如果断点没命中说明.sys文件没被加载常见原因是INF匹配失败或者驱动文件名和INF里的ServiceBinary不一致。5.3 用!irp检查IRP卡住的技巧应用层DeviceIoControl长时间不返回问题几乎都在驱动没有完成IRP。在WinDbg里中断目标机查看正在驱动的IRP地址然后执行kds !irp ffff000012345678如果IRP处于pending状态会显示“Thread is waiting”或者当前IRQL级别卡在高位。多半是驱动分支里写了return STATUS_SUCCESS却漏掉IoCompleteRequest。排查时可以用以下手法在IoCompleteRequest上下条件断点条件设为IRP地址等于xxx看是否有调用路径到达。另一个更快的技巧是在IRP堆栈的IO_STATUS_BLOCK.Status上设数据断点当它被设置为STATUS_PENDING时就会触发。这种检查方式对PCI驱动尤其重要因为很多DMA卡的中断DPC里会直接完成IRP一旦ISR没有正确清中断DPC永远不执行IRP就悬在那。调试时先确认ISR返回值和中断状态寄存器再查IRP栈顺序不能反。本文还有配套的精品资源点击获取
