Windows驱动开发

Last Updated: 2023-05-29 10:00:12 Monday

-- TOC --

有幸在工作中参与了几个Windows驱动的开发和维护，很有必要做些总结。我的Windows驱动生涯从一个虚拟麦克风驱动开始，有一份非常初级的pdf在life内。

Knowledge

• 驱动是内核Service，他们“高高在上”，但却基本是在等待用户态的调用。
• YB，Yellow Bang，Windows设备管理器里看到的有问题的node上的那个黄色三角形；
• FiDO，Filter DO的简写；DO，Device Objcet的简写。FiDO自己没有device node，它需要嵌入某个device node的stack中去。

开发调试环境

• 使用正版windows开发调试驱动，不需要激活。
• host和target可网络互通，如果host或target在VMWare虚拟机中，请桥接网络。
• 在host中安装VS（默认C++），选择SDK组件和WDK，SDK版本要与WDK版本对应。如果顺利，安装WDK的最后，会自动弹出安装WDK VS扩展的提示，安装它！（坑：WDK安装过程需要从网络下载，我遇到过用得好好的WDK，突然再无法下载了，可能微软要更新版本，但WDK的安装界面可以做仅Download，能Download就尽量Download吧，但Download下来后，不知道如何使用？我还遇到过，正常安装OK，但不能Download做备份的情况，隔段时间多尝试几次即可，做好备份不浪费生命。）
• 换版本重装WDK时，没有遇到任何障碍，直接安装。

Visual Studio只是一个框，什么版本的SDK都可以装...

如果更换WDK版本，可直接重新安装新版本。

target系统不需要装WDK也可以调试，比如用DebugView看打印，但如果希望使用WinDbg断点调试，就需要在target上安装WDK：

• 在target系统中，安装与host相同版本的WDK，关闭UEFI中的Secure Boot，无视没有SDK的warning，最后安装WDK Test Target Setup MSI（示例路径：C:\Program Files (x86)\Windows Kits\10\Remote\x64\WDK Test Target Setup x64-x64_en-us.msi）。
• 在host中，用VS的Extensions-->Driver-->Test-->Config Device，hostname填target的ip地址。
• WinDbg里面选择Kernel Debug，填入port和key，连接target。（坑：host和target要能够相互主动访问对方，如果host是虚拟机，需要桥接，不能在NAT内）连接成功的提示是这样的：

Microsoft (R) Windows Debugger Version 10.0.22621.382 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.

Using NET for debugging
Opened WinSock 2.0
Waiting to reconnect...
Connected to target 192.168.16.101 on port 50019 on local IP 192.168.16.103.
You can get the target MAC address by running .kdtargetmac command.

• 在代码中，可用DbgBreakPoint()来添加断点，断住后，host上的WinDbg上会有提示，单步调试在WinDbg上进行。（查看源码，添加驱动代码.pdb文件路径，勾选reload）

devcon和sc

devcon工具在安装WDK后就有了，在WDK的某个安装目录中...

驱动的安装卸载查找更新：

devcon install xxxx.inf root\xxxx
devcon remove root\xxx
devcon find root\xxxx
devcon update xxxx.inf root\xxxx

devcon find 后面要跟硬件id，可以在驱动属性里面查到，但有的驱动的id还带*号，而且，也不需要root\前缀，搞不懂....下面是一个bat脚本，判断*cldvirtaudiodevice这个驱动是否已经安装过了，如果是，echo后就结束，不要重复安装。

cd /d %~dp0
@echo off
devcon find *cldvirtaudiodevice | find "No matching"
if %errorlevel% == 0 (
    devcon.exe install cvadriver.inf "*cldvirtaudiodevice"
)^
else (
    echo #### Virtual audio device already exists. ####
)
@echo on

sc这个windows系统自带的命令，也可以用来安装启停和卸载驱动。但我没有搞懂sc和devcon的异同？有些驱动必须要基于inf文件来安装，此时用sc就不行。sc貌似只关心sys文件，适合software driver（不用关心PnP和Power Management）。

> sc create aname type= kernel binPath= path\to\sysfile.sys
> sc start aname
> sc stop aname
> sc delete aname
> sc query aname

进入Windows系统的测试模式

