[原创] 开源一个 NTFS 卷过滤还原驱动 ——基于写时重定向，含设计取舍与性能优化记录-编程技术-看雪安全社区

# SysRestoreDriver：基于写时重定向的 NTFS 卷过滤还原驱动设计与实现

## 〇、前言

这是一个 Windows 内核态卷过滤驱动，做的事情是：**开启保护后，系统盘上任何写入都会被悄悄重定向到空闲扇区。重启之后，磁盘自动回到保护开启时的样子。** 类似网吧/教室那种还原卡，只是纯软件实现，没有任何硬件介入。

核心机制叫"写时重定向"（copy-on-write redirection），关键的取巧之处是：**`$Bitmap` 本身也被驱动重定向了，所以它在物理磁盘上永远是保护开启那一刻的快照**——这意味着不用自己维护空闲扇区表，直接读 `$Bitmap` 就行。

没有第三方依赖，纯 WDK，Apache License 2.0。配套有一个 MFC 用户态管理程序 `QHEngineUI`，把 `.sys` 和 `.inf` 作为资源嵌入 exe，一键安装、勾选要保护的卷、开启/关闭保护。

本文记录设计取舍、几次大的方案推翻、写完后跑 CrystalDiskMark 才发现的真正瓶颈、以及一些我事后觉得有意思的小坑。

**github开源链接：<a href="elink@eabK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6I4K9r3g2F1j5$3!0V1k6i4u0Q4x3V1k6e0P5i4y4d9k6i4y4@1L8%4u0W2c8s2u0A6N6X3g2J5">SysRestoreDriver</a>**（Apache License 2.0）

---

## 一、项目定位

适用场景就那几样：网吧 / 教室 / 图书馆 / 展会样机、本地软件试用沙箱（装一堆软件、改注册表、删系统文件，重启即清）、给家里老人小孩的机器防误操作。

仅支持 NTFS。目前在 Win10 22H2 和 Win11 23H2 上实测通过，包括"正常写入后重启"、"异常断电模拟后重启"、"开关保护重启循环"三组场景。Win7 / Win8 / Win8.1 理论兼容，但没测。

---

## 二、驱动在设备栈中的位置

![设备栈位置](upload/attach/202606/1079562_UX9F8HQ7WTH6RFM.webp)

选择卷过滤而不是文件过滤（minifilter），原因很直接：**minifilter 拦不到 NTFS 元数据的写入**。`$Bitmap`、`$MFT` 这些元数据被 NTFS 内部更新时不会产生文件级 IRP，minifilter 完全无感。而卷过滤位于 NTFS 文件系统的下层，所有块级写入都要经过——这恰恰是还原驱动需要的"全覆盖"。

驱动注册为 Volume Upper Filter（`FilterClass = Volume`），系统挂载任何 NTFS 卷时，自动 attach 一个过滤设备上去。每个卷独立判断是否开启保护：根目录有 `_qh_protect_state.data` 且首字节 = 1 才激活，否则一律透传。

---

## 三、核心机制：写时重定向

![写时重定向机制](upload/attach/202606/1079562_Z3TXHBEMM9GVXQR.webp)

机制本身两句话能讲明白：

1. 用户写扇区 X → 驱动从空闲扇区池里挑一个 Y → 实际写到 Y，内存里记一笔 `X → Y`
2. 后续读 X → 查内存表，得到 Y → 实际读 Y → 应用看到的是新数据

但真正让这套设计成立的，是**第三件事**：**`$Bitmap` 自己也被驱动重定向。**

这个观察看着不起眼，但它解决了所有难题。NTFS 看到的空闲扇区表（也就是 `$Bitmap`），从保护开启那一刻起就再也不会被真实改写——所有对它的写入都被重定向到别处了。所以**物理磁盘上的 `$Bitmap`，就是保护开启时刻的快照**。重启之后，驱动重新挂载、内存表全部丢失、NTFS 重新读盘——读到的就是那张快照，整个文件系统瞬间回到保护开启那一刻。

那些重定向期间被分配到的目标扇区（Y、W、…），数据虽然还物理存在于磁盘上，但 NTFS 的 `$Bitmap` 把它们标为空闲，后续写入会自然覆盖。无需任何"提交"或"清理"步骤。

---

## 四、关键设计决策

> 这一节是整篇的重点。每个决策都讲：**最初想法 → 演变过程 → 最终方案 → 变化原因**。少数地方我花了不短的时间才想明白，过程值得记录。

### 4.1 位图管理：从"自己维护"到"复用 NTFS `$Bitmap`"

最初的设想是：自己维护一张空闲扇区位图。200GB 的 C 盘按 512B 扇区算，约 4 亿位，需要 35MB 内存——这个量级勉强能接受。但如果是 2TB 卷呢？350MB。20TB 呢？3.5GB。内存条不够的用户立马蓝屏。

于是又退一步：把位图写到磁盘扇区里，需要时局部读取。但这立刻引出另一个问题——**位图自己也是写操作的对象**，每次更新位图都要触发新的 IRP，多次扇区读写会把性能打到地板上。

