Windows驱动编程基础教程

我经常在网上遇到心如火燎的提问者。他们碰到很多工作中的技术问题,是关于驱动开发的。其实绝大部分他们碰到的“巨大困难”是被老牛们看成初级得不能再初 级的问题。比如经常有人定义一个空的UNICODE_STRING,然后往里面拷贝字符串。结果无论如何都是蓝屏。也有人在堆栈中定义一个局部 SPIN_LOCK,作为下面的同步用——这样用显然没有任何意义。我无法一一回答这些问题:因为往往要耐心的看他们的代码,才能很不容易的发现这些错 误。而且我又不是总是空闲的,可以无休止的去帮网友阅读代码和查找初级错误。但是归根结底,这些问题的出现,是因为现在写驱动的同行越来越多,但是做驱动 开发又没有比较基础的,容易读懂的资料。为此我决定从今天开始连载一篇超级入门级的教程,来解决那些最基本的开发问题。老牛们就请无视这篇教程,一笑而过 了。

Windows驱动编程基础教程(1.1-1.3)

1.1 使用字符串结构

    常常使用传统C语言的程序员比较喜欢用如下的方法定义和使用字符串:
  
    char    *str = { “my first string” };            // ansi字符串
    wchar_t    *wstr = { L”my first string” };    // unicode字符串
    size_t len = strlen(str);                    // ansi字符串求长度
    size_t wlen = wcslen(wstr);                // unicode字符串求长度
    printf(“%s %ws %d %d”,str,wstr,len,wlen);    // 打印两种字符串

    但 是实际上这种字符串相当的不安全。很容易导致缓冲溢出漏洞。这是因为没有任何地方确切的表明一个字符串的长度。仅仅用一个’\0’字符来标明这个字符串的 结束。一旦碰到根本就没有空结束的字符串(可能是攻击者恶意的输入、或者是编程错误导致的意外),程序就可能陷入崩溃。
    使用高级C++特性的编码者则容易忽略这个问题。因为常常使用std::string和CString这样高级的类。不用去担忧字符串的安全性了。
    在驱动开发中,一般不再用空来表示一个字符串的结束。而是定义了如下的一个结构:

    ty pedef struct _UNICODE_STRING {
        USHORT Length;                // 字符串的长度(字节数)
        USHORT MaximumLength;        // 字符串缓冲区的长度(字节数)
        PWSTR    Buffer;                // 字符串缓冲区
    } UNICODE_STRING, *PUNICODE_STRING;

    以上是Unicode字符串,一个字符为双字节。与之对应的还有一个Ansi字符串。Ansi字符串就是C语言中常用的单字节表示一个字符的窄字符串。

    ty pedef struct _STRING {
        USHORT Length;
        USHORT MaximumLength;
        PSTR Buffer;
    } ANSI_STRING, *PANSI_STRING;

    在驱动开发中四处可见的是Unicode字符串。因此可以说:Windows的 内核是使用Uincode编码的。ANSI_STRING仅仅在某些碰到窄字符的场合使用。而且这种场合非常罕见。

UNICODE_STRING并不保证Buffer中的字符串是以空结束的。因此,类似下面的做法都是错误的,可能会会导致 内核崩溃:

    UNICODE_STRING str;
    …
    len = wcslen(str.Buffer);            // 试图求长度。
    DbgPrint(“%ws”,str.Buffer);        // 试图打印str.Buffer。
  
    如果要用以上的方法,必须在编码中保证Buffer始终是以空结束。但这又是一个麻烦的问题。所以,使用微软提供的Rtl系列函数来操作字符串,才是正确的方法。下文逐步的讲述这个系列的函数的使用。

1.2 字符串的初始化

    请回顾之前的UNICODE_STRING结构。读者应该可以注意到,这个结构中并不含有字符串缓冲的空间。这是一个初学者常见的出问题的来源。以下的代码是完全错误的, 内核会立刻崩溃:
  
    UNICODE_STRING str;
    wcscpy(str.Buffer,L”my first string!”);
    str.Length = str.MaximumLength = wcslen(L”my first string!”) * sizeof(WCHAR);

    以上的代码定义了一个字符串并试图初始化它的值。但是非常遗憾这样做是不对的。因为str.Buffer只是一个未初始化的指针。它并没有指向有意义的空间。相反以下的方法是正确的:

    // 先定义后,再定义空间
UNICODE_STRING str;
    str.Buffer = L”my first string!”;
    str.Length = str.MaximumLength = wcslen(L”my first string!”) * sizeof(WCHAR);
    … …
  
    上面代码的第二行手写的常数字符串在代码中形成了“常数”内存空间。这个空间位于代码段。将被分配于可执行页面上。一般的情况下不可写。为此,要注意的是这个字符串空间一旦初始化就不要再更改。否则可能引发系统的保护异常。实际上更好的写法如下:

    //请分析一下为何这样写是对的:
    UNICODE_STRING str = {
        sizeof(L”my first string!”) – sizeof((L”my first string!”)[0]),  
        sizeof(L”my first string!”),
        L”my first_string!” };

    但是这样定义一个字符串实在太繁琐了。但是在头文件ntdef.h中有一个宏方便这种定义。使用这个宏之后,我们就可以简单的定义一个常数字符串如下:

    #include <ntdef.h>
    UNICODE_STRING str = RTL_CONSTANT_STRING(L“my first string!”);
  
    这只能在定义这个字符串的时候使用。为了随时初始化一个字符串,可以使用RtlInitUnicodeString。示例如下:
  
    UNICODE_STRING str;
    RtlInitUnicodeString(&str,L”my first string!”);

    用本小节的方法初始化的字符串,不用担心内存释放方面的问题。因为我们并没有分配任何内存。

1.3 字符串的拷贝

    因 为字符串不再是空结束的,所以使用wcscpy来拷贝字符串是不行的。UNICODE_STRING可以用RtlCopyUnicodeString来进 行拷贝。在进行这种拷贝的时候,最需要注意的一点是:拷贝目的字符串的Buffer必须有足够的空间。如果Buffer的空间不足,字符串会拷贝不完全。 这是一个比较隐蔽的错误。
    下面举一个例子。

    UNICODE_STRING dst;            // 目标字符串
    WCHAR dst_buf[256];                // 我们现在还不会分配内存,所以先定义缓冲区
    UNICODE_STRING src = RTL_CONST_STRING(L”My source string!”);
  
    // 把目标字符串初始化为拥有缓冲区长度为256的UNICODE_STRING空串。
    RtlInitEmptyString(dst,dst_buf,256*sizeof(WCHAR));
    RtlCopyUnicodeString(&dst,&src);    // 字符串拷贝!
  
    以上这个拷贝之所以可以成功,是因为256比L” My source string!”的长度要大。如果小,则拷贝也不会出现任何明示的错误。但是拷贝结束之后,与使用者的目标不符,字符串实际上被截短了。
    我曾经犯过的一个错误是没有调用RtlInitEmptyString。结果dst字符串被初始化认为缓冲区长度为0。虽然程序没有崩溃,却实际上没有拷贝任何内容。
    在拷贝之前,最谨慎的方法是根据源字符串的长度动态分配空间。在1.2节“内存与链表”中,读者会看到动态分配内存处理字符串的方法。