安装没有签名的Windows驱动，需要在测试模式下进行。前面介绍在target系统中安装WDK的过程，会自动将target系统设置为测试模式。对于普通的Windows系统，如果不装WDK，设置测试模式，用管理员打开cmd窗口：

C:\>bcdedit /set nointegritychecks on
C:\>bcdedit /set testsigning on

重启。（可能testsigning on包含了nointegritychecks on，单独testsigning on也可以安装未签名驱动。注意关闭Secure Boot！）

DebugView

target上完全可以不装WDK（装WDK是为了WinDbg设置断点后调试），Win系统设置为测试模式后，就可在系统中安装未签名的驱动进行测试，调试的主要手段，DebugView看打印。个人经验：DebugView64容易自己崩溃，32位的DebugView很稳定！

Capture [Global] Win32这两个选项可以关闭，它们用来捕捉用户态进程的打印。捕捉内核态的打印，打开Capture Kernel，如果打开Verbose，应该就不需要修改注册表了，此时就能看到驱动的打印输出。但据说有的时候不行，还是要修改注册表，如下：

重启。

WinDbg [Pre]

WinDbg可以断点调试kernel，可以打开dump文件分析。（还有很多其它功能）

Microsoft Store里面有个WinDbg Pre，界面很炫酷，功能更强大，可自动下载symbols。

Symbol Path设置：SRV*C:\Temp*http://msdl.microsoft.com/download/symbols（从最右边指定的地址下载后保存在C:\Temp目录下，貌似可以不需要提供地址，SRV*表示用默认地址）。WinDbg Pre都不需要设置了，自动下载symbols。也可设置环境变量_NT_SYMBOL_PATH为前面那个值，这样也可以方便一些其它需要symbol的工具。

系统日志

• 驱动安装有问题时，注意查看Windows系统日志，里面很可能会有有价值的信息。
• 驱动安装卸载log：C:\Windows\INF\setupapi.dev.log，安装失败能看到原因，但不一定有能力解决。

应用程序的问题，也有可能在Windows系统日志中找到线索。

BlueScreen

• 蓝屏后有dump文件可分析（用WinDbg打开，Open Crash Dump，需要管理员权限打开WinDbg），默认在C:\Windows\Minidump目录下，此路径可以在系统设置中查看或修改。作用有限，可看CPU寄存器和调用栈。

Kernel-mode code, on the other hand, being implicitly trusted, cannot recover from an unhandled exception. Such an exception causes the system to crash with the infamous Blue screen of death (BSOD) (newer versions of Windows have more diverse colors for the crash screen). The BSOD may first appear to be a form of punishment, but it’s essentially a protection mechanism. The rationale being it, is that allowing the code to continue execution could cause irreversible damage to Windows (such as deleting important files or corrupting the registry) that may cause the system to fail boot. It’s better, then, to stop everything immediately to prevent potential damage.

inf文件

微软的官方文档，是最好的参考资料：

https://learn.microsoft.com/en-us/windows-hardware/drivers/install/inf-version-section

%windir%：系统windows目录

关于inf文件的鼠标右键安装

要支持这种安装方式，对inf文件有一定的要求：inf文件中需要包含DefaultInstall这样的节，这个节是右键安装时的Inf入口点（MSDN的原话:"An INF file's DefaultInstall section is accessed if a user selects the "Install" menu item after right-clicking on the INF file name."）。很遗憾的是，很多驱动安装包提供的Inf文件中并没有提供这样的节，因此右键安装并不能达到预期的效果（"Providing a DefaultInstall section is optional. If an INF file does not include a DefaultInstall section, selecting "Install" after right-clicking on the file name causes an error message to be displayed."摘自MSDN）。

于是，聪明的你会想：既然inf文件中没有这样的节，我自己往文件中插入这样的节不就能达到目的了吗？这种变通的思维当然是值得肯定的，但是，最终可能还是安装失败。不要质疑是不是自己哪写的不对，再继续修改inf文件前，请看下MSDN上这段话:

"Remarks DefaultInstall sections must not be used for device installations. Use DefaultInstall sections only for the installation of class filter drivers, class co-installers, file system filters, and kernel driver services that are not associated with a device node (devnode). Note The INF file of a driver package must not contain an INF DefaultInstall section if the driver package is to be digitally signed. For more information about signing driver packages, see Driver Signing."

