内核编程基础：从零搭建你的驱动开发地基
说实话，很多刚接触内核开发的朋友，上来就盯着IRP、派遣函数这些高级概念猛啃。但我个人的经验是——先把地基打牢。内核编程和用户态编程完全是两码事，数据类型、内存管理、字符串操作这些基础，如果一开始没搞明白，后面调试起来会非常痛苦。
我记得第一次写驱动时，就因为一个UNICODE_STRING的初始化问题，蓝屏了一整个下午。嗯，从那以后，我对这些基础内容再也不敢马虎了。今天我们就来系统地梳理一下这些必备知识。
一、内核数据类型——别再用int了
在用户态写代码，int、long、char随便用，大不了出个警告。但在内核里，这么干就是给自己挖坑。为什么？因为内核代码需要跨平台、跨架构（x86、x64、ARM），不同平台上基本类型的大小可能不一样。
我见过最典型的翻车现场：有人用int存指针，结果在64位系统上直接截断了高32位，蓝屏得莫名其妙。
Windows内核定义了一套明确的数据类型，说白了就是告诉你：这个变量应该多大、干什么用的。
| 数据类型 | 长度（x64） | 说明 |
|---|---|---|
| UCHAR / CHAR | 1字节 | 无符号/有符号字符 |
| USHORT / SHORT | 2字节 | 无符号/有符号短整型 |
| ULONG / LONG | 4字节 | 无符号/有符号长整型 |
| ULONG64 / LONGLONG | 8字节 | 64位整型 |
| PVOID / HANDLE | 8字节 | 指针/句柄 |
| NTSTATUS | 4字节 | 返回状态码 |
| BOOLEAN | 1字节 | 布尔值（TRUE/FALSE） |
二、NTSTATUS返回值——驱动函数的"交通信号灯"
每个内核函数几乎都会返回一个NTSTATUS值。它不只是一个成功/失败的标志，还包含了丰富的错误信息。你想想看，如果驱动加载失败，你只知道"失败了"，那排查起来得多费劲？
NTSTATUS的结构是这样的：高两位表示严重性（成功、信息、警告、错误），中间是设施代码，低16位是具体状态码。
常用的几个：
- STATUS_SUCCESS（0x00000000）——一切正常
- STATUS_UNSUCCESSFUL（0xC0000001）——通用失败
- STATUS_INVALID_PARAMETER（0xC000000D）——参数不对
- STATUS_BUFFER_TOO_SMALL（0xC0000023）——缓冲区太小
- STATUS_ACCESS_DENIED（0xC0000022）——访问被拒
// 典型用法
NTSTATUS MyDriverFunction(PDEVICE_OBJECT DeviceObject, PIRP Irp)
{
// 检查参数
if (DeviceObject == NULL || Irp == NULL)
{
return STATUS_INVALID_PARAMETER;
}
// 执行操作...
return STATUS_SUCCESS;
}三、内核字符串操作——UNICODE_STRING是主角
在内核里，字符串操作和用户态完全不同。Windows内核默认使用Unicode，而且字符串不是简单的以NULL结尾的字符数组。内核用UNICODE_STRING结构体来管理字符串。
typedef struct _UNICODE_STRING {
USHORT Length; // 字符串当前长度（字节数）
USHORT MaximumLength; // 缓冲区最大长度（字节数）
PWCH Buffer; // 指向宽字符缓冲区的指针
} UNICODE_STRING, *PUNICODE_STRING;为什么不用普通的wchar_t*？因为内核需要知道字符串的实际长度和缓冲区大小，这样才能安全操作，防止缓冲区溢出。你想想看，如果驱动里字符串操作出了溢出，那可不是程序崩溃那么简单，而是直接蓝屏给全系统看。
常用的字符串操作函数：
- RtlInitUnicodeString——初始化UNICODE_STRING
- RtlCopyUnicodeString——复制字符串
- RtlAppendUnicodeToString——追加字符串
- RtlUnicodeStringToInteger——字符串转整数
UNICODE_STRING usDeviceName;
WCHAR wszBuffer[256];
// 初始化
RtlInitUnicodeString(&usDeviceName, L"\\Device\\MyDevice");
// 或者自己管理缓冲区
usDeviceName.Buffer = wszBuffer;
usDeviceName.MaximumLength = sizeof(wszBuffer);
usDeviceName.Length = 0;
// 安全地复制
RtlCopyUnicodeString(&usDeviceName, &anotherString);四、内存分配与释放——内核里没有free()
用户态用malloc/free，内核里用ExAllocatePoolWithTag和ExFreePool。而且，内核内存分两种类型：
- NonPagedPool——非分页内存，任何时候都能访问，但比较宝贵
- PagedPool——可分页内存，可能被换出到磁盘，不能在DISPATCH_LEVEL及以上IRQL使用
我个人习惯：驱动初始化时，能用PagedPool就用PagedPool，节省非分页内存。但中断处理函数里必须用NonPagedPool。
// 分配内存
PVOID pBuffer = ExAllocatePoolWithTag(
NonPagedPool, // 内存类型
1024, // 大小（字节）
'TAG1' // 标签，用于调试
);
if (pBuffer == NULL)
{
// 内存不足
return STATUS_INSUFFICIENT_RESOURCES;
}
// 使用内存...
// 释放内存
ExFreePool(pBuffer);
pBuffer = NULL; // 好习惯，防止野指针五、链表与数据结构——LIST_ENTRY的妙用
内核里最常用的数据结构就是双向链表，用LIST_ENTRY实现。它不像用户态那样把链表指针放在结构体里，而是把LIST_ENTRY嵌入到你的结构体中。这种设计非常灵活，一个结构体可以同时属于多个链表。
// 定义自己的结构体
typedef struct _MY_DEVICE_EXTENSION {
// 其他成员...
LIST_ENTRY ListEntry; // 链表节点
ULONG DeviceId;
// ...
} MY_DEVICE_EXTENSION, *PMY_DEVICE_EXTENSION;
// 初始化链表头
LIST_ENTRY g_DeviceListHead;
InitializeListHead(&g_DeviceListHead);
// 插入节点
PMY_DEVICE_EXTENSION pDevExt = ...;
InsertHeadList(&g_DeviceListHead, &pDevExt->ListEntry);
// 遍历链表
PLIST_ENTRY pEntry;
for (pEntry = g_DeviceListHead.Flink;
pEntry != &g_DeviceListHead;
pEntry = pEntry->Flink)
{
PMY_DEVICE_EXTENSION pCurrent =
CONTAINING_RECORD(pEntry, MY_DEVICE_EXTENSION, ListEntry);
// 处理pCurrent...
}这里有个关键宏——CONTAINING_RECORD。它通过结构体中某个成员的地址，反推出整个结构体的起始地址。说白了就是：我知道你口袋里有一块钱，通过这一块钱的位置，我能算出你整个人站在哪里。
嗯，以上就是内核编程基础的核心内容。数据类型选对、返回值判断准、字符串操作安全、内存管理严谨、链表用得溜——这五点做到了，你的驱动开发之路就稳了一大半。剩下的，就是在实践中不断积累经验了。