Windows驱动编程基础教程(1.4-2.1)

1.4 字符串的连接

    UNICODE_STRING不再是简单的字符串。操作这个数据结构往往需要更多的耐心。读者会常常碰到这样的需求:要把两个字符串连接到一起。简单的追加一个字符串并不困难。重要的依然是保证目标字符串的空间大小。下面是范例:

    NTSTATUS status;
    UNICODE_STRING dst;            // 目标字符串
    WCHAR dst_buf[256];                // 我们现在还不会分配内存,所以先定义缓冲区
    UNICODE_STRING src = RTL_CONST_STRING(L”My source string!”);
  
    // 把目标字符串初始化为拥有缓冲区长度为256的UNICODE_STRING空串
    RtlInitEmptyString(dst,dst_buf,256*sizeof(WCHAR));
    RtlCopyUnicodeString(&dst,&src);    // 字符串拷贝!
  
    status = RtlAp pendUnicodeToString(
            &dst,L”my second string!”);
    if(status != STATUS_SUCCESS)
    {
        ……
    }


    NTSTATUS是常见的返回值类型。如果函数成功,返回STATUS_SUCCESS。否则的话,是一个错误码。RtlAp pendUnicodeToString在目标字符串空间不足的时候依然可以连接字符串,但是会返回一个警告性的错误STATUS_BUFFER_TOO_SMALL。
    另外一种情况是希望连接两个UNICODE_STRING,这种情况请调用 
1.5 字符串的打印

    字符串的连接另一种常见的情况是字符串和数字的组合。有时数字需要被转换为字符串。有时需要把若干个数字和字符串混合组合起来。这往往用于打印日志的时候。日志中可能含有文件名、时间、和行号,以及其他的信息。
    熟 悉C语言的读者会使用sprintf。这个函数的宽字符版本为swprintf。该函数在驱动开发中依然可以使用,但是不安全。微软建议使用 RtlStringCbPrintfW来代替它。RtlStringCbPrintfW需要包含头文件ntstrsafe.h。在连接的时候,还需要连接 库ntsafestr.lib。
    下面的代码生成一个字符串,字符串中包含文件的路径,和这个文件的大小。
  
    #include <ntstrsafe.h>
    // 任何时候,假设文件路径的长度为有限的都是不对的。应该动态的分配
    // 内存。但是动态分配内存的方法还没有讲述,所以这里再次把内存空间
    // 定义在局部变量中,也就是所谓的“在栈中”
    WCHAR buf[512] = { 0 };
    UNICODE_STRING dst;
    NTSTATUS status;
    ……

    // 字符串初始化为空串。缓冲区长度为512*sizeof(WCHAR)
    RtlInitEmptyString(dst,dst_buf,512*sizeof(WCHAR));
  
    // 调用RtlStringCbPrintfW来进行打印
    status = RtlStringCbPrintfW(
        dst->Buffer,L”file path = %wZ file size = %d \r\n”,
        &file_path,file_size);
    // 这里调用wcslen没问题,这是因为RtlStringCbPrintfW打印的
    // 字符串是以空结束的。
    dst->Length = wcslen(dst->Buffer) * sizeof(WCHAR);

    RtlStringCbPrintfW 在目标缓冲区内存不足的时候依然可以打印,但是多余的部分被截去了。返回的status值为STATUS_BUFFER_OVERFLOW。调用这个函数 之前很难知道究竟需要多长的缓冲区。一般都采取倍增尝试。每次都传入一个为前次尝试长度为2倍长度的新缓冲区,直到这个函数返回 STATUS_SUCCESS为止。
    值得注意的是UNICODE_STRING类型的指针,用%wZ打印可以打印出字符串。在不能保证字符串为空结束的时候,必须避免使用%ws或者%s。其他的打印格式字符串与传统C语言中的printf函数完全相同。可以尽情使用。
    另外就是常见的输出打印。printf函数只有在有控制台输出的情况下才有意义。在驱动中没有控制台。但是Windows 内核中拥有调试信息输出机制。可以使用特殊的工具查看打印的调试信息(请参阅附录1“WDK的安装与驱动开发的环境配置”)。
    驱 动中可以调用DbgPrint()函数来打印调试信息。这个函数的使用和printf基本相同。但是格式字符串要使用宽字符。DbgPrint()的一个 缺点在于,发行版本的驱动程序往往不希望附带任何输出信息,只有调试版本才需要调试信息。但是DbgPrint()无论是发行版本还是调试版本编译都会有 效。为此可以自己定义一个宏:

    #if DBG
        KdPrint(a)    DbgPrint##a
    #else
        KdPrint (a)
    #endif
      
    不过这样的后果是,由于KdPrint (a)只支持1个参数,因此必须把DbgPrint的所有参数都括起来当作一个参数传入。导致KdPrint看起来很奇特的用了双重括弧:

    // 调用KdPrint来进行输出调试信息
    status = KdPrint ((
        L”file path = %wZ file size = %d \r\n”,
        &file_path,file_size));

    这个宏没有必要自己定义,WDK包中已有。所以可以直接使用KdPrint来代替DbgPrint取得更方便的效果。

2.1内存的分配与释放

    内存泄漏是C语言中一个臭名昭著的问题。但是作为 内核开 发者,读者将有必要自己来面对它。在传统的C语言中,分配内存常常使用的函数是malloc。这个函数的使用非常简单,传入长度参数就得到内存空间。在驱 动中使用内存分配,这个函数不再有效。驱动中分配内存,最常用的是调用ExAllocatePoolWithTag。其他的方法在本章范围内全部忽略。回 忆前一小节关于字符串的处理的情况。一个字符串被复制到另一个字符串的时候,最好根据源字符串的空间长度来分配目标字符串的长度。下面的举例,是把一个字 符串src拷贝到字符串dst。
  
    // 定义一个内存分配标记
    #define MEM_TAG    ‘MyTt’
    // 目标字符串,接下来它需要分配空间。
    UNICODE_STRING dst = { 0 };
    // 分配空间给目标字符串。根据源字符串的长度。
    dst.Buffer = (PWCHAR)ExAllocatePoolWithTag(NonpagedPool,src->Length,MEM_TAG);
    if(dst.Buffer == NULL)
    {
        // 错误处理
        status = STATUS_INSUFFICIENT_RESOUCRES;
        ……
    }
    dst.Length = dst.MaximumLength = src->Length;
    status = RtlCopyUnicodeString(&dst,&src);
    ASSERT(status == STATUS_SUCCESS);

    ExAllocatePoolWithTag的第一个参数NonpagedPool表明分配的内存是锁定内存。这些内存永远真实存在于物理内存上。不会被分页交换到硬盘上去。第二个参数是长度。第三个参数是一个所谓的“内存分配标记”。
    内存分配标记用于检测内存泄漏。想象一下,我们根据占用越来越多的内存的分配标记,就能大概知道泄漏的来源。一般每个驱动程序定义一个自己的内存标记。也可以在每个模块中定义单独的内存标记。内存标记是随意的32位数字。即使冲突也不会有什么问题。
    此外也可以分配可分页内存,使用PagedPool即可。
    ExAllocatePoolWithTag分配的内存可以使用ExFreePool来释放。如果不释放,则永远泄漏。并不像用户进程关闭后自动释放所有分配的空间。即使驱动程序动态卸载,也不能释放空间。唯一的办法是重启计算机。
    ExFreePool只需要提供需要释放的指针即可。举例如下:

    ExFreePool(dst.Buffer);
    dst.Buffer = NULL;
    dst.Length = dst.MaximumLength = 0;
  
    ExFreePool不能用来释放一个栈空间的指针。否则系统立刻崩溃。像以下的代码:

    UNICODE_STRING src = RTL_CONST_STRING(L”My source string!”);
    ExFreePool(src.Buffer);

    会招来立刻蓝屏。所以请务必保持ExAllocatePoolWithTag和ExFreePool的成对关系。