这段话翻译过来是说:DefaultInstall这种方式不适合设备安装(我们安装驱动不就是为了设备安装吗？)，仅适用于安装类过滤驱动/类协安装器/文件系统过滤驱动/以及内核驱动服务(即legendDriver，比如WinIO.sys)这些不涉及到设备节点(devnode)的情况。说的再通俗一点:inf文件中包含[Manufacturer]这样的节(这个节包含了驱动匹配的设备ID)就不应该再有[DefaultInstall]这样的字眼。

驱动与注册表（regedit)

\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum这里面应该是枚举了系统中所有设备，比如devcon install jmic.inf root\jmic，在ROOT\MEDIA下就能看到这个设备，Service字段对应\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services下的路径（每个驱动都是一个内核service，Services内有ImagePath字段，对应此驱动程序文件路径，还有Start方式和Type），ClassGUID字段对应\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control路径下的Class分类信息。

Enum中有时能看到Upperfilters或Lowerfilters，它们都是FiDO的service name，可能有多个。

FiDO驱动的安装

sysinternals工具

对于Windows的开发和使用者，sysinternals部分工具是无价的，这家公司已经被微软收购，搜索sysinternals链接到微软官方网页。有几个工具非常好：desktops， procexp，winobj，debugview...

关于Windows内核中C++的使用

With kernel code, Microsoft started officially supporting C++ with Visual Studio 2012 and WDK 8. C++ is not mandatory, of course, but it has some important benefits related to resource cleanup, with a C++ idiom called Resource Acquisition Is Initialization (RAII). （引入C++语法可以让程序员少犯错误）

• windows kernel中没有C++的运行时库，即没有可以链接的标准库。（但kernel中也原样实现了一些著名的常用的接口）
• new和delete会失败，因为没有用户态虚拟地址空间中的heap，但可重载后使用；
• Global variables that have non-default constructors will not be called - there is no C/C++ runtime to call these constructors.（default constructor就是什么都不做，成员变量也不会初始化，在没有运行时的场景下，原本要在main之前调用的全局对象的constructor，只能通过其它方式来调用！）
• 没有try...catch...throw... （但是有所谓的SEH，Structured Exception Handler，一组MSVC支持的私有__try...__except...__finally机制，可能是为了特意跟标准C++区别开来吧，一直感觉微软在想尽办法让开发人员傻瓜化...）
• 可以用nullptr和auto，可以使用template语法。
• Any C++ standard can be used for kernel development.

Windows Kernel内大部分还是C！

DbgPrint和KdPrint

DbgPrint是函数接口，使用它的问题是，Release版本此接口依然会被调用，有点overhead；KdPrint是个Macro，给DbgPrint包了一层（因此使用时要扩两层括号），在Release版本下，KdPrint为空。因此，一般情况都应该使用KdPrint。

#include <ntddk.h>


void Unload(_In_ PDRIVER_OBJECT DriverObject) {
    UNREFERENCED_PARAMETER(DriverObject);
    KdPrint(("byebye wdm driver, %s\n", "abcde"));
}


extern "C" NTSTATUS
DriverEntry(PDRIVER_OBJECT DriverObject, PUNICODE_STRING RegistryPath) {
    UNREFERENCED_PARAMETER(RegistryPath);

    KdPrint(("hello wdm driver, %d\n", 12345));
    DriverObject->DriverUnload = Unload;

    return STATUS_SUCCESS;
}

DriverEntry必须是C接口，在cpp文件中要使用extern "C"这个prefix。

KdPrint打印UNICODE_STRING，使用%wZ。

// %wZ is for UNICODE_STRING objects
KdPrint(("Original registry path: %wZ\n", RegistryPath));
KdPrint(("Copied registry path: %wZ\n", &g_RegistryPath));

DbgPrintEx和KdPrintEx

The output from DbgPrint(Ex) is limited to 512 bytes. Any remaining bytes are lost.

UNICODE_STRING

typedef struct _UNICODE_STRING {
  USHORT Length;
  USHORT MaximumLength;
  PWSTR  Buffer;
} UNICODE_STRING, *PUNICODE_STRING;
typedef const UNICODE_STRING *PCUNICODE_STRING;

设备名和符号链接名