转折点是反向思考的一句话：**既然 `$Bitmap` 也被我重定向了，它在磁盘上就永远是保护开启时刻的状态。那它本身就是一张天然的、不会被污染的空闲扇区位图——为什么要再自己造一张？**

所以最终方案是：驱动启动时把 `$Bitmap` 的簇级位图从磁盘读出来，在内存里展开成扇区级 `SectorBitmap`。1TB 卷约 256MB，从 NonPagedPool 分配（IRP 派遣可能在 DISPATCH_LEVEL 触达，必须不可分页）。

这一步本质上是"借力打力"——NTFS 自己已经在维护一份高度优化的空闲扇区数据结构，去复用它，而不是再造一份。

### 4.2 位图实现：基于 RTL_BITMAP 的薄包装

`SectorBitmap` 用 Microsoft 公开的 `RTL_BITMAP` 系列 API 做了一层薄包装 `QH_BITMAP`。选 `RTL_BITMAP` 的几个理由：

- **代码量极小**。`Create / Set / Test / FindNextClear` 全部直接转发给 `RtlSetBit` / `RtlClearBit` / `RtlCheckBit` / `RtlFindClearBits`。后者自带 wrap-around 语义——找不到清零位时会自动从位图头部再扫一遍，省掉上层一段"找不到则再来一次"的兜底代码。
- **容量足够**。`RTL_BITMAP` 用 `ULONG` 索引，单张位图上限约 4G 位。512B 扇区下对应约 2TB 卷，4KB 扇区下约 16TB，覆盖绝大多数系统盘 + 数据盘场景。若未来需要超大卷，可以在 `QH_BITMAP` 层内部再加稀疏分槽，上层接口不变。
- **官方 API，行为可信**。位操作本身极容易写错，能用官方实现就用官方实现。

### 4.3 偏移记录表的数据结构：从 khashl 到 RTL_GENERIC_TABLE

`(原始扇区 → 重定向目标扇区)` 这张映射表的数据结构，最初执着于"必须 O(1) 查找的哈希表"——毕竟读写 IRP 路径上每个扇区都要查一次。

第一步尝试把 klib 的 `khashl.h` 移植到内核态。klib 是一套头文件唯一的轻量 C 库，理论上"应该"能移植，毕竟它不依赖 libc。我花了不少时间适配（替换内存分配、去除标准库依赖），跑起来后却频繁卡死——具体原因到最后也没完全定位，但稳定性问题在内核里是绝对的红线。

退而求其次，改用 `RTL_GENERIC_TABLE`——基于 Splay 树，O(log N) 查找。两个理由：

- **Splay 树有"热点旋根"的局部性优化**。频繁访问的节点会被旋转到根附近，实际负载下单次查找接近 O(1)。
- **Microsoft 官方 API，行为有保证**。考虑到这个表的查找在 IRP 慢路径上每个扇区都要查一次，"快但偶尔崩"远不如"略慢但永远稳"。

剥离 klib 还有个意外收益——许可证清洁度。klib 是 MIT，并不冲突，但少一个第三方依赖等于少一份审计成本。最终代码库零第三方依赖，纯 WDK。

未来计划在稳定之后自实现 per-bucket 锁的开链哈希表，但那是后话。

### 4.4 映射粒度：从簇级到扇区级

最初按簇做映射：原始簇 → 重定向簇。这是直觉上最自然的选择——NTFS 的最小分配单元就是簇，元数据全部是按簇组织的。

实际跑起来才意识到一个问题。NTFS 的簇默认 4KB（8 个 512B 扇区）。考虑一个簇里只有部分扇区被使用的场景——比如 `_ _ * _ * * _ _`（`*` 表示被使用，`_` 表示空闲）。如果按簇重定向，写其中任一扇区都要：

1. 把原簇 8 个扇区全部读上来
2. 修改其中要改的几个扇区
3. 把整个 8 个扇区写到重定向目标簇

**每次小写入都多一次完整的簇读 IO**。CDM 跑下来性能直接砍半，这是灾难性的。还原驱动的卖点本来就是"开了保护不会显著变慢"，如果开了之后性能砍半，这个产品的使用价值就没了。

改成扇区级映射后，IRP 范围有多少扇区就操作多少扇区，精确匹配，无谓拷贝。代价是偏移表条目变多——按簇 1 条记录变成按扇区最多 8 条——但 Splay 树的 O(log N) 查找完全吃得消，内存增长也可控。

### 4.5 保护状态持久化方案的设计权衡

这是整个项目里我反复推翻自己最多的一个点。问题本身简单：**驱动启动时怎么知道"上次有没有开启保护"？** 但因为驱动会重定向所有写入，常规的"在某处存个标志位"全都行不通。

#### 推翻一：注册表