Windows驱动编程基础教程(2.2)

2.2 使用LIST_ENTRY

    Windows的 内核开发者们自己开发了部分数据结构,比如说LIST_ENTRY。
    LIST_ENTRY 是一个双向链表结构。它总是在使用的时候,被插入到已有的数据结构中。下面举一个例子。我构筑一个链表,这个链表的每个节点,是一个文件名和一个文件大小 两个数据成员组成的结构。此外有一个FILE_OBJECT的指针对象。在驱动中,这代表一个文件对象。本书后面的章节会详细解释。这个链表的作用是:保 存了文件的文件名和长度。只要传入FILE_OBJECT的指针,使用者就可以遍历链表找到文件名和文件长度。

    ty pedef struct {
        PFILE_OBJECT file_object;
        UNICODE_STRING file_name;
        LARGE_INTEGER file_length;
    } MY_FILE_INFOR, *PMY_FILE_INFOR;

    一些读者会马上注意到文件的长度用LARGE_INTEGER表示。这是一个代表长长整型的数据结构。这个结构我们在下一小小节“使用长长整型数据”中介绍。
    为了让上面的结构成为链表节点,我必须在里面插入一个LIST_ENTRY结构。至于插入的位置并无所谓。可以放在最前,也可以放中间,或者最后面。但是实际上读者很快会发现把LIST_ENTRY放在开头是最简单的做法:

    ty pedef struct {
        LIST_ENTRY list_entry;
        PFILE_OBJECT file_object;
        UNICODE_STRING file_name;
        LARGE_INTEGER file_length;
    } MY_FILE_INFOR, *PMY_FILE_INFOR;    

    list_entry如果是作为链表的头,在使用之前,必须调用InitializeListHead来初始化。下面是示例的代码:
// 我们的链表头
    LIST_ENTRY        my_list_head;

    // 链表头初始化。一般的说在应该在程序入口处调用一下
    void MyFileInforInilt()
    {
        InitializeListHead(&my_list_head);
    }

    // 我们的链表节点。里面保存一个文件名和一个文件长度信息。
    ty pedef struct {
        LIST_ENTRY list_entry;
        PFILE_OBJECT file_object;
        PUNICODE_STRING file_name;
        LARGE_INTEGER file_length;
    } MY_FILE_INFOR, *PMY_FILE_INFOR;

    // 追加一条信息。也就是增加一个链表节点。请注意file_name是外面分配的。
    // 内存由使用者管理。本链表并不管理它。
    NTSTATUS MyFileInforAp pendNode(
        PFILE_OBJECT file_object, 
        PUNICODE_STRING file_name,
        PLARGE_INTEGER file_length)
    {
        PMY_FILE_INFOR my_file_infor = 
            (PMY_FILE_INFOR)ExAllocatePoolWithTag(
                PagedPool,sizeof(MY_FILE_INFOR),MEM_TAG);
        if(my_file_infor == NULL)
            return STATUS_INSUFFICIENT_RESOURES;

        // 填写数据成员。
        my_file_infor->file_object = file_object;
        my_file_infor->file_name = file_name;
        my_file_infor->file_length = file_length;

        // 插入到链表末尾。请注意这里没有使用任何锁。所以,这个函数不是多
        // 多线程安全的。在下面自旋锁的使用中讲解如何保证多线程安全性。
        InsertHeadList(&my_list_head, (PLIST_ENTRY)& my_file_infor);
        return STATUS_SUCCESS;    
    } 以上的代码实现了插入。可以看到LIST_ENTRY插入到MY_FILE_INFOR结构的头部的好处。这样一来一个MY_FILE_INFOR看起来 就像一个LIST_ENTRY。不过糟糕的是并非所有的情况都可以这样。比如MS的许多结构喜欢一开头是结构的长度。因此在通过LIST_ENTRY结构 的地址获取所在的节点的地址的时候,有个地址偏移计算的过程。可以通过下面的一个典型的遍历链表的示例中看到:

    for(p = my_list_head.Flink; p != &my_list_head.Flink; p = p->Flink)
    {
        PMY_FILE_INFOR elem = 
            CONTAINING_RECORD(p,MY_FILE_INFOR, list_entry);
        // To do something here…
        }
    }

    其中的CONTAINING_RECORD是一个WDK中已经定义的宏,作用是通过一个LIST_ENTRY结构的指针,找到这个结构所在的节点的指针。定义如下:
    
    #define CONTAINING_RECORD(address, ty pe, field) ((ty pe *)( \
            (PCHAR)(address) - \
            (ULONG_PTR)(&((ty pe *)0)->field)))

    从上面的代码中可以总结如下的信息:
    LIST_ENTRY中的数据成员Flink指向下一个LIST_ENTRY。
    整个链表中的最后一个LIST_ENTRY的Flink不是空。而是指向头节点。
    得到LIST_ENTRY之后,要用CONTAINING_RECORD来得到链表节点中的数据。


Windows驱动编程基础教程(2.3-2.4)

