WDK驱动开发点滴
老程序员做新方向，老树发新芽，作为菜鸟的我，写点心得，用以记录并与同行交流
1对一些概念的理解：
KMDF与UMDF。两者的框架，及使用VS生成的初始代码基本相同，只有所包含的头文件不同，链接的系统库不同，最终生成的文件分别为.sys和.dll。因为框架完全相同，相互移植应该比较容易。
UMDF驱动运行在用户空间，调试相对容易，程序崩溃时也不至于对系统影响太大。所以只要能实现，应该首选使用UMDF框架。
虽说UMDF框架运行在用户空间，但也不是说所有WIN32应用程序可以使用的API都能正常工作。本人遇到过调用WMI组件在UMDF驱动中编译失败的问题，比较有趣的是使用C++调用时编译失败，但使用C文件调用时就正常。
上手
无论什么时候，微软提供的例子都是最好的学习材料，而且某些例子本身就已经能够工作的非常出色。本人曾经使用其中提供的键盘过滤驱动，只修改了安装文件中的设备路径，就可以正常安装，稳定工作。所以当要开发一个驱动时，最快捷的方法是找到最接近其功能的例子，拿它来修改。以下所记录的内容都基于一个例子，或者使用WDK的模板创建的驱动框架。
INF文件及安装
INF文件中最重要的是硬件编号，即[Standard.NT$ARCH$]所指定的内容。这里设定的硬件编号与实际安装时使用的硬件编号一定要相同。否则安装会失败。
如果是设备管理器能直接看到的设备，如果一个ACPI设备，在设备管理器中安装就可以。如果我们开发的设备驱动没有对应的硬件设备结点，就需要使用devcon来安装，该程序会创建硬件设备结点，并安装驱动。devcon可以在WDK的安装目录中找到。使用方法：
devcon.exe inf文件名称 硬件设备结点（即inf文件中设置的结点）
例如，如果设备驱动的INF文件中有如下片段：
[Standard.NT$ARCH$]
%mydriver.DeviceDesc%=mydriver_Device, Root\MyDriver
则devcon的用法为：devcon.exe install xxx.inf Root\MyDriver
在测试阶段，因为我们的驱动没有获得微软提供的签名，需要在系统中开启测试签名才能正常安装，某些驱动甚至需要将驱动文件中的测试签名证书安装到系统信任的证书目录中。开启测试签名的方法：bcdedit /set testsigining on
WHCK测试
如果只是单纯的学习WDK驱动开发，可以不做WHCK测试，但如果是做产品，WHCK是必须要做的，需要注意的几点：
1）server必须是 server2008 R2, server2012, server2016等的英文版。其它更新的server版本是否可用不清楚，但英文版本是必须的。
2）安装server时注意不要安装标准版，它没有桌面，只有命令行，使用不便，至于基于它能否运行WHCK server,还真没有试过。
3）如果一时找不到英文版本也没有关系，安装完，将界面改成英文资源。
并修改注册表以将系统默认语言改为英文。
将HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Language
下面InstallLanguage的值改为0409。如果还有问题，可以把同级的跟Language相关的注册表值都改为：0409
4)最好使用真实机器安装server，来运行WHCK服务器端。因为WHCK运行时间很长，可能需要几天。放在开发机上一不小心关掉，就麻烦了。我试过在vmware中运行server, WHCK客户端连不上。在服务端看不到测试机。
5）WHCK测试环境bug很多，需要问题不要心急，要多试。不行就重启测试机，服务一般不需要重启，实在没办法重启它也是一种方法。
6）可以在开发机上安装whck的studio，用来连接到服务器，执行测试用例，而不需要登录到服务器，比较方便。
指定驱动的类型
在调用WdfDeviceCreate之前调用：WdfDeviceInitSetDeviceType来设置驱动自身的类型，如：
WdfDeviceInitSetDeviceType(DeviceInit, FILE_DEVICE_ACPI); 将其设置为一个基于ACPI的驱动。
如果我们不依赖于其它总线，就可以不调用这个函数。如果设置的类型不对就不能正常安装。如果是过滤驱动，在调用它之前还需要调用WdfFdoInitSetFilter来申明自己是过滤驱动。
驱动中使用事件
UMDF驱动中可以直接使用CreateEvent等用户空间的API，这里不再赘述。KMDF中需要使用KeInitializeEvent来初始化一个Event, KeWaitForSingleObject来等待。KePulseEvent来释放等待中的事件。
驱动中使用延时
KMDF驱动中使用KeDelayExecutionThread来做延时，需要注意的是：其时间单位是100纳秒。如果延时1毫秒需要使用的值为：10000。而且有一个变态的设计：我们传入的值如果为负数，即表示需要等待的时间，如果为正数，则表示需要等待到的时间，即如果使用正数，就需要读出当前时间，加上要等待的时间以后再传给KeDelayExecutionThread。相信还是使用负数比较方便。
驱动相互调用
两个KMDF驱动调用比较方便，在A驱动中WdfDeviceCreate之前调用WdfDeviceInitAssignName函数来为自己申明一个名字。如：
DECLARE_CONST_UNICODE_STRING(devName, L"\\Device\\MyTestDevice");
status = WdfDeviceInitAssignName(DeviceInit, &devName);
这样在B驱动中就可以使用IoGetDeviceObjectPointer来获取驱动A的相关信息，进而调用IoCallDriver来发送Iocontrol进行数据交互。
而UMDF驱动访问KMDF驱动就比较麻烦了。请参考：https://docs.microsoft.com/en-us/windows-hardware/drivers/wdf/controlling-device-access#specifying-device-security-in-an-inf-file
中断级别（IRQ LEVEL）
相比应用开发，KMDF驱动开发有一个比较麻烦的问题是中断级别。同样的函数在不同的地方调用效果不一定相同。当函数报错，发生崩溃等问题时查看微软的帮助文档，了解中断级别对该函数的影响，及当前代码运行在什么样的中断级别上。
