1. 为什么还要折腾CDFS一个被忽视的驱动开发练兵场很多人一听到文件系统驱动开发第一反应就是去啃NTFS或者ext4的源码结果被几十万行的代码量和复杂的缓存管理、日志机制劝退。我带过几个刚入行的朋友几乎每个人都是从NTFS开始然后卡在CcInitializeCacheMap和各种锁的交互上最后不了了之。其实如果你只是想入门Windows内核里的文件系统驱动CDFSCompact Disc File System才是那个最合适的起点——它足够小足够完整又足够真实。CDFS是Windows内核中负责读取光盘CD-ROM上ISO 9660文件系统的驱动文件名叫cdfs.sys位于C:\Windows\System32\drivers\目录下。它要处理的东西一点都不少卷识别、目录枚举、文件打开、缓存读取、即插即用、电源管理一个都不缺。但它的复杂度又控制在一个可以理解的范围内因为光盘是只读介质没有写路径、没有日志、没有复杂的空间分配。这意味着你可以在几千行的代码规模里完整地看到一个文件系统驱动从DriverEntry到FastIo到IRP_MJ_READ的全貌。我自己的经验是把CDFS吃透之后再去看FAT或者NTFS的只读部分理解成本会下降一大截。因为你已经建立了文件系统驱动到底在做什么的直觉它本质上是一个翻译层把上层应用的文件操作请求打开、读取、查询信息翻译成对底层存储介质的扇区读写同时维护一套元数据来管理目录结构和文件属性。CDFS把这个翻译层做得非常干净没有多余的干扰。这篇文章我会从零开始带你走一遍Windows CDFS驱动开发的完整路径。不是那种复制粘贴就能跑的教程而是把每个设计决策背后的原因讲清楚把我在实际开发中踩过的坑摊开来说。你需要有C语言基础了解Windows内核编程的基本概念IRP、设备对象、驱动对象但不需要事先懂文件系统。读完你应该能自己写出一个能挂载ISO、能枚举目录、能读取文件内容的CDFS驱动。提示本文讨论的是Windows内核模式驱动开发涉及WDKWindows Driver Kit的使用。建议使用Visual Studio 2022 WDK 11的组合目标系统用Windows 10或Windows 11的虚拟机方便调试和快照回滚。2. CDFS在Windows存储栈里的真实位置2.1 从应用层ReadFile到光盘扇区的完整链路要理解CDFS驱动怎么写先得搞清楚它在整个存储栈里站在哪一层。当你在资源管理器里双击一个ISO文件挂载出来的光驱然后打开里面的一个文本文件时背后发生了一长串的事情。应用层调用ReadFile这个请求进入NtReadFile然后I/O管理器创建一个IRP_MJ_READ的IRP把它发给目标设备对象。对于光驱来说这个设备对象是由cdrom.sys光驱端口驱动创建的但cdrom.sys并不理解ISO 9660文件系统它只负责跟光驱硬件或者虚拟光驱通信按扇区读写。所以在cdrom.sys之上需要有一个文件系统驱动来把读取文件偏移0x100处的512字节翻译成读取光盘上第N个扇区。CDFS就是干这个的。它作为一个文件系统驱动会创建一个文件系统设备对象通常叫\FileSystem\Cdfs然后通过IoRegisterFileSystem注册自己。当I/O管理器发现一个卷需要挂载文件系统时它会依次询问已注册的文件系统驱动这个卷你能处理吗CDFS的DriverEntry里注册的IRP_MJ_FILE_SYSTEM_CONTROL处理例程会响应IRP_MN_MOUNT_VOLUME去检查卷上的数据是否符合ISO 9660规范。这里有个关键点CDFS不是直接绑定到cdrom.sys上的中间还有一层叫卷快照或者卷设备对象的东西。实际上Windows的存储栈是这样的cdrom.sys创建物理设备对象PDO然后volmgr.sys卷管理器创建一个卷设备对象VDO附加在PDO上文件系统驱动再附加到VDO上。所以CDFS看到的设备对象是卷设备对象它通过IoGetRelatedDeviceObject或者直接发IRP给下层来读写扇区。2.2 ISO 9660规范里CDFS真正用到的部分ISO 9660是一个相当老的规范1988年就定下来了设计目标是在不同操作系统之间交换光盘数据。它的结构其实不复杂核心就是几个关键的数据结构系统区域System Area前16个扇区32768字节保留给系统使用CDFS直接跳过。卷描述符Volume Descriptor从第16个扇区开始每个扇区2048字节包含卷的各种元数据。类型有主卷描述符PVD、补充卷描述符SVD、引导记录、卷描述符结束符等。CDFS主要看PVD。路径表Path Table记录目录层次结构的紧凑表示CDFS用它来快速定位目录。目录记录Directory Record每个目录和文件都有一条目录记录包含文件名、位置、大小、属性等信息。CDFS在挂载时会读取第16个扇区开始的卷描述符找到PVD从中提取根目录的目录记录位置、逻辑块大小、卷空间大小等信息。然后它就可以通过目录记录里的数据位置字段LBA逻辑块地址来定位任何文件或目录的数据。这里有个容易踩的坑ISO 9660的文件名有严格限制8.3格式大写字母、数字、下划线但Windows实际使用的光盘经常用Joliet扩展在SVD里存Unicode文件名或者Rock Ridge扩展在目录记录的系统使用区域里存POSIX属性。CDFS是支持Joliet的所以你在写自己的驱动时如果要兼容真实光盘至少得处理SVD和Joliet的UCS-2编码。2.3 为什么CDFS选择只读设计上的取舍你可能会问为什么CDFS不支持写操作这不是偷懒而是光盘介质的物理特性决定的。CD-R只能写一次CD-RW虽然可以擦写但需要特殊的擦除周期而且ISO 9660的文件系统结构本身就不适合随机写入——目录记录是连续存放的插入一个文件需要重写整个目录区域。所以CDFS的设计哲学是假设介质不可变所有元数据在挂载时读取一次之后只做缓存和读取。这带来几个好处不需要处理写冲突不需要日志不需要复杂的锁机制。对于驱动开发者来说这意味着你可以把精力集中在读取路径的优化和正确性上。但只读也带来一些限制。比如你不能在CDFS上创建文件不能修改文件属性不能重命名。这些操作会直接返回STATUS_MEDIA_WRITE_PROTECTED。在实现自己的CDFS时你需要在IRP_MJ_CREATE里检查请求的访问权限如果包含写意图就直接拒绝。3. 搭建开发环境WDK、调试器和虚拟光驱的配合3.1 WDK版本选择与项目模板的坑Windows驱动开发套件WDK的版本选择很重要。我推荐用WDK 11对应Windows 11 22H2或更新版本因为它对Visual Studio 2022的支持最好而且包含了最新的内核API头文件。如果你用的是老版本的WDK比如WDK 8.1有些新的内核函数可能没有声明编译时会报错。安装WDK之后在Visual Studio里新建项目时你会看到Driver分类下有Empty WDM Driver和Kernel Mode Driver (KMDF)等模板。对于CDFS这种文件系统驱动应该选Empty WDM Driver因为文件系统驱动需要直接处理IRP用KMDF反而会增加不必要的抽象层。创建项目后第一件事是修改项目属性里的Driver Settings。把Target OS Version设成你实际调试用的Windows版本Target Platform设成Desktop。然后在Inf2Cat里配置好因为文件系统驱动需要一个INF文件来安装。这里有个坑Visual Studio默认会把驱动编译成测试签名但Windows 10/11默认要求驱动必须有有效的数字签名才能加载。在开发阶段你需要在测试机上开启测试签名模式命令是bcdedit /set testsigning on然后重启。重启后桌面右下角会显示测试模式水印这是正常的。3.2 用WinDbg做内核调试的完整配置内核调试是驱动开发绕不开的环节。我推荐用两台机器或者两个虚拟机一台作为开发机编译驱动一台作为目标机加载驱动。目标机需要开启内核调试通过串口、网络或者USB 3.0调试线连接到开发机。网络调试是最方便的。在目标机上运行bcdedit /debug on bcdedit /dbgsettings net hostip:192.168.1.100 port:50000 key:1.2.3.4其中hostip是开发机的IPport是调试端口key是调试密钥自己设一个。然后重启目标机。在开发机上打开WinDbg选择Kernel Debug - Net填入相同的端口和密钥就能连上了。连接成功后你可以用lm命令查看已加载的模块用!drvobj查看驱动对象用!devobj查看设备对象。对于文件系统驱动!fsutil或者!cdfs如果调试符号加载正确能帮你查看内部状态。注意调试文件系统驱动时断点不要下得太频繁否则系统会卡死。建议在DriverEntry和IRP_MJ_CREATE的处理例程里下断点用g命令继续执行观察IRP的流转。3.3 虚拟光驱与ISO制作让调试可重复调试CDFS驱动时你不可能每次都刻一张光盘。用虚拟光驱是最实际的方案。Windows 10/11自带ISO挂载功能右键ISO文件选挂载就行。但自带的挂载功能背后是cdrom.sys和storvsp.sys虚拟存储端口驱动在配合对于调试来说够用了。制作ISO文件推荐用oscdimg这是Windows ADK里带的工具。命令示例oscdimg -m -o -u2 -udfver102 -bootdata:2#p0,e,betfsboot.com#pEF,e,befisys.bin -lMYCDFS C:\ISOContent C:\mycd.iso其中-u2启用UDF文件系统-udfver102指定UDF 1.02版本。但如果你只想测试纯ISO 9660可以去掉UDF相关的参数只用-m -o -lMYCDFS。我建议在ISO内容里放几个不同大小的文件一个小于4KB的测试单扇区读取一个几MB的测试多扇区读取和缓存一个带长文件名的测试Joliet一个在深层目录里的测试路径解析。这样你的驱动在调试时能覆盖大部分场景。4. 从DriverEntry到卷挂载CDFS驱动的骨架4.1 DriverEntry里必须做的五件事DriverEntry是驱动的入口点对于CDFS来说它需要完成以下工作第一设置驱动对象的MajorFunction数组。文件系统驱动需要处理的IRP类型包括IRP_MJ_CREATE、IRP_MJ_CLOSE、IRP_MJ_READ、IRP_MJ_QUERY_INFORMATION、IRP_MJ_SET_INFORMATION、IRP_MJ_DIRECTORY_CONTROL、IRP_MJ_FILE_SYSTEM_CONTROL、IRP_MJ_CLEANUP、IRP_MJ_SHUTDOWN等。每个类型都要指定一个处理函数。第二创建文件系统设备对象。用IoCreateDevice创建一个类型为FILE_DEVICE_FILE_SYSTEM的设备对象名字通常是\FileSystem\Cdfs。这个设备对象不是用来给应用层直接访问的而是作为文件系统驱动的注册点。第三注册文件系统。调用IoRegisterFileSystem把设备对象传给I/O管理器。这样当有新卷需要挂载时I/O管理器会通知这个驱动。第四设置DriverObject-FastIoDispatch。Fast I/O是文件系统驱动的重要优化路径对于CDFS来说至少要实现FastIoRead和FastIoQueryBasicInfo。如果Fast I/O返回TRUEI/O管理器就不会创建IRP直接走快速路径性能提升很明显。第五初始化全局数据结构。比如缓存管理器回调、锁资源、调试跟踪标志等。代码骨架大概长这样NTSTATUS DriverEntry(PDRIVER_OBJECT DriverObject, PUNICODE_STRING RegistryPath) { NTSTATUS status; PDEVICE_OBJECT deviceObject NULL; UNICODE_STRING deviceName; RtlInitUnicodeString(deviceName, L\\FileSystem\\Cdfs); status IoCreateDevice(DriverObject, sizeof(CDFS_DEVICE_EXTENSION), deviceName, FILE_DEVICE_FILE_SYSTEM, 0, FALSE, deviceObject); if (!NT_SUCCESS(status)) return status; // 设置MajorFunction for (int i 0; i IRP_MJ_MAXIMUM_FUNCTION; i) { DriverObject-MajorFunction[i] CdfsDispatch; } DriverObject-MajorFunction[IRP_MJ_FILE_SYSTEM_CONTROL] CdfsFileSystemControl; DriverObject-MajorFunction[IRP_MJ_CREATE] CdfsCreate; DriverObject-MajorFunction[IRP_MJ_READ] CdfsRead; // ... 其他 // 注册文件系统 IoRegisterFileSystem(deviceObject); // 设置FastIo DriverObject-FastIoDispatch CdfsFastIoDispatch; return STATUS_SUCCESS; }4.2 响应IRP_MN_MOUNT_VOLUME卷识别与挂载当I/O管理器发现一个新卷时它会向所有已注册的文件系统驱动发送IRP_MJ_FILE_SYSTEM_CONTROLMinorFunction是IRP_MN_MOUNT_VOLUME。CDFS需要在这个例程里检查卷上的数据是否符合ISO 9660规范。具体步骤是先读取卷的第16个扇区偏移32768字节检查第一个卷描述符的类型字节。如果是1主卷描述符并且标识符是CD001那就认为这是一个ISO 9660卷。然后继续读取后续的卷描述符找到PVD提取根目录记录。这里有个细节卷描述符的读取需要通过IRP_MJ_READ发给下层设备对象。在IRP_MN_MOUNT_VOLUME的处理例程里你不能直接调用ZwReadFile因为那会重新进入I/O管理器可能造成死锁。正确做法是构造一个IRP_MJ_READ的IRP用IoCallDriver同步发送给下层设备对象然后等待完成。挂载成功后CDFS需要创建一个卷设备对象VDO附加到下层设备对象上。这个VDO会保存卷的元数据根目录的LBA、逻辑块大小、卷大小、Joliet目录的位置等。之后所有针对这个卷的文件操作都会先到达VDO然后由CDFS的处理例程处理。4.3 卷设备对象的创建与附加创建VDO用IoCreateDevice设备类型是FILE_DEVICE_CD_ROM_FILE_SYSTEM设备扩展里存CDFS_VCBVolume Control Block结构。这个结构是CDFS的核心数据结构包含下层设备对象指针TargetDeviceObject卷的根目录记录RootDirRecord逻辑块大小通常是2048字节卷的总扇区数Joliet目录的LBA如果有缓存管理器相关的回调指针一个ERESOURCE锁保护VCB的并发访问创建VDO后调用IoAttachDeviceToDeviceStack把它附加到下层设备对象上。然后设置DeviceObject-Flags | DO_DIRECT_IO因为文件系统驱动通常用直接I/ODirect I/O来传输数据避免缓冲区拷贝。最后调用IoRegisterDeviceInterface或者直接设置DeviceObject-Flags | DO_LOW_PRIORITY_FILESYSTEM对于光盘这种慢速设备让I/O管理器知道这个卷已经准备好了。5. 目录枚举与文件打开IRP_MJ_CREATE和IRP_MJ_DIRECTORY_CONTROL5.1 IRP_MJ_CREATE里解析路径的完整逻辑当应用层调用CreateFile打开光盘上的一个文件时I/O管理器会创建一个IRP_MJ_CREATE的IRP发给CDFS的VDO。这个IRP的FileObject-FileName字段包含相对路径比如\DIR1\FILE.TXT。CDFS的处理逻辑是从VCB的根目录记录开始逐级解析路径。每一级目录都要读取目录记录在目录项里查找匹配的名字。ISO 9660的目录记录是变长的每条记录的第一个字节是记录长度后面跟着扩展属性长度、数据位置LBA、数据长度、日期时间、文件标志、文件名长度、文件名等字段。查找名字时要注意大小写。ISO 9660的文件名是大写的但Windows应用可能用小写或者混合大小写来打开文件。CDFS的做法是先把名字转成大写再比较。如果卷支持Joliet还要处理UCS-2编码的文件名。找到目标文件的目录记录后CDFS需要创建一个CDFS_FCBFile Control Block结构保存文件的数据位置、大小、当前偏移等信息。这个FCB会挂在FileObject-FsContext上后续的读操作直接从这里取元数据。如果路径中间有目录不存在或者文件不存在返回STATUS_OBJECT_NAME_NOT_FOUND。如果请求的访问权限包含写意图返回STATUS_MEDIA_WRITE_PROTECTED。5.2 目录枚举IRP_MJ_DIRECTORY_CONTROL的两种MinorFunction目录枚举对应IRP_MJ_DIRECTORY_CONTROL有两个主要的MinorFunctionIRP_MN_QUERY_DIRECTORY和IRP_MN_NOTIFY_CHANGE_DIRECTORY。CDFS只需要处理前者因为光盘是只读的不需要通知目录变化。IRP_MN_QUERY_DIRECTORY的请求里包含一个FILE_INFORMATION_CLASS常见的有FileDirectoryInformation、FileFullDirectoryInformation、FileBothDirectoryInformation、FileNamesInformation。CDFS需要根据请求的信息类把目录记录转换成对应的结构填充到用户提供的缓冲区里。这里的关键是处理缓冲区大小。如果缓冲区不够放下所有目录项CDFS应该返回STATUS_BUFFER_OVERFLOW并且设置Irp-IoStatus.Information为实际写入的字节数。应用层会再次调用带上更大的缓冲区或者从上次的偏移继续。目录枚举的另一个坑是.和..这两个特殊目录项。ISO 9660的目录记录里前两条就是.和..CDFS在枚举时可以选择跳过它们也可以返回。Windows的资源管理器期望看到它们所以建议返回。5.3 文件名编码ISO 9660、Joliet和UDF的兼容处理真实世界的光盘很少是纯ISO 9660的。大部分Windows光盘都用Joliet扩展来支持Unicode文件名。Joliet的原理是在卷描述符里增加一个补充卷描述符SVD类型字节是2里面的目录记录用UCS-2编码文件名。CDFS在挂载时如果发现SVD应该优先使用SVD里的根目录记录。这样枚举出来的文件名就是Unicode的能正确显示中文、日文等字符。如果光盘还用了UDFUniversal Disk Format那就更复杂了。UDF有自己的文件系统结构CDFS本身不处理UDFWindows是用udfs.sys来挂载UDF的。但有些光盘是ISO 9660和UDF混合的所谓的UDF Bridge这种情况下CDFS和UDF驱动都可能去挂载具体谁挂载取决于I/O管理器的挂载顺序和卷的标识。在实现自己的CDFS时我建议至少支持ISO 9660和Joliet。UDF可以暂时不管因为那是一个独立的文件系统驱动该做的事。6. 数据读取路径缓存、Fast I/O和IRP_MJ_READ6.1 缓存管理器在CDFS里的角色文件系统驱动读取数据时如果每次都直接发IRP给下层设备性能会很差。Windows内核提供了缓存管理器Cache Manager它可以把最近读取的扇区缓存在内存里下次读取相同位置时直接命中缓存。CDFS使用缓存管理器的方式是在IRP_MJ_READ的处理例程里调用CcInitializeCacheMap初始化缓存然后调用CcCopyRead从缓存里读数据。如果缓存未命中缓存管理器会构造一个IRP_MJ_READ发给下层设备填充缓存然后完成用户的读请求。这里有个关键的回调CcInitializeCacheMap需要提供一个CDFS_CACHE_MANAGER_CALLBACKS结构里面包含AcquireForLazyWrite、ReleaseFromLazyWrite、AcquireForReadAhead、ReleaseFromReadAhead等函数指针。这些回调用来在缓存管理器进行延迟写和预读时获取和释放VCB的锁。对于只读的CDFS延迟写回调其实用不到但还是要提供否则CcInitializeCacheMap会失败。预读回调则很重要因为光盘的寻道时间很长预读能显著提升顺序读取的性能。6.2 Fast I/O路径绕过IRP的快速读取Fast I/O是文件系统驱动的一个重要优化。当应用层调用ReadFile时I/O管理器会先检查目标设备对象的FastIoDispatch里有没有FastIoRead函数。如果有并且调用返回TRUE就不创建IRP直接完成读取。CDFS的FastIoRead实现逻辑是检查请求的偏移和长度是否在文件范围内然后调用CcCopyRead从缓存读取。如果缓存未命中返回FALSE让I/O管理器走正常的IRP路径。Fast I/O的另一个重要函数是FastIoQueryBasicInfo和FastIoQueryStandardInfo它们用来快速响应GetFileInformationByHandle之类的查询。实现这些函数能减少IRP的创建提升性能。但要注意Fast I/O是在调用者的线程上下文里执行的不能阻塞不能等待。如果缓存未命中需要发IRP给下层设备必须返回FALSE让I/O管理器在系统工作线程里处理。6.3 IRP_MJ_READ的完整处理流程当Fast I/O返回FALSE时I/O管理器会创建一个IRP_MJ_READ的IRP。CDFS的处理流程是第一步从FileObject-FsContext取出FCB检查请求的偏移和长度是否合法。如果偏移超过文件大小返回STATUS_END_OF_FILE。第二步调用CcCopyRead从缓存读取。如果缓存命中直接完成IRP设置Irp-IoStatus.Information为读取的字节数。第三步如果缓存未命中CcCopyRead会返回FALSE并且缓存管理器会构造一个IRP_MJ_READ发给下层设备。CDFS需要在这个IRP里设置Irp-FileObject为FCB里保存的流文件对象Stream File Object然后调用IoCallDriver发给下层设备。第四步下层设备完成读取后缓存管理器会填充缓存然后完成用户的IRP。这里有个容易出错的地方CcCopyRead的Wait参数。如果设为TRUE它会阻塞等待缓存填充完成如果设为FALSE它会立即返回但需要调用者处理STATUS_PENDING。在IRP_MJ_READ的处理例程里通常设为TRUE因为I/O管理器已经在系统线程里了阻塞是安全的。7. 那些文档里不会写的踩坑记录7.1 卷挂载时的递归死锁我第一次写CDFS时在IRP_MN_MOUNT_VOLUME的处理例程里直接调用ZwReadFile去读卷描述符结果系统直接蓝屏错误码是IRQL_NOT_LESS_OR_EQUAL。原因是在挂载例程里IRQL可能已经提升到DISPATCH_LEVEL而ZwReadFile要求PASSIVE_LEVEL。正确的做法是构造一个IRP_MJ_READ用IoCallDriver同步发送给下层设备然后等待事件。但这里又有一个坑如果下层设备是cdrom.sys它可能在完成IRP时提升IRQL导致你的等待代码在错误的IRQL上执行。解决办法是用KeWaitForSingleObject等待事件并且确保事件对象是在PASSIVE_LEVEL创建的。更隐蔽的一个坑是在挂载例程里你不能持有VCB的锁去发IRP因为下层设备完成IRP时可能需要获取同一个锁造成死锁。我当时的做法是在挂载前先初始化VCB的锁但在发IRP读卷描述符时不持有锁等读取完成后再获取锁去更新VCB。7.2 缓存管理器的回调函数里不能做的事CcInitializeCacheMap的回调函数AcquireForLazyWrite等是在缓存管理器的内部线程里调用的IRQL是PASSIVE_LEVEL但你不能在这些回调里做任何可能阻塞的操作比如发IRP、等待事件、调用Zw系列函数。因为这些操作可能导致缓存管理器死锁。我踩过的坑是在AcquireForReadAhead回调里调用了ExAcquireResourceExclusiveLite而这个锁已经被另一个线程持有那个线程正在等待缓存管理器的预读完成。结果就是经典的ABBA死锁系统卡死只能强制重启。正确的做法是回调函数里只做最简单的锁操作用ExAcquireResourceSharedLite获取共享锁并且设置超时。如果获取不到直接返回FALSE让缓存管理器跳过这次预读。7.3 目录枚举的缓冲区溢出与对齐问题IRP_MN_QUERY_DIRECTORY的缓冲区处理比想象中复杂。用户提供的缓冲区可能不是对齐的而FILE_DIRECTORY_INFORMATION结构里的FileName字段是变长的需要按ULONG对齐。如果你直接往缓冲区里写结构可能会触发STATUS_DATATYPE_MISALIGNMENT。我的做法是先用ProbeForWrite检查缓冲区的可写性然后用一个临时缓冲区构造目录项最后用RtlCopyMemory拷贝到用户缓冲区。拷贝时要注意对齐每个目录项的起始地址必须是ULONG的倍数。另一个坑是Irp-IoStatus.Information的设置。如果缓冲区不够返回STATUS_BUFFER_OVERFLOW并且Information要设置为实际写入的字节数。如果缓冲区够返回STATUS_SUCCESSInformation设置为总字节数。如果目录为空返回STATUS_NO_MORE_FILES。7.4 卸载驱动时的资源泄漏文件系统驱动的卸载比普通驱动复杂因为可能有文件还打开着缓存还没刷新。CDFS的卸载例程需要调用IoUnregisterFileSystem注销文件系统遍历所有VDO对每个VDO调用CcUninitializeCacheMap释放缓存删除所有VDO删除文件系统设备对象我遇到的一个问题是如果卸载时还有文件打开着CcUninitializeCacheMap会失败返回STATUS_DEVICE_BUSY。这时候不能强行卸载应该返回失败让I/O管理器稍后重试。另一个问题是IoUnregisterFileSystem之后I/O管理器可能还会发送挂载请求。所以卸载例程里要设置一个标志让IRP_MN_MOUNT_VOLUME的处理例程直接返回STATUS_DEVICE_NOT_READY。8. 从能跑到好用性能调优与测试验证8.1 预读策略对光盘读取性能的影响光盘的随机读取性能很差寻道时间可能达到几百毫秒。所以预读Read-Ahead对CDFS来说特别重要。缓存管理器的预读逻辑是当检测到顺序读取时自动预读后续的扇区。CDFS可以通过CcSetReadAheadGranularity设置预读的粒度。默认值是64KB对于光盘来说可能太小。我试过设成256KB顺序读取大文件时性能提升明显。但设得太大也有问题如果应用只是随机读取小文件预读会浪费带宽和缓存。我的经验是根据文件类型动态调整。对于.txt、.log这类可能顺序读取的文件用较大的预读粒度对于.dll、.exe这类随机访问的文件用较小的粒度。但CDFS本身不知道文件类型所以这个策略需要在应用层或者通过文件扩展名来推断。8.2 用IOmeter和DiskSpd做基准测试测试CDFS驱动的性能推荐用DiskSpd微软官方的存储性能测试工具。命令示例diskspd -c1G -d30 -w0 -t4 -o4 -b64K -Sh -L D:\testfile.dat这个命令会在D盘创建一个1GB的文件进行30秒的4线程、4队列深度、64KB块的纯读测试。-Sh表示禁用硬件缓存-L表示测量延迟。对于CDFS你需要在挂载的ISO上运行测试。注意ISO是只读的所以-w00%写是必须的。测试结果里关注Total IOPS、AvgLatency和Read Speed。如果IOPS很低比如低于100说明预读或者缓存策略有问题。另一个有用的工具是IOmeter它可以模拟不同的访问模式顺序、随机、混合并且能生成详细的延迟分布图。我通常用IOmeter来对比不同预读粒度下的性能差异。8.3 验证正确性从文件哈希到边界条件性能之外正确性更重要。我建议写一个测试脚本自动完成以下验证枚举ISO上的所有文件计算每个文件的MD5和原始文件对比测试边界条件读取0字节、读取超过文件大小、读取偏移在文件末尾、打开不存在的文件、打开目录作为文件测试并发多个线程同时读取同一个文件的不同部分测试挂载和卸载反复挂载ISO、卸载ISO检查是否有内存泄漏内存泄漏可以用Poolmon或者Verifier来检测。开启Driver Verifier的Pool Tracking选项加载驱动后运行测试然后检查Poolmon里Cdfs标签的内存分配是否在卸载后归零。我踩过的一个坑是在IRP_MJ_CREATE里分配了FCB但在IRP_MJ_CLOSE里忘记释放。结果反复打开关闭文件后内存持续增长。后来用Poolmon定位到是Cdfs标签的NonPaged池在泄漏加上释放代码后就正常了。8.4 签名与部署让驱动在真实环境跑起来开发完成后如果要在非测试模式下加载驱动需要有效的数字签名。对于个人开发者可以购买代码签名证书或者用微软的硬件开发者门户提交驱动进行签名。在测试阶段用测试签名就够了。但要注意测试签名模式下系统会加载所有测试签名的驱动包括恶意驱动。所以测试机不要放敏感数据最好用虚拟机。部署驱动时需要写一个INF文件指定驱动的安装信息。对于文件系统驱动INF里的Class应该是FileSystemClassGuid是{4D36E967-E325-11CE-BFC1-08002BE10318}。安装时用pnputil /add-driver cdfs.inf /install然后重启。如果驱动加载失败可以用sc query cdfs查看服务状态用fltmc查看文件系统过滤驱动列表CDFS不是过滤驱动但fltmc能帮你确认文件系统驱动是否加载。事件查看器里的System日志也会有驱动加载失败的详细信息。9. 继续深入的方向从CDFS到更复杂的文件系统写完一个能用的CDFS之后你对Windows文件系统驱动的理解应该已经上了一个台阶。接下来可以往几个方向深入第一个方向是支持UDF。UDF是ISO 9660的现代替代品支持更大的文件和更好的Unicode。实现UDF驱动需要处理更复杂的元数据分区、文件入口、扩展属性等。但核心的IRP处理逻辑和CDFS是相通的。第二个方向是写一个只读的NTFS驱动。NTFS的MFT主文件表结构比ISO 9660复杂得多但只读路径不需要处理日志和事务难度可控。你可以从解析MFT记录开始逐步实现文件打开和读取。第三个方向是文件系统过滤驱动。过滤驱动附加在现有文件系统之上可以拦截和修改IRP。比如你可以写一个过滤驱动记录所有对光盘的读取操作或者对特定文件进行透明解密。过滤驱动的开发用Filter ManagerFltMgr会更方便但理解CDFS的IRP处理逻辑对写过滤驱动很有帮助。第四个方向是性能优化。CDFS的缓存策略还有很大的优化空间比如实现自适应预读、基于访问模式的缓存替换策略、多核环境下的锁优化等。这些优化需要你对Windows内核的缓存管理器和并发控制有深入理解。我个人觉得CDFS最大的价值不是它本身能做什么而是它提供了一个完整的、可理解的、可修改的文件系统驱动样本。你可以把它当成一个教学工具也可以把它当成一个基础框架在上面添加自己的功能。比如你可以加一个透明解压功能读取ISO里的压缩文件时自动解压或者加一个网络重定向功能把对光盘的读取转发到网络服务器。最后分享一个小技巧调试文件系统驱动时用!analyze -v分析蓝屏转储是最快的定位方法。但很多时候蓝屏的原因是死锁!analyze -v只能告诉你哪个线程卡住了不能告诉你为什么卡住。这时候用!locks查看锁的持有情况用!thread查看线程栈结合!irp查看未完成的IRP通常能定位到死锁的根源。我调试CDFS时遇到的大部分问题最后都是靠这三个命令组合解决的。