2.3 使用长长整型数据
    这里解释前面碰到的LARGE_INTEGER结构。与可能的误解不同,64位数据并非要在64位操作系统下才能使用。在VC中,64位数据的类型为__int64。定义写法如下:

    __int64 file_offset;

    上 面之所以定义的变量名为file_offset,是因为文件中的偏移量是一种常见的要使用64位数据的情况。同时,文件的大小也是如此(回忆上一小节中定 义的文件大小)。32位数据无符号整型只能表示到4GB。而众所周知,现在超过4GB的文件绝对不罕见了。但是实际上__int64这个类型在驱动开发中 很少被使用。基本上被使用到的是一个共用体:LARGE_INTEGER。这个共用体定义如下:

    ty pedef __int64 LONGLONG;    
    ty pedef union _LARGE_INTEGER {
        struct {
            ULONG LowPart;
            LONG HighPart;
        };
        struct {
            ULONG LowPart;
            LONG HighPart;
        } u;
        LONGLONG QuadPart;
    } LARGE_INTEGER;

    这个共用体的方便之处在于,既可以很方便的得到高32位,低32位,也可以方便的得到整个64位。进行运算和比较的时候,使用QuadPart即可。

    LARGE_INTEGER a,b;
    a.QuadPart = 100;
    a.QuadPart *= 100;
    b.QuadPart = a.QuadPart;
    if(b.QuadPart > 1000)
    {
        KdPrint(“b.QuadPart < 1000, LowPart = %x HighPart = %x”, b.LowPart,b.HighPart);
    }
    
    上面这段代码演示了这种结构的一般用法。在实际编程中,会碰到大量的参数是LARGE_INTEGER类型的。
2.4使用自旋锁

    链表之类的结构总是涉及到恼人的多线程同步问题,这时候就必须使用锁。这里只介绍最简单的自选锁。
    有些读者可能疑惑锁存在的意义。这和多线程操作有关。在驱动开发的代码中,大多是存在于多线程执行环境的。就是说可能有几个线程在同时调用当前函数。
    这样一来,前文1.2.2中提及的追加链表节点函数就根本无法使用了。因为MyFileInforAp pendNode 这个函数只是简单的操作链表。如果两个线程同时调用这个函数来操作链表的话:注意这个函数操作的是一个全局变量链表。换句话说,无论有多少个线程同时执 行,他们操作的都是同一个链表。这就可能发生,一个线程插入一个节点的同时,另一个线程也同时插入。他们都插入同一个链表节点的后边。这时链表就会发生问 题。到底最后插入的是哪一个呢?要么一个丢失了。要么链表被损坏了。
    如下的代码初始化获取一个自选锁:

    KSPIN_LOCK my_spin_lock;
    KeInitializeSpinLock(&my_spin_lock);

    KeInitializeSpinLock 这个函数没有返回值。下面的代码展示了如何使用这个SpinLock。在KeAcquireSpinLock和KeReleaseSpinLock之间的 代码是只有单线程执行的。其他的线程会停留在KeAcquireSpinLock等候。直到KeReleaseSpinLock被调用。KIRQL是一个 中断级。KeAcquireSpinLock会提高当前的中断级。但是目前忽略这个问题。中断级在后面讲述。
    
    KIRQL irql;
    KeAcquireSpinLock(&my_spin_lock,&irql);
    // To do something …
    KeReleaseSpinLock(&my_spin_lock,irql);
    
    初学者要注意的是,像下面写的这样的“加锁”代码是没有意义的,等于没加锁:
    
    void MySafeFunction()
    {
        KSPIN_LOCK my_spin_lock;
        KIRQL irql;
        KeInitializeSpinLock(&my_spin_lock);
        KeAcquireSpinLock(&my_spin_lock,&irql);
        // To do something …
        KeReleaseSpinLock(&my_spin_lock,irql);
    }

    原 因是my_spin_lock在堆栈中。每个线程来执行的时候都会重新初始化一个锁。只有所有的线程共用一个锁,锁才有意义。所以,锁一般不会定义成局部 变量。可以使用静态变量、全局变量,或者分配在堆中(见前面的1.2.1内存的分配与释放一节)。请读者自己写出正确的方法。
LIST_ENTRY有一系列的操作。这些操作并不需要使用者自己调用获取与释放锁。只需要为每个链表定义并初始化一个锁即可:

    
    LIST_ENTRY        my_list_head;        // 链表头
    KSPIN_LOCK    my_list_lock;        // 链表的锁
    
    // 链表初始化函数
    void MyFileInforInilt()
    {
        InitializeListHead(&my_list_head);
        KeInitializeSpinLock(&my_list_lock);
    }

    链表一旦完成了初始化,之后的可以采用一系列加锁的操作来代替普通的操作。比如插入一个节点,普通的操作代码如下:

    InsertHeadList(&my_list_head, (PLIST_ENTRY)& my_file_infor);

    换成加锁的操作方式如下:

    ExInterlockedInsertHeadList(
        &my_list_head, 
        (PLIST_ENTRY)& my_file_infor,
        &my_list_lock);

    注意不同之处在于,增加了一个KSPIN_LOCK的指针作为参数。在ExInterlockedInsertHeadList中,会自动的使用这个KSPIN_LOCK进行加锁。类似的还有一个加锁的Remove函数,用来移除一个节点,调用如下:

    my_file_infor = ExInterlockedRemoveHeadList (
        &my_list_head, 
        &my_list_lock);

    这个函数从链表中移除第一个节点。并返回到my_file_infor中。

Windows驱动编程基础教程(3.1-3.2)

3.1 使用OBJECT_ATTRIBUTES

    一 般的想法是,打开文件应该传入这个文件的路径。但是实际上这个函数并不直接接受一个字符串。使用者必须首先填写一个OBJECT_ATTRIBUTES结 构。在文档中并没有公开这个OBJECT_ATTRIBUTES结构。这个结构总是被InitializeObjectAttributes初始化。
    下面专门说明InitializeObjectAttributes。
    
    VOID InitializeObjectAttributes(
        OUT POBJECT_ATTRIBUTES InitializedAttributes,
        IN PUNICODE_STRING ObjectName,
        IN ULONG Attributes,
        IN HANDLE RootDirectory,
        IN PSECURITY_DESCRIPTOR SecurityDescriptor);

    读者需要注意的以下的几点:InitializedAttributes是要初始化的OBJECT_ATTRIBUTES结构的指针。ObjectName则是对象名字字符串。也就是前文所描述的文件的路径(如果要打开的对象是一个文件的话)。
    Attributes 则只需要填写OBJ_CASE_INSENSITIVE| OBJ_KERNEL_HANDLE即可(如果读者是想要方便的简洁的打开一个文件的话)。 OBJ_CASE_INSENSITIVE意味着名字字符串是不区分大小写的。由于Windows的文件系统本来就不区分字母大小写,所以笔者并没有尝试 过如果不设置这个标记会有什么后果。OBJ_KERNEL_HANDLE表明打开的文件句柄一个“ 内核句柄”。 内核文件句柄比应用层句柄使用更方便,可以不受线程和进程的限制。在任何线程中都可以读写。同时打开 内核文件句柄不需要顾及当前进程是否有权限访问该文件的问题(如果是有安全权限限制的文件系统)。如果不使用 内核句柄,则有时不得不填写后面的的SecurityDescriptor参数。
    RootDirectory用于相对打开的情况。目前省略。请读者传入NULL即可。
    SecurityDescriptor用于设置安全描述符。由于笔者总是打开 内核句柄,所以很少设置这个参数。

