先说说我自己的情况我第一次写Windows驱动的时候连DriverEntry这个入口函数该放在哪个文件里都懵了半个下午。教材上的代码一大堆看着都能看懂一上机就各种编译错误、加载失败最后好不容易加载进去屏幕一蓝我整个人都傻了。其实对于入门来说最大的门槛根本不是看懂代码而是你到底知不知道内核驱动和普通程序的运行逻辑完全不一样。这篇是我把自己从零开始摸路的过程整理出来的系列第一篇主题很明确把环境、工具和第一个能成功跑起来的驱动骨架弄明白。适合那些有一年半载C语言基础、了解基本系统API比如写过简单Win32程序或者搞过逆向、外挂调试、内核感兴趣的朋友但不适合刚学编程一上来就冲驱动的同学——你至少得先习惯指针和内存布局。这篇不会一次讲太多能够成功加载一个.sys、看到DbgPrint的输出、再学会自己排查加载失败的常见原因就已经是很大的进步了。驱动开发最怕空中楼阁没跑通第一个驱动就去看一堆《Windows内核原理》看三天就忘了。先让它动起来后面再回头补理论效率高得多。1. 为什么驱动开发总卡在第一步环境坑比代码坑更多严格来说驱动开发本身的代码难度对新手来说还好真正的拦路虎是环境搭建。因为现代Windows对驱动加载有强制的签名校验系统版本不同、WDK版本不同、Visual Studio版本不匹配都会让一个明明没错的驱动加载失败而且报错方式还特别拧巴——最常见的是提示无法验证此设备所需的驱动程序的数字签名或Windows 无法启动这个硬件设备。(代码31)这个问题搞不定代码写了一万行也别想跑起来。1.1 选择正确的工具链组合写驱动绕不开微软自家的一套组合拳Visual Studio现在通常用VS2019或VS2022、Windows SDK软件开发工具包和WDKWindows驱动开发工具包。这三者的版本必须匹配否则在VS里面新建内核模式驱动程序空项目都会找不到模板。我当前主机的环境是Windows 11 22H2用的是Visual Studio 2022 Community Windows SDK 10.0.22621 WDK for Windows 11版本10.0.26100。参考之前带过几个新同事的经历我给一个稳定的组合参考操作系统Visual StudioSDKWDKWindows 10 2004VS2019 16.9Windows 10 SDK 2004WDK 10.0.19041Windows 11 21H2VS2022 17.0Windows 11 SDKWDK for Win11Windows 11 22H2VS2022 17.6Windows 11 SDK 22621WDK 10.0.26100装WDK之前务必先装好VS再装SDK最后装WDK。WDK自带的安装器会检测VS版本顺序反了VS里往往找不到对应扩展模板。另外注意WDK装好之后VS的扩展模板会生效但有时候VS已经开着那大概率要重启VS甚至重启电脑。1.2 一定要准备虚拟机新人写驱动必备一台Windows虚拟机——这个建议我放到环境部分说是因为它能救你无数次蓝屏。虚拟机首选VMware或Virtual Box里面同样装好一套Windows 10/11版本不用和宿主一致但位数必须一样比如都是x64。驱动一旦写错最常见的表现是加载后立刻蓝屏或重启如果你在物理机上测试轻则丢失未保存的工作重则系统损坏。我在物理机上测试过一回错误的内存操作蓝屏之后重启网卡驱动都加载不了最后只能进安全模式恢复。虚拟机就无所谓了快照一拍蓝屏了恢复快照继续试无非十秒钟的事。所以第一课的结论就是不管你是多专业的老手驱动调试尽量别直接跑物理机。虚拟机里做调试性能损耗对驱动开发的影响可以忽略不计。2. 内核驱动的心智模型它跟普通程序存在的三个本质差异很多从Application转到驱动开发的人第一个坎其实不是API记不住而是理解不了驱动在这个系统里算什么角色。普通程序是一个被创建出来然后执行任务的东西驱动则是被系统按需加载作为内核与硬件/操作之间的代理的东西。你想写好它必须先建立正确的心智模型。2.1 没有main函数只有DriverEntry普通程序一开始是main驱动一开始是DriverEntry而且它不像main那样可以跑完就退出。DriverEntry负责初始化这个驱动——也就是把各种回调函数、分发例程填充到一个叫DRIVER_OBJECT的结构体里然后返回一个NTSTATUS状态码。更有意思的是绝大多数驱动在DriverEntry返回之后并不会像普通程序那样立即频繁执行逻辑而是挂在系统里像一根插在电路板上的芯片平时待命当某个IRPIO请求包需要处理时系统调用你注册的例程。所以写驱动更像写一套给系统调用的回调集合而不是一串从上向下执行的流程。2.2 IRQL驱动里的CPU情绪等级普通程序你随意在任意线程里Sleep、申请内存、访问文件几乎不用担心时机问题。驱动里不一样系统把CPU的执行级别分成了不同的IRQL中断请求级别你的驱动代码会在不同的IRQL上运行。为了方便理解我平时跟人打比方IRQL就好比人的情绪等级。在 PASSIVE_LEVEL被动级别你心情平静可以干一切事情比如等文件操作、申请大量内存一旦升到 DISPATCH_LEVEL分发级别你相当于在忙碌状态这时候不能等待、不能做页交换——也就是说很多常规函数比如像ZwDelayExecution、KeWaitForSingleObject直接等待就绝对不能调用。驱动开发和普通开发最大的思维差异就在这里你必须时刻清楚当前代码跑在什么IRQL上再决定能用哪些API。新手最容易犯的错误就是迷迷糊糊在DISPATCH_LEVEL调了只能用于PASSIVE_LEVEL的函数结果蓝屏代码IRQL_NOT_LESS_OR_EQUAL直接教你做人。2.3 驱动对象的生命周期跟系统同生共死普通程序可以退出进程退出后它所有资源都被系统回收。驱动不一样它一旦加载直到被停止或系统关停它都一直存在于内核地址空间中。常见的驱动对象是DRIVER_OBJECT里面有驱动名、各个分发例程的入口地址、设备对象链表等。驱动虽然长驻但它的入口DriverEntry只执行一次。而DriverUnload是当你卸载驱动时被调用的清理函数你必须把DriverEntry里创建的所有对象、申请的记录都释放掉否则会造成内核资源泄漏。内核态的资源泄漏比普通程序的内存泄漏要严重得多轻则设备无法正常启停重则系统不稳定动不动就蓝屏。3. 从零手写一个最简单的驱动骨架逐行拆解代码考虑到目标是成功加载并看到输出我先不带入WDFWindows驱动框架那一大堆对象模型而是用最原始、最通俗的WDM写一个最简驱动。WDM虽然代码更啰嗦但没有任何框架封装更能让你看清DriverEntry、DRIVER_OBJECT、DriverUnload这些最基础的东西。等你理解了整个结构再去用WDF/KMDF框架就能明白框架帮你省了多少事。3.1 新建项目和配置项先在VS里新建一个C空项目项目名比如叫MyFirstDriver。然后右键项目属性在配置属性里把 配置类型 改为 驱动程序在驱动程序设置里把 驱动程序类型 选为 内核模式驱动。这一步很重要否则你编译出来的还是.exe或.dll而不是.sys。有一些教程还说要把目标平台从桌面改成通用实际上选桌面也可以。我比较推荐直接创建Empty WDM Driver for Windows模板如果VS里能看到没有就按上面的方式手动配置效果一样。因为模板项目会自动帮你设置好链接器入口/DRIVER:WDM手配容易忘记。3.2 完整的最简驱动代码下面这个代码是整篇文章里唯一需要你逐步搞懂的代码别看它短里面几乎包含了驱动所有核心机制#include ntddk.h // 卸载例程驱动被卸载时系统会调用这个函数 VOID DriverUnload(_In_ PDRIVER_OBJECT DriverObject) { // 这个参数目前用不到所以给编译器一个标记避免警告 UNREFERENCED_PARAMETER(DriverObject); // DbgPrint是内核态的“printf”输出到内核调试器或DebugView DbgPrint([MyFirstDriver] Goodbye, kernel!\n); } // 驱动的入口类似于普通程序的main函数 extern C NTSTATUS DriverEntry( _In_ PDRIVER_OBJECT DriverObject, _In_ PUNICODE_STRING RegistryPath) { UNREFERENCED_PARAMETER(RegistryPath); DbgPrint([MyFirstDriver] Hello, kernel!\n); // 把卸载例程注册到驱动对象里 DriverObject-DriverUnload DriverUnload; // 返回STATUS_SUCCESS表示这个驱动加载成功 return STATUS_SUCCESS; }这段代码看起来简单但它背后的知识点非常关键DriverEntry的第一个参数DriverObject是一个由系统分配好的结构体里面包含了这个驱动的几乎所有身份信息。RegistryPath是注册表中这个驱动对应的服务项路径一般新手用不到暂时忽略即可。DriverUnload会在你执行sc stop MyFirstDriver或者系统关闭时被调用。不注册它也可以但你不注册的情况下这个驱动一旦被加载就没法正常停止了它会一直挂在内核里。注册卸载例程是一个好习惯它让你可以在开发和反复测试中顺利卸载重载而不是每次改代码都要重启虚拟机。extern C是因为DDK头文件在C和C混编译时要确保驱动程序入口点符号名不被C名字改编。你如果不加这一段链接时就会报找不到DriverEntry那种错误特别容易让新手怀疑人生。3.3 手动创建inf文件还是用命令行加载驱动文件编译后是.sys但Windows加载一个驱动通常需要一个.inf安装信息文件来描述这个驱动属于什么设备、用什么方式安装。对于新手来说手写一份简单的 INF 往往比写代码更头疼因为INF语法老派且极其严格。好消息是对于最简驱动我们可以完全绕过INF使用命令行方式加载。微软提供了一组工具只要把.sys复制到系统驱动目录然后用服务管理器注册一下就能加载比如# 把编译好的驱动复制到系统驱动目录 copy /Y myfirstdriver.sys C:\Windows\System32\drivers\ # 创建一个名为MyFirstDriver的内核服务初次加载 sc create MyFirstDriver type kernel binPath C:\Windows\System32\drivers\myfirstdriver.sys # 启动这个驱动服务 sc start MyFirstDriver # 查看驱动服务状态 sc query MyFirstDriver # 停止并删除驱动服务 sc stop MyFirstDriver sc delete MyFirstDriversc create里的type kernel表明创建的是一个内核驱动服务等号后面有空格这属于sc命令的语法要求写错就提示参数错误而且是那种非常让人崩溃的无效参数提示。新手照着敲的时候大小写无所谓但空格一定要照着来。用这种方式省略INF的解析过程能让入门流程大幅缩短也更能看清驱动被系统当作内核服务加载的本质。等你后面开始做即插即用设备驱动再回过来学INF理解会好很多。4. 编译成功只是第一步签名、测试模式与调试输出代码写好了编译也通过了很多新手到了这一步会非常兴奋觉得马上就能看到驱动跑起来。实际上现代Windows的驱动加载流程中还横着一道大坎数字签名。简单来说64位Windows的普通版本不允许加载没有有效签名的内核驱动至少默认策略如此。如果是你自用的开发驱动不需要花钱买EV证书标准做法是开启测试签名模式并用自己生成的测试证书给驱动签名。4.1 开启测试签名模式以管理员身份打开命令提示符执行bcdedit /set testsigning on然后重启电脑。再次开机后桌面右下角如果出现测试模式水印就说明测试签名模式已生效。注意这个操作本身不算危险但如果你打算长期在某个系统上进行驱动开发建议只在专用的测试虚拟机上开启。有些老教程会让你用bcdedit /set nointegritychecks on或bcdedit /disable_integrity_checks来关闭驱动签名强制校验但那个选项在较新的Win10/Win11上已基本失效而且更不安全。正规做法是使用WDK自带的工具自己做一个测试证书再给.sys签名。4.2 给驱动做测试签名WDK装好后开始菜单里能找到Developer Command Prompt for VS 2022。在这个环境里用MakeCert或更推荐的新工具New-SelfSignedCertificatePowerShell生成一个自签证书然后还要再用Inf2Cat或者SignTool签名。下面是完整步骤假设系统上已经开启了测试签名模式# 创建一个自签名证书一次性有效期为两年 makecert -r -pe -ss PrivateCertStore -n CNMyTestDriverCert -len 2048 myTestDriverCert.cer不过新版本WDK里面MakeCert其实已经标记为废弃更通用的做法是# 使用 PowerShell 生成证书并导出为cer文件 New-SelfSignedCertificate -Subject CNMyTestDriverCert -Type CodeSigningCert -CertStoreLocation Cert:\LocalMachine\My | Export-Certificate -FilePath C:\Project\myTestDriverCert.cer生成证书之后还需要在C:\Project下写一个极其简单的INF文件用于签名描述[Version] Signature $WINDOWS NT$ Class Driver ClassGuid {8ECC055D-047F-11D1-A537-0000F8753ED1} Provider %ProviderName% DriverVer 06/26/2024,1.0.0.0 [Manufacturer] %ProviderName% DeviceList, NTamd64 [DestinationDirs] DefaultDestDir 12 [DeviceList.NTamd64] %DeviceName% RootDeviceInstall, Root\MyFirstDriver [RootDeviceInstall.NTamd64] CopyFiles DriverFiles [RootDeviceInstall.NTamd64.Services] AddService MyFirstDriver, 0x00000002, DriverService [DriverFiles] myfirstdriver.sys 1,,32 [DriverService] DisplayName MyFirstDriver Service ServiceType 1 StartType 3 ErrorControl 1 ServiceBinary %12%\myfirstdriver.sys [Strings] ProviderName MyFirstDriverProvider DeviceName MyFirstDriver Device这段INF只服务于给驱动做目录签名不深入去讲每一位的含义因为在命令行加载方式下INF不一定参与安装过程。接下来执行# 用inf生成catalog文件 inf2cat /driver:C:\Project /os:10_RS5_X64 # 使用之前生成的证书给cat和sys都签名 signtool sign /v /f myTestDriverCert.pfx /t http://timestamp.digicert.com myfirstdriver.sys实际上如果你嫌麻烦很多教程和团队内部其实用简化办法只要开启了测试签名模式有的签名工具可以对未签名驱动以测试证书直接签署.sys不一定需要一套完整INF。个人经验是在最开始的练习里你只需要让驱动能被加载起来签名搞到系统识别为测试签名就够。4.3 用DebugView看内核打印代码里的DbgPrint出来的信息你普通运行是看不到的。新手最容易卡住的就是这里驱动已经加载成功了但不知道去哪看输出。一个最简单的方法是使用Sysinternals套件里的DebugView。以管理员身份打开DebugView然后在菜单里勾选上内核输出捕获选项选中Capture Kernel菜单项打开Capture Global Win32或相关选项重启MyFirstDriver服务如果驱动加载成功你会在 DebugView 的输出窗口里看到[MyFirstDriver] Hello, kernel!停止时能看到[MyFirstDriver] Goodbye, kernel!。注意不用Windbg的情况下DbgPrint的输出可能受某些系统策略控制比如内核调试器未连接时可能不输出。我的经验是如果是本地VM测试直接勾选DebugView的Enable Verbose Kernel Output如果版本里有这个选项再重新加载驱动通常能解决。DebugView对新手来说是最友好的调试手段不需要连接双机调试也不设置符号先满足看得见日志这个基本需求。后面深入后再学WinDbg双机调试也不迟。5. 驱动加载失败与蓝屏的常见原因我的完整排查链路说实话驱动开发里最折磨人的不是写功能逻辑而是加载失败。而且内核失败和用户态失败完全不是一个世界用户态程序崩了最多弹个错误框顶多进程崩溃驱动出错整个系统蓝屏所有正在编辑的文档一秒钟全没。我整理了自己和同事踩过的几个典型问题按排查链路一步步说能帮你省下大量查资料时间。5.1 错误代码这是由注册表中的信息不完整或已损坏引起的如果加载后设备管理器里显示由于其配置信息(注册表中的)不完整或已损坏Windows 无法启动这个硬件设备。 (代码19)这个往往不是驱动文件的问题而是设备服务项在注册表中的配置被破坏或者驱动的服务类型和sc create不一致。可以先删掉服务再重新创建把服务名和驱动文件名对齐。sc stop MyFirstDriver sc delete MyFirstDriver sc create MyFirstDriver type kernel binPath C:\Windows\System32\drivers\myfirstdriver.sys sc start MyFirstDriver如果依然报错检查一下是不是以管理员身份执行的以及binPath路径是否真实存在。驱动路径写错是特别常见的坑比如把C:\Windows\System32\drivers写成了C:\Windows\System32\DriverStore那是驱动仓库目录不是驱动加载目录。5.2 无法验证此设备所需的驱动程序的数字签名这个问题我身边的新同事几乎每个人都会遇到提示是Windows 无法验证此设备所需的驱动程序的数字签名。最近的硬件或软件更改安装的文件可能未正确签名或已损坏或者可能是来自未知来源的恶意软件。 (代码52)。解决方案就是前面说的在开发期使用测试签名模式 测试证书签名。如果你确实需要临时加载未签名驱动先确认bcdedit设置生效然后重启。记住签名校验被绕过之后加载驱动要格外谨慎不要随意加载网上来源不明的.sys那是系统底层的东西恶意驱动能拿到完全的内核权限。5.3 蓝屏代码 IRQL_NOT_LESS_OR_EQUAL这个蓝屏代码基本能确认你的驱动里发生了在错误的高IRQL上访问了可分页内存或访问了非法地址。比如在DISPATCH_LEVEL上调用了一个可能引起页错误的函数或者对某个空指针做了解引用。遇到蓝屏不要慌先在虚拟机里重启然后打开系统的内存转储文件C:\Windows\MEMORY.DMP用WinDbg加载后执行!analyze -v它会给出崩溃时的调用栈。这一步对于新手来说是个很好的学习机会你能直接看到崩溃代码在哪个函数、哪个偏移。比如有一次我是因为忘记了某个UNICODE_STRING的Buffer还没初始化就直接wcslen导致蓝屏而dump分析里明确显示的正是那个偏移位置一下就定位到了。5.4 加载成功但立即又停止驱动崩溃回滚有时候你执行sc start MyFirstDriver系统提示服务已启动但紧接着调sc query发现服务已经停止。这种情况大多是DriverEntry或驱动初始化阶段发生了异常系统自动回滚并卸载了这个驱动。最常见的原因是DriverEntry里返回了一个失败状态码或者DriverEntry里执行了会崩溃的代码。这时候DebugView的日志就显得极为重要。我的做法是在DriverEntry里逐步加DbgPrint比如在进入函数时打印一次、注册完Unload时打印一次、准备返回前打印一次看它到底卡在哪个位置。如果日志没输出那大概率驱动压根没有进入入口——这种情况优先检查签名和路径。6. 一台按了暂停键的系统进一步理解设备对象与IRP如果你能把上面最简驱动成功跑完下一步就应该往设备对象和IRP这两个概念走了。这俩是驱动开发最核心的骨架新手没必要一次性吃透但第一课里至少要建立基本印象。6.1 设备对象驱动不是设备设备对象才是设备初学者最容易混淆的是驱动和设备。系统里真正被操作的是设备对象驱动是服务于设备对象的代码。一个驱动可以创建多个设备对象比如每个物理硬盘可能对应一个设备对象一个网卡驱动也可以同时管理多个网卡。设备对象用IoCreateDevice创建并有一个名字。如果是命名设备应用程序可以像打开文件一样用CreateFile打开它然后通过DeviceIoControl发控制指令。如果是不命名设备通常只能让更上层的驱动通过IoAttachDevice等方式访问。我们后面会经常看到一个叫DEVICE_OBJECT的结构体它有一个MajorFunction数组里面存了各种IRP分发例程的入口比如IRP_MJ_READ、IRP_MJ_WRITE、IRP_MJ_DEVICE_CONTROL。简单说上层调用ReadFile发下来的请求会变成IRP内核根据设备对象里注册的处理函数去调用你的驱动代码。6.2 IRP内核里流动的快递单把IRP理解成一份快递单最形象。应用程序调用ReadFile、WriteFile、DeviceIoControl时系统会封装出一个IRP上面写着请求类型、缓冲区地址、请求长度、完成状态等信息然后把它送到对应设备对象的分发例程。驱动收到IRP后可以选择自己立刻完成也可以把它转发给下层驱动。处理完一定要调用IoCompleteRequest并设置IRP-IoStatus.Status如果不完成IRP调用它的用户程序会一直卡住等待看起来就是程序假死。初学阶段最常犯的错误之一就是忘了完成IRP。如果这第一课就能让你搞懂驱动 注册回调 响应IRP那后面的路就好走了很多。7. 给新手的几条硬经验从第一行驱动代码到可以跑项目的道路最后我把两年来踩坑的经验浓缩成几条穿插着分享出来。这些不属于任何教材但每一条都是真实填坑换来的。7.1 一定要掌握WinDbg双机调试的启动姿势DebugView适合我已经写完只想看日志的场景但一旦驱动崩溃DebugView帮不了什么忙。要在开发初期就先把WinDbg双机调试环境搭起来宿主和虚拟机之间用命名管道连接哪怕只是学会暂停、附加内核、!analyze -v这几个操作价值都远超想象。装WinDbg的过程本身不复杂在Windows商店搜索WinDbg就能安装它是独立于旧版WDK的新调试器。把符号路径设置为微软公共符号srv*https://msdl.microsoft.com/download/symbols然后连接虚拟机。第一次丢!analyze -v的时候你可能会觉得信息太多看不懂没关系坚持看栈逐步定位几次蓝屏基本就学会读内核崩溃转储了。7.2 推荐的学习顺序别一上来就啃《深入理解Windows内核》对于大多数人我不推荐直接按经典大部头从头啃。更合适的学习路径是第一梯队跑通DriverEntry、DriverUnload、IRP的基础读写Handle、CreateFile/DeviceIoControl第二梯队学习WDF框架用KMDF写一个简单的PNP设备过滤驱动第三梯队深入某个垂直场景比如文件系统过滤/minifilter、网络过滤WFP、WDM总线驱动第四梯队看经典原理书补底层知识比如内核调度、内存管理、对象管理驱动开发一个很迷人的点在于它既需要工程能力又需要原理深度。如果直接从原理开啃很容易困在理论的汪洋大海里没有代码正反馈反过来直接抄代码很容易写出能跑但不知道在干嘛的驱动。理想的方式是以小项目为锚点一个点一个点去触发理论需求学到的东西才真正扎根。7.3 不要忽视WDF/KMDF但第一课还是先看WDM我见过很多新人直奔WDF被它的各种对象、事件、回调搞晕最后连基本的DriverEntry都没搞清楚也见过执着于WDM写到底几乎所有的框架包装都不用结果实际开发效率很低。我的结论是第一课用WDM看清底部的样子第二课转KMDF做实际功能。WDF把很多重复逻辑封装了比如即插即用和电源管理不用WDF的话你会耗费大量精力在处理启动、停止、状态转换这些必备但无关功能的代码上。最理想的状态是既能看懂WDM底下的原理又能用WDF快速实现。7.4 善用WDK示例代码但要注意版本和系统WDK安装目录下有大量官方示例分布在类似C:\Program Files (x86)\Windows Kits\10\Samples的地方。这些示例写得非常规范很多还配有完整INF是最快的学习素材。但我发现不少新手拿到的示例是在较老系统Win7/Win8上写的里面有些API在Win10/11上已经废弃编译报错非常迷惑。遇到这种情况第一反应不是去改代码而是去查这个API的微软当前文档状态。有时候API确实被标记为废弃但有些只是改了头文件位置或宏定义需要仔细看ntddk.h的版本。比如RtlStringCchPrintf系列来自ntstrsafe.h和旧版的sprintf_s在使用场景上有所不同。总之示例代码看看可以但永远以你现在系统的头文件为准。驱动开发的学习曲线确实陡峭蓝屏和图里图气的报错信息会伴随你好一阵子但一旦你突破了第一次加载成功、第一次看到日志、第一次定位蓝屏那种掌控系统底层的成就感是很多上层开发给不了的。尤其当你能用一个小驱动去控制物理设备行为或者在系统崩溃转储中准确找到自己的代码位置你会觉得之前的挣扎都值了。下一篇我会接着写IRP分发的实际实现用一个可以接收DeviceIoControl命令的完整驱动示例一步一步把它们串起来。等那个驱动跑通你手里的Windows就真成了可以自己改造底层的平台。
