看了 ChuKuangRen 的第二版《文件過濾驅動開發教程》後，頗有感觸。我想，交流都是 建立在平等的基礎上，在抱怨氛圍和環境不好的同時應該先想一想自己究竟付出了多少？只 知索取不願付出的人也就不用抱怨了，要怪也只能怪自己。發自己心得的人無非是兩種目的 ，一是引發一些討論，好糾正自己錯誤的認識，以便從中獲取更多的知識使自己進步的更快 。二是做一份備忘，當自己遺忘的時候能夠馬上找到相關資料。我這裡也總結了近幾年做文 件過濾驅動時所積累下來的一些小小經驗，這分筆記也是看了 ChuKuangRen 的教程後，臨時 想到的一小部分而已，是想到哪寫到哪，不是很全，如果以後再回想起什麼也會不斷補充。 因其工作原因，近段時間在 SOLARIS 驅動與 Linux 內核方面投入的精力比較多，Windows 下的文件過濾驅動一直也沒有怎麼去碰，所以最後還是那句老話 FIXME。
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 下使用 IoCreateFileSpecifyDeviceObjectHint() 函數。並且把以上幾種在不同環境下使用要處理 的問題也做了簡單的介紹。且在 Q33 裡介紹了在 CIFS 碰到的 FILE_COMPLETE_IF_OPLOCKED 問題的解決方法。