3.2 打开和关闭文件

    下面的函数用于打开一个文件:
    
    NTSTATUS ZwCreateFile(
        OUT PHANDLE FileHandle,                            
        IN ACCESS_MASK DesiredAccess,                    
        IN POBJECT_ATTRIBUTES ObjectAttribute,    
        OUT PIO_STATUS_BLOCK IoStatusBlock,
        IN PLARGE_INTEGER AllocationSize OPTIONAL,
        IN ULONG FileAttributes,
        IN ULONG ShareAccess,
        IN ULONG CreateDisposition,
        IN ULONG createOptions,
        IN PVOID EaBuffer OPTIONAL,
        IN ULONG EaLength);
这个函数的参数异常复杂。下面逐个的说明如下:
    FileHandle:是一个句柄的指针。如果这个函数调用返回成成功(STATUS_SUCCESS),那就么打开的文件句柄就返回在这个地址内。
DesiredAccess: 申请的权限。如果打开写文件内容,请使用FILE_WRITE_DATA。如果需要读文件内容,请使用FILE_READ_DATA。如果需要删除文件或 者把文件改名,请使用Delete。如果想设置文件属性,请使用FILE_WRITE_ATTRIBUTES。反之,读文件属性则使用 FILE_READ_ATTRIBUTES。这些条件可以用|(位或)来组合。有两个宏分别组合了常用的读权限和常用的写权限。分别为 GENERIC_READ和GENERIC_WRITE。此外还有一个宏代表全部权限,是GENERIC_ALL。此外,如果想同步的打开文件,请加上 SYNCHRONIZE。同步打开文件详见后面对CreateOptions的说明。
    ObjectAttribute:对象描述。见前一小节。
    IoStatusBlock也是一个结构。这个结构在 内核开发中经常使用。它往往用于表示一个操作的结果。这个结构在文档中是公开的,如下:

    ty pedef struct _IO_STATUS_BLOCK {
        union {
            NTSTATUS Status;
            PVOID Pointer;
        };
        ULONG_PTR Information;
    } IO_STATUS_BLOCK, *PIO_STATUS_BLOCK;

    实 际编程中很少用到Pointer。一般的说,返回的结果在Status中。成功则为STATUS_SUCCESS。否则则是一个错误码。进一步的信息在 Information中。不同的情况下返回的Information的信息意义不同。针对ZwCreateFile调用的情况,Information 的返回值有以下几种可能:
    FILE_CreateD:文件被成功的新建了。
    FILE_OPENED:    文件被打开了。
    FILE_OVERWRITTEN:文件被覆盖了。
    FILE_SUPERSEDED:    文件被替代了。
    FILE_EXISTS:文件已存在。(因而打开失败了)。
    FILE_DOES_NOT_EXIST:文件不存在。(因而打开失败了)。
    这些返回值和打开文件的意图有关(有时希望打开已存在的文件,有时则希望建立新的文件等等。这些意图在本小节稍后的内容中详细说明。
    ZwCreateFile 的下一个参数是AllocationSize。这个参数很少使用,请设置为NULL。    再接下来的一个参数为FileAttributes。这个参 数控制新建立的文件的属性。一般的说,设置为FILE_ATTRIBUTE_NORMAL即可。在实际编程中,笔者没有尝试过其他的值。
    ShareAccess 是一个非常容易被人误解的参数。实际上,这是在本代码打开这个文件的时候,允许别的代码同时打开这个文件所持有的权限。所以称为共享访问。一共有三种共享 标记可以设置:FILE_SHARE_READ、FILE_SHARE_WRITE、FILE_SHARE_Delete。这三个标记可以用|(位或)来 组合。举例如下:如果本次打开只使用了FILE_SHARE_READ,那么这个文件在本次打开之后,关闭之前,别次打开试图以读权限打开,则被允许,可 以成功打开。如果别次打开试图以写权限打开,则一定失败。返回共享冲突。
    同时,如果本次打开只只用了FILE_SHARE_READ,而之前这个文件已经被另一次打开用写权限打开着。那么本次打开一定失败,返回共享冲突。其中的逻辑关系貌似比较复杂,读者应耐心理解。
    CreateDisposition参数说明了这次打开的意图。可能的选择如下(请注意这些选择不能组合):
    FILE_Create:新建文件。如果文件已经存在,则这个请求失败。
    FILE_OPEN:打开文件。如果文件不存在,则请求失败。
    FILE_OPEN_IF:打开或新建。如果文件存在,则打开。如果不存在,则失败。
    FILE_OVERWRITE:覆盖。如果文件存在,则打开并覆盖其内容。如果文件不存在,这个请求返回失败。
    FILE_OVERWRITE_IF:新建或覆盖。如果要打开的文件已存在,则打开它,并覆盖其内存。如果不存在,则简单的新建新文件。
    FILE_SUPERSEDE:新建或取代。如果要打开的文件已存在。则生成一个新文件替代之。如果不存在,则简单的生成新文件。
    请联系上面的IoStatusBlock参数中的Information的说明。
最 后一个重要的参数是CreateOptions。在惯常的编程中,笔者使用 FILE_NON_DIRECTORY_FILE| FILE_SYNCHRONOUS_IO_NONALERT。此时文件被同步的打开。而且打开的是文 件(而不是目录。创建目录请用FILE_ DIRECTORY_FILE)。所谓同步的打开的意义在于,以后每次操作文件的时候,比如写入文件,调用 ZwWriteFile,在ZwWriteFile返回时,文件写操作已经得到了完成。而不会有返回STATUS_PENDING(未决)的情况。在非同 步文件的情况下,返回未决是常见的。此时文件请求没有完成,使用者需要等待事件来等待请求的完成。当然,好处是使用者可以先去做别的事情。
    要同步打开,前面的DesiredAccess必须含有SYNCHRONIZE。
    此 外还有一些其他的情况。比如不通过缓冲操作文件。希望每次读写文件都是直接往磁盘上操作的。此时CreateOptions中应该带标记 FILE_NO_INTERMEDIATE_BUFFERING。带了这个标记后,请注意操作文件每次读写都必须以磁盘扇区大小(最常见的是512字节) 对齐。否则会返回错误。
    这个函数是如此的繁琐,以至于再多的文档也不如一个可以利用的例子。早期笔者调用这个函数往往因为参数设置不对而导致打开失败。非常渴望找到一个实际可以使用的参数的范例。下面举例如下:

    // 要返回的文件句柄
    HANDLE file_handle = NULL;
    // 返回值
    NTSTATUS status;
    // 首先初始化含有文件路径的OBJECT_ATTRIBUTES
    OBJECT_ATTRIBUTES object_attributes;
    UNICODE_STRING ufile_name = RTL_CONST_STRING(L”\\??\\C:\\a.dat”);
    InitializeObjectAttributes(
        &object_attributes,
        &ufile_name,
        OBJ_CASE_INSENSITIVE|OBJ_KERNEL_HANDLE,
        NULL,
                NULL);
    // 以OPEN_IF方式打开文件。
    status = ZwCreateFile(
                &file_handle,
                GENERIC_READ | GENERIC_WRITE,
                &object_attributes,
                &io_status,
                NULL,
                FILE_ATTRIBUTE_NORMAL,
                FILE_SHARE_READ,
                FILE_OPEN_IF,
                FILE_NON_DIRECTORY_FILE |
                FILE_RANDOM_ACCESS |
                FILE_SYNCHRONOUS_IO_NONALERT,
                NULL,
                0);

    值得注意的是路径的写法。并不是像应用层一样直接写“C:\\a.dat”。而是写成了“\\??\\C:\\a.dat”。这是因为ZwCreateFile使用的是对象路径。“C:”是一个符号链接对象。符号链接对象一般都在“\\??\\”路径下。
    这种文件句柄的关闭非常简单。调用ZwClose即可。 内核句柄的关闭不需要和打开在同一进程中。示例如下:

    ZwClose(file_handle);

Windows驱动编程基础教程(3.3-4.1)

3.3 文件的读写操作
    打开文件之后,最重要的操作是对文件的读写。读与写的方法是对称的。只是参数输入与输出的方向不同。读取文件内容一般用ZwReadFile,写文件一般使用ZwWriteFile。

    NTSTATUS 
      ZwReadFile(
          IN HANDLE  FileHandle,
            IN HANDLE  Event  OPTIONAL,
            IN PIO_APC_ROUTINE  ApcRoutine  OPTIONAL,
            IN PVOID  ApcContext  OPTIONAL,
            OUT PIO_STATUS_BLOCK  IoStatusBlock,
            OUT PVOID  Buffer,
            IN ULONG  Length,
            IN PLARGE_INTEGER  ByteOffset  OPTIONAL,
            IN PULONG  Key  OPTIONAL);

    FileHandle:是前面ZwCreateFile成功后所得到的FileHandle。如果是 内核句柄,ZwReadFile和ZwCreateFile并不需要在同一个进程中。句柄是各进程通用的。
    Event :一个事件。用于异步完成读时。下面的举例始终用同步读,所以忽略这个参数。请始终填写NULL。
    ApcRoutine Apc:回调例程。用于异步完成读时。下面的举例始终用同步读,所以忽略这个参数。请始终填写NULL。
    IoStatusBlock:返回结果状态。同ZwCreateFile中的同名参数。
    Buffer:缓冲区。如果读文件的内容成功,则内容被被读到这个缓冲里。
    Length:描述缓冲区的长度。这个长度也就是试图读取文件的长度。
    ByteOffset:要读取的文件的偏移量。也就是要读取的内容在文件中的位置。一般的说,不要设置为NULL。文件句柄不一定支持直接读取当前偏移。
    Key:读取文件时用的一种附加信息,一般不使用。设置NULL。
    返 回值:成功的返回值是STATUS_SUCCESS。只要读取到任意多个字节(不管是否符合输入的Length的要求),返回值都是 STATUS_SUCCESS。即使试图读取的长度范围超出了文件本来的大小。但是,如果仅读取文件长度之外的部分,则返回 STATUS_END_OF_FILE。
    ZwWriteFile的参数与ZwReadFile完全相同。当然,除了读写文件外,有的读者 可能会问是否提供一个ZwCopyFile用来拷贝一个文件。这个要求未能被满足。如果有这个需求,这个函数必须自己来编写。下面是一个例子,用来拷贝一 个文件。利用到了ZwCreateFile,ZwReadFile和ZwWrite这三个函数。
不过作为本节的例子,只举出ZwReadFile和ZwWriteFile的部分:

    NTSTATUS MyCopyFile(
        PUNICODE_STRING target_path,
        PUNICODE_STRING source_path)
    {
        // 源和目标的文件句柄
        HANDLE target = NULL,source = NULL;
        // 用来拷贝的缓冲区
        PVOID buffer = NULL;
        LARGE_INTEGER offset = { 0 };
        IO_STATUS_BLOCK io_status = { 0 };
    
        do {
            // 这里请用前一小节说到的例子打开target_path和source_path所对应的
            // 句柄target和source,并为buffer分配一个页面也就是4k的内存。
            … …
            // 然后用一个循环来读取文件。每次从源文件中读取4k内容,然后往
            // 目标文件中写入4k,直到拷贝结束为止。 
            while(1) {
                length = 4*1024;        // 每次读取4k。
                // 读取旧文件。注意status。
                status = ZwReadFile (
                    source,NULL,NULL,NULL,
                    &my_io_status,buffer, length,&offset,
                    NULL);
                if(!NT_SUCCESS(status))
                {
                    // 如果状态为STATUS_END_OF_FILE,则说明文件
                    // 的拷贝已经成功的结束了。
                    if(status == STATUS_END_OF_FILE)
                        status = STATUS_SUCCESS;
                    break;
                }
                // 获得实际读取到的长度。
                length = IoStatus.Information;

                // 现在读取了内容。读出的长度为length.那么我写入
                // 的长度也应该是length。写入必须成功。如果失败,
                // 则返回错误。
                status = ZwWriteFile(
                    target,NULL,NULL,NULL,
                    &my_io_status,
                    buffer,length,&offset,
                    NULL);
                if(!NT_SUCCESS(status))
                    break;
                
                // offset移动,然后继续。直到出现STATUS_END_OF_FILE
                // 的时候才结束。
                offset.QuadPart += length;
            }
        } while(0);

        // 在退出之前,释放资源,关闭所有的句柄。
        if(target != NULL)
            ZwClose(target);
        if(source != NULL)
            ZwClose(source);
        if(buffer != NULL)
            ExFreePool(buffer);
        return STATUS_SUCCESS;
    }
    
    除了读写之外,文件还有很多的操作。比如删除、重新命名、枚举。这些操作将在后面实例中用到时,再详细讲解。
.1注册键的打开操作

    和在应用程序中编程的方式类似,注册表是一个巨大的树形结构。操作一般都是打开某个子键。子键下有若干个值可以获得。每一个值有一个名字。值有不同的类型。一般需要查询才能获得其类型。
    子键一般用一个路径来表示。和应用程序编程的一点重大不同是这个路径的写法不一样。一般应用编程中需要提供一个根子键的句柄。而驱动中则全部用路径表示。相应的有一张表表示如下:

    应用编程中对应的子键    驱动编程中的路径写法
    HKEY_LOCAL_MACHINE    \Registry\Machine
    HKEY_USERS        \Registry\User
    HKEY_CLASSES_ROOT    没有对应的路径
    HKEY_CURRENT_USER    没有简单的对应路径,但是可以求得
    
    实 际上应用程序和驱动程序很大的一个不同在于应用程序总是由某个“当前用户”启动的。因此可以直接读取HKEY_CLASSES_ROOT和 HKEY_CURRENT_USER。而驱动程序和用户无关,所以直接去打开HKEY_CURRENT_USER也就不符合逻辑了。
    打开注册表键使用函数ZwO penKey。新建或者打开则使用ZwCreateKey。一般在驱动编程中,使用ZwO penKey的情况比较多见。下面以此为例讲解。ZwO penKey的原型如下:

    NTSTATUS 
          ZwO penKey(
            OUT PHANDLE  KeyHandle,
              IN ACCESS_MASK  DesiredAccess,
            IN POBJECT_ATTRIBUTES  ObjectAttributes
        );
    
    这个函数和ZwCreateFile是类似的。它并不接受直接传入一个字符串来表示一个子键。而是要求输入一个OBJECT_ATTRIBUTES的指针。如何初始化一个OBJECT_ATTRIBUTES请参考前面的讲解ZwCreateFile的章节。
    DesiredAccess支持一系列的组合权限。可以是下表中所有权限的任何组合:
    KEY_QUERY_VALUE:读取键下的值。
    KEY_SET_VALUE:设置键下的值。
    KEY_Create_SUB_KEY:生成子键。
    KEY_ENUMERATE_SUB_KEYS:枚举子键。
    不过实际上可以用KEY_READ来做为通用的读权限组合。这是一个组合宏。此外对应的有KEY_WRITE。如果需要获得全部的权限,可以使用KEY_ALL_ACCESS。
    下面是一个例子,这个例子非常的有实用价值。它读取注册表中保存的Windows系统目录(指Windows目录)的位置。不过这里只涉及打开子键。并不读取值。读取具体的值在后面的小节中再完成。
    Windows 目录的位置被称为SystemRoot,这一值保存在注册表中,路径是“HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft \Windows NT\CurrentVersion”。当然,请注意注意在驱动编程中的写法有所不同。下面的代码初始化一个 OBJECT_ATTRIBUTES。

    HANDLE my_key = NULL;
    NTSTATUS status;

    // 定义要获取的路径    
    UNICODE_STRING my_key_path = 
        RTL_CONSTANT_STRING(
            L” \\ Registry\\Machine\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion”);
    OBJECT_ATTRIBUTE my_obj_attr = { 0 };

    // 初始化OBJECT_ATTRIBUTE
    InitializeObjectAttributes(
        &my_obj_attr,
        &my_key_path,
        OBJ_CASE_INSENSITIVE,
        NULL,
                NULL);
    // 接下来是打开Key
    status = ZwO penKey(&my_key,KEY_READ,&my_obj_attr);
    if(!NT_SUCCESS(status))
    {
        // 失败处理
        ……
    }

    上面的代码得到了my_key。子键已经打开。然后的步骤是读取下面的SystemRoot值。这在后面一个小节中讲述。


Windows 文件过滤驱动经验总结

1、获得文件全路径以及判断时机

除 在所有 IRP_MJ_XXX 之前自己从头创建 IRP 发送到下层设备查询全路径外,不要尝试在 IRP_MJ_Create 以外的地方获得全路 径,因为只有在 IRP_MJ_Create中才会使用 ObCreateObject() 来建立一个有效的 FILE_OBJECT。而 在 IRP_READ,IRP_WRITE 中它们是直接操作 FCB (File Control Block)的。


2、从头建立 IRP 发送关注点

无 论你建立什么样的 IRP,是 IRP_MJ_Create 也好还是 IRP_MJ_DIRECTORY_CONTROL也罢,最要提醒的就是一些标 志。不同的标志会代来不同的结果,有些结果是直接返回失败。这里指的标志不光是 IRP->Flags,还要考 虑 IO_STACK_LOCATION->Flags还有其它等等。尤其是你要达到一些特殊目的,这时候更需要注意, 如 IRP_MN_QUERY_DIRECTORY,不同的标志结果有很大的不同。


3、从头建立 IRP 获取全路径注意点

自 己从头建立一个 IRP_MJ_QUERY_INFORMATION 的 IRP 获取全路径时需要注意,不仅在 IRP_MJ_Create 要做区别 处理,在 IRP_MJ_CLOSE 也要做同样的处理,否则如果目标是 NTFS 文件系统的话可能产生 deadlock。如果是 NTFS 那么在 IRP_MJ_CLEANUP 的时候也需要对 FO_STREAM_FILE 类型的文件做同样处理。



4、获得本地/远程访问用户名(域名/SID)

方 法只有在 IRP_MJ_Create 中才可用,那是因为 IO_SECURITY_CONTEXT 只有 在 IO_STACK_LOCATION->Parameters.Create.SecurityContext 才会有效。这样你才有可能 从 IO_SECURITY_CONTEXT->SecurityContext->AccessState->SubjectSecurityContext.XXXToken 中 获得访问 TOKEN,从而进一步得到用户名或 SID。记得 IFS 中有一个库,它的 LIB 导出一个函数可以让你在获得以上信息后得到用户名与域 名。但如果你想兼容 NT4 的话,只能自己分析来得出本地和远程的 SID。


5、文件与目录的判断

正确的方法 在楚狂人的文档里已经说过了,再补充一句。如果你的文件过滤驱动要兼容所有文件系统,那么不要十分相信 从 FileObject->FsContext 里取得的数据。正确的方法还是在你传递下去 IRP_MJ_Create 后从最下层文件系统延 设备栈返回到你这里后再获得。


6、加/解密中判断点

只判 断 IRP_PAGING_IO,IRP_SYNCHRONOUS_PAGING_IO,IRP_NOCACHE 是没错的。如果有问题,相信是自己的问 题。关于有人提到在 FILE_OBJECT->Flags中的 FO_NO_INTERMEDIATE_BUFFERING 是否需要判断,对此 问题的回答是只要你判断了IRP_NOCACHE 就不用再判断 FILE_OBJECT 中的,因为它最终会设 置 IRP->Flags 为 IRP_NOCACHE。关于你看到的诸如 IRP_DEFER_IO_COMPLETION等 IRP 不要去管 它,因为它只是一个过程。最终读写还是如上所介绍。至于以上这些 IRP 哪个是由 CC MGR 发送的,哪些是由 I/O MGR 发送和在什么时候 发送的,这个已经有很多讨论了,相信可以找到。



7、举例说明关于 IRP 传递与完成注意事项

只 看 Walter Oney 的那本 《Programming the Microsoft Windows driver model》里介绍的流 程,自己没有实际的体会还是不够的,那里只介绍了基础概念,让自己有了知识。知道如何用,在什么情况下用,用哪种方法,能够用的稳定这叫有了技术。我们从 另一个角度出发,把问题分为两段来看,这样利于总结。一个 IRP 在过滤驱动中,把它分为需要安装 CompleteRoutine 的与无需安 装 CompleteRoutine 的。那么在不需要安装 CompleteRoutine 的有以下几类情况。

(1) 拿到这个 IRP 后什么都不做,直接调用 IoCompleteRequest() 来返回。
(2) 拿到这个 IRP 后什么都不做,直接传递到底层设备,使用 IoSkipCurrentIrpStackLocation() 后调用 IoCallDriver() 传递。
(3) 使用 IoBuildSynchronousFsdRequest() 或 IoBuildDeviceIoControlRequest()来建立 IRP 的。

以 上几种根据需要直接使用即可,除了一些参数与标志需要注意外,没有什么系统机制相关的东西需要注意了。那么再来看需要安 装 CompleteRoutine 的情况。我们把这种情况再细分为两种,一是在 CompleteRoutine 中返回标志为 STATUS_MORE_PROCESSING_REQUIRED 的情况。二是返回处这个外的标志,需要使用函数 IoMarkIrpPending() 的情况。在 CompleteRoutine 中绝大多数就这么两种情况,你需要使用其中的一种情况。那么为什么 需要安装 CompleteRoutine 呢?那是因为我们对其 IRP 从上层驱动,经过我们驱动,在经过底层设备栈返回到我们这一层驱动时需要得到 其中内容作为参考依据的,还有对其中内容需要进行修改的。再有一种情况是没有经过上层驱动,而 IRP 的产生是在我们驱动直接下发到底层驱动,而经过设 备栈后返回到我们这一层,且我们不在希望它继续向上返回的,因为这个 IRP 本身就不是从上层来的。综上所述,先来看 下 IoMarkIrpPending() 的情况。


(1) 在 CompleteRoutine 中判 断 Irp->PendingReturned 并使用 IoMarkIrpPending()然后返回。这种方法在没有使 用 KeSetEvent() 的情况下,且不是自建 IRP 发送到底层驱动返回时使用。也就是说有可能我所做的工作都是 在 CompleteRoutine 中进行的。比如加/解密时,我在这里对下层驱动返回数据的判断并修改。修改后因为没有使 用 STATUS_MORE_PROCESSING_REQUIRED 标志,它会延设备堆一直向上返回并到用户得到数据为止。这里一定要注意,在这种情 况下 CompleteRoutine返回后,不要在碰这个 IRP。也就是说如果这个时候你使用了 IoCompleteRequest()的话会出现 一个 MULTIPLE_IRP_COMPLIETE_REQUEST 的 BSOD 错误。


(2) 在 CompleteRoutine 中直接返回 STATUS_MORE_PROCESSING_REQUIRED 标志。这种情况在使用了 KeSetEvent() 的函数下出现。这里又有两个小小的分之。

  1) 出 现于上层发送到我这里,当我这里使用 IoCallDriver() 后,底层返回数据经过我这一层时,我想让它暂时停止继续向上传递,让这 个 IRP 稍微歇息一会,等我对这个 IRP 返回的数据操作完成后(一般是没有在 CompleteRoutine中对返回数据进行操作情况下,也就 是说等到完成例程返回后再进行操作),由我来调用 IoCompleteRequest() 让它延着设备栈继续返回。这里要注意,我们是想让它返回的, 所以调用了 IoCompleteRequest()。这个可不同于下面所讲的自己从头分配 IRP 时在 CompleteRoutine 中已经调 用 IoFreeIrp() 释放了当前 IRP 的情况。比如我在做一个改变文件大小,向文件头写入加密标志的驱动时,在上层发来 了 IRP_MJ_QUERY_INFORMATION 查询文件,我想在这个时候获得文件信息进行判断,然后根据我的判断结果再移动文件指针。注意:上 面是两步,第一步是先获得文件大小,那么在这个时候我就需要用到上述办法,先让这个 IRP传递下去,得到我想要的东西后在进行对比。等待适当时机完成这 个 IRP,让数据继续传递,直到用户收到为止。第二步我会结合下面小节来讲。

  2) 出现于自己从头建立 IRP,当使 用 IoAllocate() 或 IoBuildAsynchronousFsdRequest()创建 IRP 调 用 IoCallDriver() 后,底层返回数据到我这一层时,我不想让这 个 IRP 继续向上延设备栈传递。因为这个 IRP 就是在我这层次建 立的,上层本就不知道有这么一个 IRP。那么到这里我就要在 CompleteRoutine 中使用 IoFreeIrp()来释放掉这个 IRP, 并不让它继续传递。这里一定要注意,在 CompleteRoutine函数返回后,这个 IRP 已经释放了,如果这个时候在有任何关于这 个 IRP 的操作那么后果是灾难性的,必定导致 BSOD 错误。前面 1) 小节给出的例子只完成了第一步这里继续讲第二步,第一步我重用这 个 IRP 得到了文件大小,那么这个时候虽 然知道大小,但我还是无法知道这个文件是否被我加过密。这时,我就需要在这里自己从头建立一 个 IRP_MJ_READ 的 IRP 来读取文件来判断是否我加密过了的文件,如果是,则要减少相应的大小,然后继续返回。注意:这里的返回是指让第 一步的 IRP 返回。而不是我们自己创建的。我们创建的都已经在 CompleteRoutine 中销 毁了。