第一个直觉是注册表。用户态在 `HKLM\SYSTEM\...\Services\SysRestoreDriver\` 下记一个值，驱动启动时读。

问题瞬间冒出来：**用户在保护开启状态下关闭 D 盘保护，他对注册表的写入会被驱动重定向**。也就是说，他把注册表里的"D 盘开启保护"删了，但这个删除操作实际写到了某个空闲扇区。重启之后，物理磁盘上的注册表 hive 文件**根本没被改过**——D 盘依然被认为是开启保护的。

试图绕过：能不能"暂停重定向"，让那次注册表写入直通磁盘，然后恢复重定向？理论上可以，但要解决的问题一堆：

- 注册表的写入可能被文件系统缓存延后
- 暂停期间如果有其他注册表写入并发怎么办
- 注册表 hive 文件在磁盘上的物理位置怎么算

每一个都不是小工程。这条路放弃。

#### 推翻二：再写一个 minifilter 通信

退而想：写第二个驱动，一个文件过滤系统（minifilter），它能感知文件级 IO。在用户态修改注册表时，minifilter 拦截到、计算这条注册表项落在哪个物理扇区、通过共享内存通知卷过滤驱动"这个扇区放行不要重定向"。

听起来不错，写起来全是雷：

- minifilter 算物理扇区需要打开文件 → 查 extent → 算 LCN → 算物理偏移，**这事情本身就容易出错**
- 一个扇区 512B，可能装多条记录，**万一并发写到同一扇区其他位置怎么办**
- 跨驱动通信的同步原语，又是一坨复杂度

而且核心矛盾没解决：**这么复杂的机制，仅仅是为了存"开 / 关"这一个 bit**。这就跟为了拧一颗螺丝去造一台机床一样。

#### 推翻三：注册表 + 自定义扇区

又想：用户态软件安装时，在 NTFS 空闲簇里挑一个扇区，把那个扇区号写注册表。这个扇区由驱动直接读写，不经过文件系统。

问题更隐蔽，等想清楚已经晚了：**NTFS 不知道这个扇区被驱动私自占用了**。下次启动时，文件系统可能已经把这个扇区分配给某个文件、写了新数据，驱动按记录的扇区号去读，读到的是文件内容——保护状态判断完全错乱。

#### 最终方案：ProtectRanges + 卷根目录状态文件

最后想通的方案，反而是最朴素的：**在卷根目录创建一个固定大小的隐藏文件 `_qh_protect_state.data`**，1MB 大小，首字节存 1/0 表示开 / 关。

关键设计：**这个文件的所有物理扇区被驱动加入 `ProtectRanges`（直写放行扇区区间表），读写时直通真实磁盘，绕过重定向。**

`ProtectRanges` 是一个 init 阶段一次性填充、之后只读的静态小数组（嵌入 `DEVICE_EXTENSION`，上限 8 段，实际仅占 3-4 段），IRP 路径上无锁线性扫描。它的填充流程：

1. UI 开启保护时创建状态文件，写首字节 1
2. 驱动启动时通过 `FSCTL_GET_RETRIEVAL_POINTERS` 拿到文件的所有 extent
3. 把这些 extent 对应的扇区追加到 `ProtectRanges`

由此达成的几个不变量：

- **文件由 NTFS 真实管理**，所以 NTFS 不会重新分配这些扇区给别人
- **文件的扇区在 `ProtectRanges` 里**，UI 写首字节时直通真实磁盘，重启后驱动能读到真实值
- **驱动初始化期间**（`Initialized == FALSE`），所有 IRP 走默认透传，`ZwReadFile` 读到的是真实磁盘内容
- **文件大小 1MB**，强制 NTFS 走非驻留存储——驻留属性的阈值约 700B，如果文件太小数据会直接塞进 MFT 记录，那 `ProtectRanges` 标的"文件扇区"会落到 MFT 内部，整个机制崩塌

完全不依赖注册表。

#### 一个连带的好处：解决 NTFS dirty flag 问题

`ProtectRanges` 的机制不只用于状态文件。还有一个隐蔽的坑：**NTFS 的 `$Volume` 元数据（MFT 记录 #3）维护着 dirty flag**，干净关机时 NTFS 会清这个 flag。如果这个写入被重定向，物理磁盘上的 dirty bit 永远停在保护开启那一刻。**几次重启后，Windows 累计判定"未干净关机"，会触发 WinRE 修复模式**。

解决方法很对称：把 MFT #3 主区与 `$MFTMirr` 的对应镜像两个扇区也加入 `ProtectRanges`。一共两段，再加状态文件的一两段，总数不超过 4 段，远在 8 段上限之内。

#### 一个反向决策：为什么不把 pagefile.sys / hiberfil.sys 加进去

早期版本试过把 `pagefile.sys` / `hiberfil.sys` / `bootstat.dat` 也加入直写放行——理由直觉上很合理，这些都是系统关键文件，被拦截会带来麻烦。

测试时却没人察觉到一个关键问题：**这些文件可能在保护期间被用户态动态扩缩容**。`pagefile.sys` 尤其严重，Windows 在内存压力下会自动伸缩页面文件大小。新分配的扇区不在已快照的 `ProtectRanges` 里，写入会被驱动重定向 → 系统后续读 pagefile 时读到错位数据 → **蓝屏或更糟**。

所以最后的规则很简单：**`ProtectRanges` 只收录扇区位置在保护期间永远不变的实体**。状态文件 1MB 固定不动，MFT 元数据物理位置由文件系统固定分配——这两类是安全的。其他系统文件一概不放，宁可它们走重定向。

### 4.6 驱动初始化时机：从 IOCTL_VOLUME_ONLINE 到 BootDriverReinitialization

最初的初始化点选在 `IOCTL_VOLUME_ONLINE` 控制码处理函数里——这个 IOCTL 是 mount manager 在卷上线时发的，听起来就是"卷已经上线，可以初始化了"。

实测下来发现一个严重问题：**`IOCTL_VOLUME_ONLINE` 到达时，NTFS 不一定已经挂载完毕**。状态文件需要通过 `ZwCreateFile` 打开 → 必须等 NTFS 就绪 → 此时打开会失败。

研究后改用 `IoRegisterBootDriverReinitialization` 注册的回调。这个回调由系统保证在**所有 Boot 驱动加载完成**后调用，意味着 NTFS 必然已经挂载——是文件操作的最早安全时机。

对于动态插拔介质（U 盘等），仍然走 `IOCTL_VOLUME_ONLINE` 路径执行初始化（因为它们不在 Boot 驱动列表里），但要等 `BootReinitDone == 1` 后才允许激活保护，防止系统盘还没初始化完就先启动 U 盘的保护。

### 4.7 文件删除导致空间萎缩问题的权衡

写完核心机制后才意识到一个隐患。考虑这个场景：

1. 保护开启，空闲扇区 Z，原始扇区 X 被写入 → 驱动重定向 X → Z
2. NTFS 仍然认为 Z 空闲，把 Z 分配给某个新文件 → 写入 Z 触发驱动重定向 Z → W
3. 这个文件后来被删除，NTFS 把 Z 在 `$Bitmap`（重定向视图）里标为空闲
4. **但驱动并不知道"Z 又空闲了"**——它仍然把 Z 视为 X 的重定向目标占用着
5. 时间长了，越来越多 Z 这样的扇区"脱离空闲池"，重定向空间不断萎缩

理论上这是个 bug。最稳的解法是写一个 minifilter 拦截文件删除 IRP，拿到文件的 extent 表，发自定义 IOCTL 通知卷过滤驱动"这些扇区释放了，可以从偏移表里删掉"。

权衡之后**当前版本不处理**。理由：

- 触发这个问题需要**对已经被重定向保护的数据持续大量修改**，**同时配合大量删除操作**。真实场景里保护期间的写入量本身就有限
- 多写一个 minifilter 引入跨驱动通信，复杂度和不稳定性风险大幅上升
- 目标场景是网吧 / 教室——这些机器单次保护期内写入量小、生命周期短（每天重启）

这是已知限制，写在 README 里。如果未来真有用户反馈空间耗尽，我也不打算再补 minifilter了，到时候添加一个定时自检空闲剩余空间(检查$Bitmap)，然后更新偏移表，让出空闲空间的工作项即可，但是需要注意的是这个工作项可能会有性能问题，因为它 **遍历 + 删除** 偏移表和空闲扇区记录表项，所以必须在被保护磁盘空间即将耗尽时调用。

---

## 五、核心数据结构

### 5.1 扇区位图 + 直写放行区间表

| 结构 | 含义 | 来源 |
|---|---|---|
| `SectorBitmap`（`QH_BITMAP` 薄包装） | 扇区级占用位图（0=空闲, 1=占用） | 从 `$Bitmap` 簇级位图展开 |
| `ProtectRanges[8]`（嵌入 `DEVICE_EXTENSION`） | 直写放行扇区区间（状态文件 + `$Volume` MFT#3 主/镜） | `QHPopulateProtectRanges` 初始化时填充，IRP 路径无锁只读 |

### 5.2 偏移记录表（重定向映射表）

- **实现**：`RTL_GENERIC_TABLE`（Splay 树，O(log N) 查找）
- **键**：原始扇区索引 → **值**：重定向后的扇区索引
- **用途**：读 / 写路径直接查表。命中即取目标扇区，未命中即按原位置处理

### 5.3 设备扩展核心字段

```c
typedef struct _QH_DEVICE_EXTENSION
{
    BOOLEAN              Initialized;              // 是否已激活保护
    PDEVICE_OBJECT       LowerDeviceObject;        // 下层设备
    PDEVICE_OBJECT       PhysicalDeviceObject;     // PDO
    QH_NTFS_BOOT_SECTOR  NtfsBootSector;           // 卷的引导扇区
    PQH_BITMAP           SectorBitmap;             // 扇区占用位图
    QH_PROTECT_RANGE     ProtectRanges[8];         // 直写放行区间(无锁)
    ULONG                ProtectRangeCount;
    ULONG                LastScanIndex;            // 加速 FindClearBits 起点提示
    FAST_MUTEX           BitmapMutex;
    PQH_OFFSET_HASH      OffsetHash;               // 偏移记录表
    FAST_MUTEX           OffsetHashMutex;
    KSPIN_LOCK           PendingIrpQueueLock;
    LIST_ENTRY           PendingIrpQueue;
    PIO_WORKITEM         IoWorkItem;
    // ...
} QH_DEVICE_EXTENSION;
```

注意 `ProtectRanges` 是**静态嵌入**而不是指针——它在 init 阶段一次性填充、之后只读，IRP 路径上的 `QHIsSectorProtected` 完全无锁，省掉一对 mutex 切换。

---

## 六、写 IRP 处理流程

![写IRP处理流程](upload/attach/202606/1079562_TNTQ39268MFFCYW.webp)

写路径是整个驱动里最复杂的部分。按流程图节点逐步讲解：

**步骤 1-3：早期过滤**
- 未初始化 → 透传到下层设备
- 当前 IRQL > `PASSIVE_LEVEL` → 排入工作项队列稍后处理（`ZwCreateFile` 等 NTFS 文件 API 要求 `PASSIVE_LEVEL`）
- 引导扇区写保护：偏移 < `BytesPerSector` 直接返回 `STATUS_ACCESS_DENIED`。理由——引导扇区被改了就启动不了，没有任何合法理由让保护期间的应用程序去碰它

**步骤 4：范围短路（fast-path）**

这是一个性能关键的优化。绝大多数写 IRP 要么整段命中 `ProtectRanges`（状态文件 / MFT 元数据），要么整段落在空闲扇区上（新文件分配）。这两种情况都不需要重定向，直接透传就行。

慢路径每次进入要 `qhalloc(Length)` 分配一个 1MiB 的缓冲区 + `RtlCopyMemory` 拷贝用户数据——这两步开销很大。fast-path 用 `RtlAreBitsClear` 和 `QHAreSectorsProtected` 两次扫描判断整段是否符合条件，省掉这一大块开销。

实测净收益 +5% 写性能。听起来不多，但代码只有 30 行，风险也小，留下了。

**步骤 5-6：慢路径分类处理**

每个扇区分三种情况：

1. **命中 `ProtectRanges`** → 写原始位置（状态文件、MFT 元数据直通）
2. **`SectorBitmap` 显示空闲** → 标位 + 写原始位置（这扇区 NTFS 视图里就是空的，重启后 `$Bitmap` 复原即丢弃）
3. **已占用扇区** → 在 `OffsetHashMutex` 内**原子完成**"查表 → 命中即写目标 / 未命中则分配新空闲扇区 + 写哈希表"

第 3 种情况的并发安全很关键。如果把"查 hash"和"分配 + 写 hash"拆到两段不同的锁里，两个并发写同一扇区的 IRP 会各自判定"未命中"、各自分一个新扇区、各自写 hash、后写的覆盖前写的——结果一份数据落在前一个扇区永久泄露，hash 表只指向后一个扇区，**前一个 IRP 的数据永久丢失**。

锁顺序约定：`OffsetHashMutex` 外，`BitmapMutex` 内。全代码库无反向嵌套，无死锁风险。

**步骤 7：合并连续 IO**

逐扇区生成的物理写入如果在磁盘上连续，合并成一次大 IO 下发。`LastScanIndex` 的提示策略让连续写拿到的重定向目标也是连续的，所以这一步通常能把 IO 数量降到接近 1。

---

## 七、读 IRP 处理流程

![读IRP处理流程](upload/attach/202606/1079562_HNYHXGMQ6NJJ882.webp)

读路径比写路径简单一截：

**与写路径的关键差异**：
- **没有引导扇区保护**——读引导扇区合法
- **没有"首次重定向"分支**——读不创建新映射，未命中就是按原位置读
- **慢路径只有 3 类分支**：`ProtectRanges` 命中 / `OffsetHash` 命中 / `OffsetHash` 未命中
- **末尾多一步 `RtlCopyMemory`**：把从独立缓冲区读到的数据拷回原 IRP 缓冲区（用独立缓冲区是为了避免原始 MDL 与自建 IRP 的 MDL 同时锁定同一物理页，避免 PFN_LIST_CORRUPT）

读路径有个 fast-path：快速扫描整段范围，**只要有任一扇区没有重定向，就走慢路径**。其实更严格地说，只有"整段无重定向"才能直接透传。但这个扫描本身要逐扇区查 `OffsetHash`，在 SEQ Q1 这种大块顺序读的场景下，1MiB / 4KiB = 256 个扇区每个都要查一次 Splay 树——这是读路径性能损失的主要来源（SEQ Q1 约 −41%）。

权衡之后还是保留了这个 fast-path，因为绝大多数顺序读都是无重定向的，不能让所有读都走慢路径分配独立缓冲区。

---

## 八、重启还原的机制

机制本身在第三节已经讲过，这里补一点细节性的观察。

重启之后会发生这几件事，按顺序：

1. 驱动重新挂载，**内存中的 `SectorBitmap`、`ProtectRanges`、`OffsetHash` 全部丢失**（这些都是 `NonPagedPool` 分配的，关机即销毁）
2. NTFS 重新挂载卷，**重新从磁盘读取 `$Bitmap`、`$MFT`、`$Volume` 等元数据**
3. 由于这些元数据自保护开启起从未被真实修改过（写入全被驱动重定向了），NTFS 读到的就是**保护开启那一刻的快照**
4. 整个文件系统视图回到那一刻——文件、目录、空闲空间都一致

那些重定向期间被分配出去的目标扇区，物理上仍然在磁盘上保留着数据。但因为 `$Bitmap` 把它们标为空闲，NTFS 后续的写入会自然覆盖它们。**无需任何主动的"清理"或"提交"步骤**——这正是 COW redirect 相比 COW copy 优雅的地方。

---

## 九、性能数据

在 Win10 22H2 / NVMe SSD / 60GB 系统盘上用 CrystalDiskMark 8.0.4 实测（1 GiB × 5 轮）：

| 项目 | 保护关闭 | 保护开启 | 变化 |
|---|---|---|---|
| SEQ Q8 1MiB **Read** | 1753 MB/s | 1510 MB/s | −14% |
| SEQ Q1 1MiB **Read** | 1170 MB/s | 685 MB/s | **−41%** |
| RND Q32 4KiB **Read** | 18.3 MB/s | 18.5 MB/s | +1%（噪声） |
| RND Q1 4KiB **Read** | 11.2 MB/s | 10.8 MB/s | −4% |
| SEQ Q8 1MiB **Write** | 673 MB/s | 436 MB/s | −35% |
| SEQ Q1 1MiB **Write** | 916 MB/s | 373 MB/s | **−59%** |
| RND Q32 4KiB **Write** | 19.2 MB/s | 10.1 MB/s | −47% |
| RND Q1 4KiB **Write** | 10.9 MB/s | 10.2 MB/s | −6% |

几个观察：

- **读路径**：低队列深度顺序读损失最大（SEQ Q1 约 −41%），瓶颈在逐扇区查 Splay 树。高队列深度因为并发掩盖了单次查询延迟，损失收敛到 −14%
- **写路径**：顺序大块写约 −35%，瓶颈在防御性的 1MiB `qhalloc` + `memcpy` + 每段 IO 的同步等待
- **小 IO 几乎无损**：Q1 4KiB 读写均 < 6%

没对比同类商业方案（Deep Freeze / PowerShadow 等）。这些厂商不公布基准数据，第三方独立评测也极少，没有可信参照。如果读者手头有可复现的对比数据，欢迎反馈。

---

## 十、性能优化探索记录

这一节是写完核心功能后调优阶段的真实记录。试过的几条路里只有一条留下了，其他全撤了——记录一下，免得有同样想法的人重走一遍。

### 10.1 留下的：写入口范围短路（+5%）

就是第六节讲的 fast-path。写 IRP 一进来先用 `RtlAreBitsClear` + `QHAreSectorsProtected` 看一眼整段是不是要么整段在 `ProtectRanges` 里，要么整段空闲。命中其一就直接透传，省掉 1MiB `qhalloc` + `memcpy` 和慢路径的逐扇区循环。

实测只有 +5%，比想象的少很多——大多数 CDM 测试场景下整段空闲的命中率其实不高（CDM 会先把测试文件预分配好，第二轮起所有扇区都已经被占用了，走的全是慢路径）。但代码简单、风险低、留下。

### 10.2 试过但撤回的

**读路径范围短路**：想法跟写路径对称——整段都没重定向就直接透传。结果 SEQ Q1 Read 反而退化 5–11%，没完全搞清楚原因，可能是 `QHHashGet` 大范围扫一遍比按需逐扇区还慢？读本来损失就只有几个百分点，不值得为这点不确定性引入修改，撤了。

**慢路径锁合并**：每个扇区原本要抢 3-4 次 mutex（`BitmapMutex` 测占用 → 释放 → `OffsetHashMutex` 查 hash → 释放 → ...），合并成一次大临界区。理论上应该有提升，结果 CDM 测下来完全没变化。`FAST_MUTEX` 在这台 NVMe 上太便宜了，锁切换根本不是瓶颈。徒增代码复杂度，撤。

**异步 IO 流水线**：这是花时间最多的一条。写了批次结构、完成例程、引用计数、槽位限流（`MAX_INFLIGHT=16`），目标是让一个写 IRP 里的多个段并发跑——理论上能把总延迟从 `sum(每段)` 压到 `max(每段)`。

实测 +5%。为啥这么少？因为 `LastScanIndex` 让连续写拿到的重定向目标也是连续的，IO 合并之后通常就剩 1 段，根本没东西可以并发。CDM 这种"预分配 + 反复重写同一段"的负载特别坑这个优化。

不是说这条路死了。"解压一堆小文件"这种天然多段的负载可能还有用，但要专门做稳定性测试才敢上，CDM 测不出来就先撤了。

### 10.3 几个事后想明白的事

**CDM SEQ 写不能代表所有写负载**。它的特点决定了控制流优化基本没用：1MiB 大块 → IO 合并几乎完美；文件预分配 + 5 轮重写 → 第二轮起全走慢路径；重定向目标连续 → 物理上还是顺序写。

**真正的瓶颈不在控制流**。剩下的延迟里大头是：
- 防御性的 1MiB `qhalloc` + `memcpy`
- 慢路径下发 IO 时 `IoCallDriver + KeWaitForSingleObject` 同步等待

这两个不动，光优化锁和分支没意义。

**防御性缓冲区不能动**。试过去掉那个 `qhalloc + RtlCopyMemory`，直接把父 IRP 的 MDL 系统地址传给下层——蓝屏。这条路堵死了，别再试。

### 10.4 还没试的方向

留给以后或者社区贡献者：

- **per-bucket 锁的开链哈希表**替掉 Splay 树。理论上对并发写更友好，但 CDM 单线程测不出区别
- **ERESOURCE 替掉 FAST_MUTEX**，让位图支持多读并发，Q8 多线程读可能受益
- **真正的 IRP 流水线异步模型**——工程量很大，没 WinDbg 这种调试设备就别开始

---

## 十一、已知限制与未来规划

### 限制

- **仅支持 NTFS**。FAT32 / exFAT 暂不支持（解析不了 `$Bitmap`）
- **未处理文件删除导致的空间萎缩**（详见 4.7 节）
- **状态文件可被用户手动删除**——删除等同关闭保护，目前未做防删监控
- **Splay 树是临时方案**，查找性能非最优

### 规划

- 自实现高性能内核态哈希表替换 `RTL_GENERIC_TABLE`
- minifilter 监控状态文件防误删
- 评估对 FAT32 / exFAT 的支持

---

## 十二、源码与协议

- **GitHub**：<a href="elink@f09K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6I4K9r3g2F1j5$3!0V1k6i4u0Q4x3V1k6e0P5i4y4d9k6i4y4@1L8%4u0W2c8s2u0A6N6X3g2J5"><mark class="encrypted">072K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6I4K9r3g2F1j5$3!0V1k6i4u0Q4x3V1k6e0P5i4y4d9k6i4y4@1L8%4u0W2c8s2u0A6N6X3g2J5</mark></a>
- **协议**：Apache License 2.0——允许商用、闭源集成、修改后再分发。无传递性依赖，集成审计零摩擦
- **反馈**：欢迎通过 GitHub Issues 提交问题、反馈与 PR

---

## 附：作者后记

写这个驱动之前，我在用户态写了 10 年 C++。这是第一次写 Windows 内核驱动。

最大的反差感是：用户态写错了，崩溃个进程；内核态写错了，崩溃整台机器。第一个 bug 花了大半天定位——栈申请几个 `WCHAR[2048]`，立刻蓝屏。后来才知道内核栈默认就 12KB，几个大数组就爆。

第二件让我吐血的事，是写完整个项目后才发现：**Windows 有官方的驱动样例集合**，挂在 <mark class="encrypted">cf1K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6E0K9h3y4J5L8%4y4G2k6Y4c8Q4x3V1k6i4K9h3&6V1L8%4N6K6i4K6u0V1k6s2u0A6N6X3g2J5i4K6u0V1M7$3q4E0M7r3I4W2M7#2!0q4x3#2)9^5x3q4)9^5x3W2!0q4y4W2)9&6y4#2!0m8z5g2!0q4y4#2)9&6c8W2!0m8y4g2!0q4z5g2)9^5x3g2)9&6x3#2!0q4y4W2)9&6b7#2)9^5z5g2!0q4z5q4!0n7c8W2)9&6z5g2!0q4y4q4!0n7z5q4!0m8b7g2!0q4c8W2!0n7b7#2)9^5b7#2!0q4z5q4)9^5y4#2!0n7x3#2!0q4y4g2!0n7x3q4)9&6x3g2!0q4z5q4)9^5x3#2!0n7c8q4!0q4y4g2!0n7x3q4)9&6x3g2!0q4y4#2!0n7b7W2)9&6y4g2!0q4y4q4!0n7z5q4)9^5x3q4!0q4y4g2!0m8y4q4!0m8y4#2!0q4y4g2)9&6b7#2)9^5z5q4!0q4x3#2)9^5x3q4)9^5x3R3`.`.</mark>

第三件是，**整个开发过程没用 WinDbg**——单纯因为不知道有这个工具。所有的内核态调试就是"出蓝屏 → 盯着代码看 → 查资料 → 改 → 再装一次"。一个 bug 平均要这样跑十几次。等项目写完才知道双机调试是怎么回事，多少有些哭笑不得。

第四件，**网上几乎没有此类驱动的开源实现可供参考**。商业的 Deep Freeze、PowerShadow、影子卫士、冰点还原都是闭源的，技术细节藏得很深。写到中段一度查资料查到绝望——`$Bitmap` 的格式、MFT 的非驻留属性 data run 解码、`FSCTL_GET_RETRIEVAL_POINTERS` 的输出语义……这些资料散在 MSDN 角落、Reactos 源码、十几年前的论坛帖子里，每一个都要拼接才能用。

如果这篇文章和这个项目能让后来想做类似驱动的人少踩几个坑，那写出来就值得了。

---

*完*

回复或点赞可查看完整内容

传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！！

最后于 2026-6-11 06:39 被encoder编辑，原因：

#系统内核 #驱动开发 #开源分享 #开发技巧 #工具脚本

上传的附件：

写时重定向机制.png （110.45kb，5次下载）
写IRP处理流程.png （141.39kb，5次下载）
设备栈位置.png （74.73kb，5次下载）
读IRP处理流程.png （132.73kb，5次下载）

最新回复 (53) 1 2 3 ▶
拍拖雪币： 2790 活跃值： (7146) 能力值： ( LV6，RANK：90 ) 在线值：发帖 22 回帖 436 粉丝 15 关注私信	拍拖 2 2 楼感谢分享 2026-6-11 11:12 0
xingbing 雪币： 158 活跃值： (5791) 能力值： ( LV2，RANK：10 ) 在线值：发帖 2 回帖 1400 粉丝 2 关注私信	xingbing 3 楼感谢分享 2026-6-11 16:15 0
zywzjn 雪币： 196 活跃值： (1162) 能力值： ( LV3，RANK：20 ) 在线值：发帖 2 回帖 33 粉丝 1 关注私信	zywzjn 4 楼感谢分享学习 2026-6-11 18:00 0
木志本柯雪币： 6578 活跃值： (8654) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 448 粉丝 9 关注私信	木志本柯 5 楼这个是不是就是影子系统那种功能？ 2026-6-11 18:24 0
encoder 雪币： 1235 活跃值： (115) 能力值： ( LV4，RANK：40 ) 在线值：发帖 1 回帖 1 粉丝 5 关注私信	encoder 1 6 楼木志本柯这个是不是就是影子系统那种功能？是的，与冰点还原、影子系统功能很相似，但是实现上更接近冰点还原，影子系统是另一套模式。 2026-6-11 18:35 0
fengyunabc 雪币： 5418 活跃值： (6237) 能力值： ( LV4，RANK：50 ) 在线值：发帖 11 回帖 634 粉丝 27 关注私信	fengyunabc 1 7 楼感谢分享。 2026-6-11 18:53 0
啊你好哇123 雪币： 799 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 378 粉丝 0 关注私信	啊你好哇123 8 楼学习学习 2026-6-11 23:23 0
KALI_MC 雪币： 31 能力值： ( LV1，RANK：0 ) 在线值：发帖 5 回帖 13 粉丝 7 关注私信	KALI_MC 9 楼 1 2026-6-13 02:29 0
mb_eizetlni 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 47 粉丝 1 关注私信	mb_eizetlni 10 楼 666 2026-6-13 06:04 0
jongan 雪币： 89 活跃值： (2343) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 39 粉丝 3 关注私信	jongan 11 楼感谢分享 2026-6-13 08:34 0
mb_qimctavn 雪币： 5329 活跃值： (6790) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 402 粉丝 1 关注私信	mb_qimctavn 12 楼 6 2026-6-13 08:40 0
option 雪币： 9440 活跃值： (4434) 能力值： ( LV2，RANK：10 ) 在线值：发帖 40 回帖 782 粉丝 4 关注私信	option 13 楼冰点还原=Deep Freeze 最后于 2026-6-13 09:16 被option编辑，原因： 2026-6-13 09:14 0
lhglhg 雪币： 221 活跃值： (3421) 能力值： ( LV4，RANK：50 ) 在线值：发帖 8 回帖 480 粉丝 5 关注私信	lhglhg 1 14 楼感谢分享 2026-6-13 17:46 0
mb_urzqsoer 雪币： 206 能力值： ( LV1，RANK：0 ) 在线值：发帖 1 回帖 121 粉丝 0 关注私信	mb_urzqsoer 15 楼牛逼 2026-6-13 23:42 0
Rookietp 雪币： 857 活跃值： (1021) 能力值： ( LV2，RANK：10 ) 在线值：发帖 5 回帖 811 粉丝 2 关注私信	Rookietp 16 楼学习下 2026-6-14 05:19 0
lovemalware 雪币： 0 活跃值： (415) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 5 粉丝 0 关注私信	lovemalware 17 楼非常支持你的观点！ 2026-6-14 09:38 0
dayang 雪币： 220 活跃值： (1291) 能力值： ( LV2，RANK：10 ) 在线值：发帖 38 回帖 954 粉丝 1 关注私信	dayang 18 楼前来学习 2026-6-14 19:33 0
hambaga 雪币： 187 活跃值： (3971) 能力值： ( LV3，RANK：20 ) 在线值：发帖 6 回帖 94 粉丝 61 关注私信	hambaga 19 楼牛逼 2026-6-14 23:09 0
wujimaa 雪币： 364 活跃值： (3117) 能力值： ( LV4，RANK：50 ) 在线值：发帖 11 回帖 211 粉丝 1 关注私信	wujimaa 1 20 楼 6666 2026-6-15 09:36 0
zxdpxl 雪币： 9 活跃值： (1460) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 49 粉丝 0 关注私信	zxdpxl 21 楼学习一下 2026-6-15 09:41 0
dx苹果的心愿雪币： 1903 活跃值： (6477) 能力值： ( LV5，RANK：70 ) 在线值：发帖 3 回帖 113 粉丝 8 关注私信	dx苹果的心愿 1 22 楼 6 2026-6-15 10:59 0
xiaofo 雪币： 6 活跃值： (443) 能力值： ( LV2，RANK：10 ) 在线值：发帖 13 回帖 130 粉丝 5 关注私信	xiaofo 23 楼 6666666666666666666 2026-6-15 17:00 0
imlym 雪币： 215 活跃值： (465) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 40 粉丝 0 关注私信	imlym 24 楼太强了，膜拜！ 2026-6-16 14:57 0
ThreadEx 雪币： 244 能力值： ( LV1，RANK：0 ) 在线值：发帖 3 回帖 48 粉丝 0 关注私信	ThreadEx 25 楼 m 2026-6-16 17:29 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复