Windows下的设备是以\Device\[设备名]形式命名，例如磁盘分区的C盘和D盘的设备名称就是\Device\HarddiskVolume1和\Device\HarddiskVolume2, 当然也可以不指定设备名称。

如果IoCreateDevice中没有指定设备名称，那么I/O管理器会自动分配一个数字作为设备的名称。例如\Device\00000001。

\Device\[设备名]这样的设备名使用起来稍有不便。符号链接可以理解为设备的别名。设备名只能被内核模式下的其他驱动所识别，而别名可以被用户模式下的应用程序识别，例如C盘，就是名为C:的符号链接，其真正的设备对象是\Device\HarddiskVolume1（不同系统可能编号有别）。所以在写驱动时候，一般我们会创建一个符号链接别名，供用户态程序使用。

用winobj可以查看系统中的设备和符号链接：

从winobj的界面上看，同一个device可以存在多个symbolic link。

驱动代码中定义：

#define NT_DEVICE_NAME  L"\\Device\\VMouse"      // device
#define DOS_DEVICE_NAME L"\\DosDevices\\VMouse"  // symlink
// or
#define DOS_DEVICE_NAME L"\\??\\VMouse"          // symlink

DosDevices的符号链接名就是??, 所以\\DosDevices\\XXXX其实就是\\??\\XXXX

用户态代码使用：

#define   VIRTUAL_DEVICE_NAME   L"\\\\.\\VMouse"
// or
#define   VIRTUAL_DEVICE_NAME   LR"(\\.\VMouse)"  // C++11

DriverObject和DeviceObject

一个DriverObject可以挂多个DeviceObject：

Although a driver object may look like a good candidate for clients to talk to, this is not the case. The actual communication endpoints for clients are device objects. Device objects are instances of the semi-documented DEVICE_OBJECT structure. Without device objects, there is no one to talk to. This means that at least one device object should be created by the driver and given a name, so that it may be contacted by clients.

开发经验：

• 只有所有的device都delete后，在DriverObject上注册的Unload接口才会被调用！（还有一个不调用unload的原因，见后面）
• 某位高手说：除了nonpnp driver（比如software driver，或filter），都不会在DriverEntry中创建device object，这样不规范。
• 对于pnp设备（所有device在AddDevice中创建，在remove中删除），禁用如果触发Unload（一定会有pnp的remove），在启用会从DriverEntry开始。（Unload是Driver的unload，不是device的）
• 在AddDevice中创建的device object，如果给这个device设置symlink，加入devstack，这个symlink无法被用户态访问，access denied，如果一定要访问，需要设置SDDL，或者采用control device的方案。
• control device，我理解应该是指没有加入devstack的Device Object。这类device可以安全的设置symlink，与用户态通信。

微软官方：

The control device object is the only type of device object that can safely be named, because it is the only device object that is not attached to a driver stack.

A user mode application can not access the filter driver with out a device name since a call to IoRegisterDeviceInterface is not valid for control device objects. If a non-NULL value is passed in the DeviceName parameter, this value becomes the name of the control device object.

• 在用户态还没有close所有handle的时候，卸载或禁用驱动，此时也没有Unload调用（很可能是为了防止用户态的继续访问，如果资源都释放了，BSOD）。再安装或启用，也同样不会有DriverEntry调用。所以，从这个角度看，在DriverEntry中创建control device是不规范的。安装了驱动，系统提示重启后生效，可能也是这个原因，就驱动没有unload。
• 如果用户态没有close handle，此时驱动被卸载或被禁用，走的流程一样，而且没有unload。再安装或启用，用户态还能够继续执行DeviceIoControl，但接口收到的device object地址是之前的过时的地址，anyway，这个地址有的时候没有任何作用，但对这个地址做任何操作都非常非常危险。

如何在miniport中增加control device

在miniport中，可以创建control device，即不加入devstack的device，设置symlink，设置属性，与用户态沟通。假设用户态只用DeviceIoControl来与驱动交互，此时，miniport的DriverEntry中，需要注册至少3个MJ：

DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] = for_DeviceIoControl;
DriverObject->MajorFunction[IRP_MJ_CREATE] = for_CreateClose;
DriverObject->MajorFunction[IRP_MJ_CLOSE] = for_CreateClose;