8、关于完成 IRP 的动作简介

当 一个底层驱动调用了 IoCompleteRequest() 函数时,基本上所有设备栈相关 IRP 处理工作都是在它那里完成的。包 括 IRP->Flags 的一些标志的判断,对 APC 的处理,抛出MULTIPLE_IRP_COMPLETE_REQUESTS 错误等。 当它延设备栈一直调用驱动所安装的 CompleteRoutine时,如果发现 STATUS_MORE_PROCESSING_REQUIRED 这 个标志,则会停止向上继续回滚。这也是为什么在 CompleteRoutine 中使用这个标志即可暂停 IRP 的原因。



9、关于 ObQueryNameString 的使用

这 个函数的使用,在有些环境下会有问题。它的上层函数是 ZwQueryObject()。在某些情况下会导致系统挂起,或者直接 BSOD。它是从 对象 管理器中的 ObpRootDirectoryObject开始遍历,通过 OBJECT_HEADER_TO_NAME_INFO 获得对象名称。今天 问了下 PolyMeta好象是在处理 PIPE 时会挂启,这个问题出现在 2000 系统。在 XP 上好象补丁了。


10、关于重入问题

其 实这个问题在很久前的 IFS FAQ 里已经介绍的很清楚,包括处理方法以及每种方法可能带来的问题。IFS FAQ 里的 Q34 一共介绍了四种方 法,包括自己从头建立 IRP发送,使用 ShadowDevice,使用特征字符串,根据线程 ID,在 XP 下使用IoCreateFileS pecifyDeviceObjectHint() 函数。并且把以上几种在不同环境下使用要处理的问题也做了简单的介绍。且在 Q33 里介绍了在 CIFS 碰到的 FILE_COMPLETE_IF_OPLOCKED 问题的解决方法。

你可能感兴趣的:(windows)