如果不注册CREATE和CLOSE，我遭遇的就是，用户态createfile的时候蓝屏（另一个FDO有一个系统自动生成的symlink，被我找出来用了）。因为，此时createfile流程会进入classport注册的CREATE接口，我们不知道这个接口内在做什么事情。而如果在miniport中注册CREATE，用户态在createfile的时候，调用就会进入miniport的这个CREATE接口，此时，我们只需要成功返回即可：

NTSTATUS
for_CreateClose(
    _In_ PDEVICE_OBJECT     pDeviceObject,
    _Inout_ PIRP            pIrp
)
{
    PAGED_CODE();
    ASSERT(pDeviceObject != NULL);
    ASSERT(pIrp != NULL);

    if (pDeviceObject == pcm_device) {
        pIrp->IoStatus.Status = STATUS_SUCCESS;
        pIrp->IoStatus.Information = 0;
        IoCompleteRequest(pIrp, IO_NO_INCREMENT);
        return STATUS_SUCCESS;
    }

    return PcDispatchIrp(pDeviceObject, pIrp);
}

记得做一个pDeviceObject == pcm_device的判断。DeviceIoControl接口中，也要做这个判断。如果不是miniport创建的这个control device，就把IRP交给classport处理。

LIST_ENTRY和CONTAINING_RECORD

我在Linux内核中也见过类似的技术，我在一篇英文博文中读到：这个技术无处不在...

typedef struct _LIST_ENTRY {
    struct _LIST_ENTRY *Flink;
    struct _LIST_ENTRY *Blink;
} LIST_ENTRY, *PLIST_ENTRY;

struct MyDataItem {
    // some data members
    LIST_ENTRY Link;
    // more data members
};

//
// CONTAINING_RECORD macro
//Gets the value of structure member (field),given the type(MYSTRUCT, in this code) and the List_Entry head(temp, in this code)
// 这个macro的定义，不是来自微软官方
#define CONTAINING_RECORD(address, type, field) (\
    (type*)((char*)(address) - (unsigned long)(&((type*)0)->field)))

MyDataItem* GetItem(LIST_ENTRY* pEntry) {
    return CONTAINING_RECORD(pEntry, MyDataItem, Link);
}

CONTAINING_RECORD第3个参数是field (name)，在实际调用的时候，它就是结构体中LIST_ENTRY类型的成员名称，如上，Link！

用这个技术，能够将任意自定义的结构体串起来，形成双向链表，只要知道Link这个field的address，和结构体的type。

Windows Kernel中还提供了一组用来操作这种list结构的函数接口。

IRQL

Every hardware interrupt is associated with a priority, called Interrupt Request Level (IRQL) (not to be confused with an interrupt physical line known as IRQ), determined by the HAL. Each processor’s context has its own IRQL, just like any register. IRQLs may or may not be implemented by the CPU hardware, but this is essentially unimportant. IRQL should be treated just like any other CPU register. The basic rule is that a processor executes the code with the highest IRQL.

When user-mode code is executing, the IRQL is always zero (PASSIVE_LEVEL). This is one reason why the term IRQL is not mentioned in any user-mode documentation - it’s always zero and cannot be changed. Most kernel-mode code runs with IRQL zero as well.

高IRQL的ISR（Interrupt Service Routine）可以抢占低IRQL，用户态的代码“毫无尊严”，可以随时被中断抢占。（但用户态自由啊...）

DISPATCH_LEVEL (2) - this is where things change radically. The scheduler cannot wake up on this CPU. Paged memory access is not allowed - such access causes a system crash. Since the scheduler cannot interfere, waiting on kernel objects is not allowed (causes a system crash if used).（在这个级别，只有更高级别的硬件设备终端才能抢占CPU，不能访问paged memory，不能等待...spinlock运行在这个级别）

In kernel mode, the IRQL can be raised with the KeRaiseIrql function and lowered back with KeLowerIrql.

IRQL is an attribute of a processor. Priority is an attribute of a thread. Thread priorities only have meaning at IRQL < 2. Once an executing thread raised IRQL to 2 or higher, its priority does not mean anything anymore - it has theoretically an infinite quantum - it will continue execution until it lowers the IRQL to below 2.

中断控制器（如APIC）允许设定每一个硬件中断的优先级，但 Windows 并没有使用中断控制器的优先级，而是规定了一套软件中断优先级，称为中断请求级别（IRQL，Interrupt Request Level）。在 Intel x86 系统中，Windows 使用 0~31 来表示 IRQL，数值越大，优先级越高。处理器在运行时总是有一个当前 IRQL，如果发生中断时，中断源的 IRQL 等于或者低于当前级别，则该中断被屏蔽，直到处理器的 IRQL 降下来为止。IRQL=0 表示普通线程，称为 PASSIVE_LEVEL 或被动级别，它的优先级最低，可被任何其他级别的中断打断；IRQL=1 表示异步过程调用（APC，Asynchronous Procedure Call），称为 APC_LEVEL，它仅仅比 PASSIVE_LEVEL 高，因此，在一个线程中插入一个 APC 对象可以打断该线程的执行；IRQL=2 表示处理器正在做以下两件事情之一：正在进行线程调度，比如选择新的线程；正在处理一个硬件中断的后半部分（不那么紧急的部分），在 Windows 中，这被称为延迟过程调用（DPC，Deferred Procedure Call）。因此 IRQL 为 2 也被称为 DISPATCH/DPC级别，或者简单地称为 DISPATCH_LEVEL。3~26 是设备 IRQL，27~31 是一些特殊的硬件中断，包括时钟中断、电源中断、处理器间中断等，它们都是硬件中断。

DPC 是一个重要的概念，它的 IRQL 等于 DISPATCH_LEVEL，高于 PASSIVE_LEVEL和 APC_LEVEL，因此它优先于任何一个与线程相关的函数，也屏蔽了线程调度；同时又低于所有的硬件中断，所以它不会屏蔽任何一个硬件中断。之所以称为“延迟的”过程调用，是因为它往往被用来执行一些相对于当前高优先级的任务来说不那么紧急的事情，例如，硬件中断服务例程可以把一些相对不紧急的事情放到一个 DPC 对象中处理，从而缩短处理器停留在高 IRQL 的时间。

Spin Lock

The Spin Lock is just a bit in memory that is used with atomic test-and-set operations via an API. When a CPU tries to acquire a spin lock, and that spin lock is not currently free (the bit is set), the CPU keeps spinning on the spin lock, busy waiting for it to be released by another CPU (remember, putting the thread into a waiting state cannot be done at IRQL DISPATCH_LEVEL or higher).

资料上说：spinlock的内存，以及被保护的资源，都需要在non-paged pool中。因为获取spinlock会让线程的IRQL升级到DISPATCH_LEVEL，这个级别不能访问paged pool。另外，spinlock只有在多核CPU或多CPU场景下才有效，在单核CPU上，spinlock无效（相当于获取spinlock的那一行代码什么都不干，直接过）。（获取spinlock的接口，先升级到DISPATCH_LEVEL，这样才能更好地实现在某个CPU核上做busy wait）

网上有多份资料都说明，默认情况下（没有#pragma指令），内核加载器会加载所有的代码和全局数据到non-paged内存中！

If several CPUs try to acquire the same spin lock at the same time, which CPU gets the spin lock first? Normally, there is no order - the CPU with fastest electrons wins :). The kernel does provide an alternative, called Queued spin locks that serve CPUs on a FIFO basis.

Paged or Non-paged Memory

内核态的内存分paged或non-paged，即是否可以paged out这个区别。用户态的内存都是可paged！（用户态地位底下呀，但是自由啊...）

当IRQL在 >=2 的时候，代码就只能访问non-paged内存区域！

下面这些编译器指令，可在编译时，明确这些指令下面的代码或数据，他们载入的内存区域是paged还是non-paged：

#pragma code_seg()  // default, non-paged
#pragma code_seg("INIT")
#pragma code_seg("PAGE")
#pragma data_seg()  // default, non-paged
#pragma data_seg("INIT")
#pragma data_seg("PAGE")

我重新浏览了一遍微软的麦克风驱动demo代码，几乎所有的函数定义前，都有一个指定paged或non-paged的编译器指令。

DriverEntry接口，应该指定到INIT section。

下面是我见过的另外一种定义方式：

#ifdef ALLOC_PRAGMA
#pragma alloc_text(INIT,DriverEntry)
#pragma alloc_text(PAGE,AddDevice)
#pragma alloc_text(PAGE,Unload)
#pragma alloc_text(PAGE,Pnp)
#pragma alloc_text(PAGE,Power)
#pragma alloc_text(PAGE,Create)
#pragma alloc_text(PAGE,Close)
#pragma alloc_text(PAGE,DeviceControl)
#pragma alloc_text(PAGE,InternalControl)
#pragma alloc_text(PAGE,SystemControl)
#pragma alloc_text(PAGE,CompleteIrp)
#endif

使用NonPagedPoolNx

As a best practice, drivers for Windows 8 and later versions of Windows should allocate most or all of their nonpaged memory from the no-execute (NX) nonpaged pool. By allocating memory from NX nonpaged pool, a kernel-mode driver improves security by preventing malicious software from executing instructions in this memory.

HLK测试有这一项检测。

POOL_FLAG_NON_PAGED这个macro自带Nx属性，但老接口ExAllocatePoolWithTag要用NonPagedPoolNx。

IRP

An IRP is a structure that is allocated from non-paged pool typically by one of the “managers” in the Executive (I/O Manager, Plug & Play Manager, Power Manager), but can also be allocated by the driver, perhaps for passing a request to another driver. Whichever entity allocating the IRP is also responsible for freeing it. An IRP is never allocated alone. It’s always accompanied by one or more I/O Stack Location structures (IO_STACK_LOCATION).

When a driver receives an IRP, it gets a pointer to the IRP structure itself, knowing it’s followed by a set of I/O stack location, one of which is for the driver’s use. To get the correct I/O stack location, a driver calls IoGetCurrentIrpStackLocation (actually a macro).

The parameters of the request are somehow “split” between the main IRP structure and the current IO_STACK_LOCATION. （入参分散在IRP和IO_STACK_LCATION两个地方，我觉得可能是因为有入参的性质，因此名称为IO+STACK，但其实只是IRP后面的一块non-paged内存。）

一个device node中是分层的，每一层一个driver object和一组device object，IRP的传递如下图：

我现在的理解，比如上图的FDO，里面有一个Driver Object，但可能有多个Device Object，这些device具有不同的性质，有些device就算有symlink，用户态也无法访问。（这部分前文还有描述）

IRP就是这样流动的...从上到下（只到IoCompleteRequest），再回到最初...

• PDO (Physical Device Object) - Despite the name, there is nothing “physical” about it. This device object is created by a bus driver - the driver that is in charge of the particular bus (e.g. PCI, USB, etc.). This device object represents the fact that there is some device in that slot on that bus.
• FDO (Functional Device Object) - This device object is created by the “real” driver; that is, the driver typically provided by the hardware’s vendor that understands the details of the device intimately.
• FiDO (Filter Device Object) - These are optional filter devices created by filter drivers.

The Plug & Play (P&P) manager, in this case, is responsible for loading the appropriate drivers, starting from the bottom. （从底向上创建）There are at least two layers - PDO and FDO, but there could be more if filters are involved.

WHLK测试

https://learn.microsoft.com/en-us/windows-hardware/test/hlk/

• 要用英文版的windows server安装HLK，我的经验是，装载VM虚拟机里面，如果装在物理机里面，可能会没有网卡驱动。也不要使用Hyper-V，我不知道怎么在Hyper-V中设置网络桥接。
• 安装test system的时候，路径要使用test server的hostname，不能用ip地址。
• 如果无法将machine加入pool，试试重启Studio，用admin权限启动Studio。
• 有些测试项可能牵扯到无关的设备，可将其禁用后重测。
• 测试项目的具体内容，可以通过bing搜索，在微软的官网查询到。
• 有一些manual的测试项，可能需要人工干预才能通过。(HLK Studio界面的Type列，有个小人图标)
• my case：我删除了麦克风驱动inf文件中的render（扬声器）一些内容，然后再测试，发现测试条目变少了很多。额...
• 有些测试没过，也许重来一次就OK了。
• HLK测试环境与使用UKey做签名的环境。签名环境安装Studio不需要windows server版本，不需要装controller，可以分开。

本文链接：https://cs.pynote.net/sf/win/202211221/

-- EOF --

-- MORE --

• VMware虚拟机使用技巧
• Windows下用cmake和gtest问题总结
• 学习bat脚本
• Notepad++使用技巧
• 在Windows中遍历系统摄像头

CS笔记 Since 2021.9
Powered by Python & Markdown