文件過濾驅動雙緩沖

㈠ 在不壓縮時如何把文件加密

一． HS-Key技術特色

從我們對產品的構思設計和開發，以及國內大企業用戶的評測驗證和認可度上，巨石企業文件加密系統HS-Key，無論從底層技術的運用上，還是軟體的擴展性和柔韌性上，都已經走在了中國企業文件加密軟體的最前面。並在對中國企業管理的符合度上，優於國外同類產品。與國內同類產品相比，HS-Key具有以下明顯的特色和優勢：

1． 基於底層驅動的雙緩沖加解密技術

國內目前應用最廣的是基於應用程序二次開發加密以及基於驅動的單機加密系統，但這兩種加密系統都存在著明顯的缺陷和安全漏洞。

基於應用程序二次開發的加密軟體，只能針對少數幾種應用程序進行加密控制，而不能適應種類繁多的應用程序的加密控制，因此受到很大應用局限性。

基於驅動的單機加密系統，雖然可以加密監控本地計算機所有的應用程序，但是由於不支持網路文件系統，打開本機加密文件另存至未受控的計算機時會自動解密，從而導致加密文件的安全泄漏。

而HS-Key則在底層技術上採用了以下技術：

（1） 採用雙緩沖底層驅動文件過濾技術進行文件加密。

雙緩沖技術，即在windows自有的緩沖區之外，另建了一個存儲結構相同的緩沖區，這個緩沖區由HS-Key單獨管理和控制。在讀取密文的時候，在windows緩存中保存密文，而在自建的緩沖區中保存明文信息，當進行寫操作時，如果需要寫入明文，則從自建的緩沖區中直接寫入硬碟，如果需要寫入密文，則將windows緩沖區的密文內容寫入硬碟。這樣做的優勢就在於：

直接在緩存中進行加解密，寫硬碟的速度更快，加解密效率更高。

在windows緩存中保存的是密文，可以防止別有用心的人從windows緩沖中竊取明文數據，導致泄密。

不但可以實現強制加密功能，而且可以輕松的實現強制解密功能，更加符合企業的實際加密管理需求。

（2） 全面支持網路文件系統。

同時監控本地硬碟和網路驅動器的讀寫加密。對任何應用程序生成的任何文件進行加密控制。同時，透明加解密的過程中，不產生臨時文件，

2． 高安全性演算法和加解密效率並重

加密強度和加解密速度是雙面刃。加密強度越高，加解密速度越慢，而且文件越大，時間上的延遲越明顯。加密強度太低，則很容易被破解。為了同時保證文件安全和加密效率，HS-Key採用了160位的IBM公司的SEAL加密演算法，同時採用雙緩沖技術，對加解密速度進行了優化。實際測試結果證明，使用HS-Key透明打開大於100M的文件，也不會有明顯的時間延遲。

3． 切合企業實際的安全管理

國內的很多加密軟體在關注文件加解密的同時，忽略了將加解密管理融入到企業的管理體系當中，為了加密而加密，不但改變了企業原有的工作習慣，而且導致工作效率因此而大幅度降低。HS-Key則在產品的構架上充分考慮了企業的實際需求，因此在實施時能夠很好的融合到企業的整體安全管理體系中。

（1） 實名制身份認證

國內絕大多數加密軟體簡單地採用硬體綁定的方式進行加密管理，這種方式的缺點就在於：

a. 無法判斷客戶端的登錄用戶到底是誰；

b. 不能夠進行分組管理和授權；

c. 將客戶端與計算機硬體進行了綁定。一旦計算機硬體配置發生變化，則無法再進行管理。高加密許可權的用戶也無法操作普通用戶的計算機。

d. 單個用戶只能有單一的許可權。

針對這些問題，HS-Key獨創的採用實名制方式進行身份認證管理，即每個用戶都擁有一個安全許可權，根據用戶名+密碼登錄+硬體碼的方式進行管理，而不是簡單地和機器的硬體（MAC地址）進行綁定。這種管理方式的優勢在於：

a. 可以直觀的看到安全組以及其用戶的設置情況；

b. 可以直觀了解，哪些用戶沒有登錄或者未受到加密監控；

c. 高級許可權的用戶無論在任何一台機器上登錄都擁有相同的許可權；

d. 在同一台機器上可以進行多用戶的切換，加解密許可權也隨之變化；

e. 也可以根據需要將用戶名和硬體綁定，限定該用戶只能在本機登錄。

f. 不需要專門的解密工具，擁有解密許可權的用戶可以登錄到任何一台計算機進行解密。

（2） 允許多重許可權的組合

特殊的許可權可以授權給某個安全組，也可以授權給某個用戶，如果這個用戶屬於多個安全組，HS-Key將進行智能累加，使多重身份，多重許可權成為可能。

（3） 允許特權用戶的存在

公司領導往往是特權擁有者，HS-Key充分考慮到這一點，允許在許可權設置時，放寬對該部分群體的加密限制。比如允許關閉加密監控、允許拷屏操作等。

（4） 允許合法的離線工作

HS-Key不但允許合法用戶離線進行加密文件的閱讀，同時還允許動態的延長授權時間和授權策略。

（5） 多種明文出口

加密軟體對企業工作習慣影響最大的，還是對外交流。HS-Key除了提供方便的手工解密方式外，還提供多種自動解密渠道供企業選擇，滿足安全性和靈活性的要求：

郵件發送自動解密、即時通訊軟體（如QQ、MSN等）發送自動解密等；

存儲到移動磁碟（U盤、移動硬碟等）時自動解密；

刻錄到光碟時自動解密；

保存到網路磁碟（網上鄰居的共享目錄）時自動解密；

保存到指定目錄自動解密等等。

保存某種指定文件格式時強制解密（如保存為txt文件格式時自動解密）等等。

（6） 靈活的策略自定義

HS-Key提供開放的策略自定義功能，用戶可以通過策略的自行配置，滿足各種復雜的安全需求。如：

本地列印機的控制

禁止指定的應用程序運行

禁止未授權的應用程序訪問加密文件

與PDM、OA、ERP系統的集成等等。

4． 多操作系統的加解密管理

國內的加密軟體大多隻支持常用的windows2000和XP操作系統，而HS-Key則可以支持最廣泛的操作系統平台，不但支持常用的windows操作系統，還支持早期的windows 98系統。與此同時，為了滿足與UNIX、Linux等多操作系統文件共享的問題，還提供了專門的加解密策略方案。

5． 開發中的HS-Key高級企業版

巨石公司的HS-Key高級企業版已經規劃完畢，編碼工作已經開始。在我們的規劃中，高級企業版將在標准企業版的基礎上，增加分組、分級授權，功能更加強大，能滿足集團化企業和動態企業聯盟的復雜的文件安全需求。目前國內尚未有此類產品上市。HS-Key高級企業版的將在技術和功能上與國外的同類產品分庭抗禮，並在某些方面超過

㈡ linux怎樣載入文件過濾驅動

文件系統過濾驅動是一種可選的，為文件系統提供具有附加值功能的驅動程序。文件系統過濾驅動是一種核心模式組件，它作為Windows NT執行體的一部分運行。
文件系統過濾驅動可以過濾一個或多個文件系統或文件系統卷的I/O操作。按不同的種類劃分，文件系統過濾驅動可以分成日誌記錄、系統監測、數據修改或事件預防幾類。通常，以文件系統過濾驅動為核心的應用程序有防毒軟體、加密程序、分級存儲管理系統等。
二、文件系統過濾驅動並不是設備驅動
設備驅動是用來控制特定硬體I/O設備的軟體組件。例如：DVD存儲設備驅動是一個DVD驅動。
相反，文件系統過濾驅動與一個或多個文件系統協同工作來處理文件I/O操作。這些操作包括：創建、打開、關閉、枚舉文件和目錄；獲取和設置文件、目錄、卷的相關信息；向文件中讀取或寫入數據。另外，文件系統過濾驅動必須支持文件系統特定的功能，例如緩存、鎖定、稀疏文件、磁碟配額、壓縮、安全、可恢復性、還原點和卷裝載等。
下面兩部分詳細的闡述了文件系統過濾驅動和設備驅動之間的相似點與不同點。

三、安裝文件系統過濾驅動
對於Windows XP和後續操作系統來說，可以通過INI文件或安裝應用程序來安裝文件系統過濾驅動（對於Windows 2000和更早的操作系統，過濾驅動通常通過服務控制管理器Service Control Manager來進行安裝）。
四、初始化文件系統過濾驅動
與設備驅動類似，文件系統過濾驅動也使用DriverEntry常式進行初始化工作。在驅動程序載入後，載入驅動相同的組件將通過調用驅動程序的 DriverEntry常式來對驅動程序進行初始化工作。對於文件系統過濾驅動來說，載入和初始化過濾驅動的系統組件為I/O管理器。
DriverEntry常式運行於系統線程上下文中，其IRQL = PASSIVE_LEVEL。本常式可分頁，詳細信息參見MmLockPagableCodeSection。
DriverEntry常式定義如下：
NTSTATUS
DriverEntry (
IN PDRIVER_OBJECT DriverObject,
IN PUNICODE_STRING RegistryPath
)
本常式有兩個輸入參數。第一個參數，DriverObject為系統在文件系統過濾驅動載入時所創建的驅動對象；第二個參數，RegistryPath為包含驅動程序注冊鍵路徑的Unicode字元串。
文件系統過濾驅動按如下順序執行DriverEntry常式：

01、創建控制設備對象：

文件系統過濾驅動的DriverEntry常式通常以創建控制設備對象作為該常式的起始。創建控制設備對象的目的在於允許應用程序即使在過濾驅動載入到文件系統或卷設備對象之前也能夠直接與過濾驅動進行通信。
注意：文件系統也會創建控制設備對象。當文件系統過濾驅動將其自身附加到文件系統之上時（而不是附加到某一特定文件系統卷），過濾驅動同樣將其自身附加到文件系統的控制設備對象之上。

在FileSpy驅動範例中，控制設備對象按如下方式創建：

RtlInitUnicodeString(&nameString, FILESPY_FULLDEVICE_NAME);
status = IoCreateDevice(
DriverObject, //DriverObject
0, //DeviceExtensionSize
&nameString, //DeviceName
FILE_DEVICE_DISK_FILE_SYSTEM, //DeviceType
FILE_DEVICE_SECURE_OPEN, //DeviceCharacteristics
FALSE, //Exclusive
&gControlDeviceObject); //DeviceObject

RtlInitUnicodeString(&linkString, FILESPY_DOSDEVICE_NAME);
status = IoCreateSymbolicLink(&linkString, &nameString);

與文件系統不同，文件系統過濾驅動並不是一定要為其控制設備對象命名。如果傳遞給DeviceName參數一個非空（Non-NULL）值，該值將作為控制設備對象的名稱。接下來，在前面的代碼範例中DriverEntry可以調用IoCreateSymbolicLink常式來將該對象的核心模式名稱與應用程序可見的用戶模式名稱關聯到一起（同樣可以通過調用IoRegisterDeviceInterface來使設備對象對應用程序可見）。
注意：由於控制設備對象是唯一不會附加到設備堆棧中的設備對象，因此控制設備對象是唯一的可安全命名的設備對象。由此，是否為文件系統過濾驅動的控制設備對象是否命名是可選的。
注意：文件系統的控制設備對象必須命名。過濾設備對象從不命名。

㈢ 數據防泄露的技術變革

透明加密技術是近年來針對企業數據保密需求應運而生的一種數據加密技術。所謂透明，是指對使用者來說是透明的，感覺不到加密存在，當使用者在打開或編輯指定文件時，系統將自動對加密的數據進行解密，讓使用者看到的是明文。保存數據的時候，系統自動對數據進行加密，保存的是密文。而沒有許可權的人，無法讀取保密數據，從而達到數據保密的效果。

自WindowsNT問世以來，微軟提出的分層的概念，使透明加密有了實現的可能。自上而下，

應用軟體，應用層APIhook(俗稱鉤子), 文件過濾驅動，卷過濾驅動，磁碟過濾驅動，另外還有網路過濾驅動，各種設備過濾驅動。其中應用軟體和應用層apihook在應用層(R3), 從文件過濾驅動開始，屬於內核層(R0).

數據透明加密技術，目前為止，發展了3代，分別為

第一代APIHOOK應用層透明加密技術；

第二代文件過濾驅動層（內核）加密技術；

第三代內核級縱深加密技術 ；

第一代：APIHOOK應用層透明加密技術

應用層透明加密技術俗稱鉤子透明加密技術。這種技術起源於win98時代，後來隨著windows2000而流行起來。就是將上述兩種技術（應用層API和Hook）組合而成的。通過windows的鉤子技術，監控應用程序對文件的打開和保存，當打開文件時，先將密文轉換後再讓程序讀入內存，保證程序讀到的是明文，而在保存時，又將內存中的明文加密後再寫入到磁碟中。應用層APIHOOK加密技術，特點是實現簡單，缺點是可靠性差，速度超級慢，因為需要臨時文件，也容易破解。但由於直接對文件加密直觀感覺非常好，對於當初空白的市場來講，這一旗號確實打動了不少企業。

第二代：文件過濾驅動加密技術

驅動加密技術是基於windows的文件系統（過濾）驅動技術，起源於WindowsNT發布之後，其工作在windows的內核層，處於應用層APIHook的下面，卷過濾和磁碟過濾的上面。設計思想是建立當應用程序(進程)和文件格式(後綴名)進行關聯，當用戶操作某種後綴文件時對該文件進行加密解密操作，從而達到加密的效果。

內核層文件過濾驅動技術，分IFS和Minifilter2類。IFS出現較早，Minfilter出現在xp以後。兩者的區別可以理解為VC++和MFC的區別，IFS很多事情需要自己處理，而Minifilter是微軟提供了很多成熟庫，直接用。由於windows文件保存的時候，存在緩存，並不是立即寫入文件，所以根據是否處理了雙緩bug，後來做了些細分，但本質還是一樣，都是問題的修正版本而已。但由於工作在受windows保護的內核層，運行速度比APIHOOK加密速度快，解決了很多問題和風險。

文件過濾驅動技術實現相對簡單，但穩定性一直不太理想。

第三代：內核級縱深沙盒加密技術

之所以叫內核級縱深沙盒加密技術，主要原因是使用了磁碟過濾驅動技術，卷過濾驅動技術，文件過濾驅動技術，網路過濾驅動(NDIS/TDI)技術等一系列內核級驅動技術，從上到下，縱深防禦加密。該技術也起源於WindowsNT之後，但由於技術復雜，開發要求高，公開資料少，而發展較慢。但隨著微軟公布了部分Windows源代碼之後，此技術開始逐漸成熟。內核級沙盒加密，是當使用者操作涉密數據的時候，對其存儲過程進行控制，對其結果進行加密保存，每個模塊只做自己最擅長的那塊，所以非常穩定。加密的沙盒是個容器，把涉密軟體，文件扔到容器中加密。而這個容器是透明的，使用者感覺不到它的存在。，

第三代透明加密技術的特點是，涉密數據使用前，先初始化涉密沙盒，沙盒加密一旦成功，之後所有的數據都是數據實體，不針對文件個體，所以無數據破損等問題。特點是速度快，穩定。

第一代，第二代本質都是採用的針對單個文件實體進行加密，如a.txt內容為1234, 加密後變成@#$%% +標記。@#$%%是把原文1234進行加密之後的密文。而標記的用途是用來區分一個a.txt文件是否是已經被加密。當系統遇到一個文件的時候，首先判斷這個標記是否存在，如果存在，表明是被系統加密過的，則走解密讀取流程，如果不是加密的，就無需解密，直接顯示給使用者，只是當保存的時候，再進行加密，使其成文密文+標記。

這就帶來一個巨大的風險 ：如果是一個較大文件，加密過程中發生異常，標記沒加上，那麼下次讀這個文件的時候，因為沒有讀到表記，而採用原文讀取，然後再加密，那麼這個文件就徹底毀壞了。這個現象在第一代APIHOOK透明加密技術的產品中特別明顯，在第二代文件過濾驅動產品中，因為速度變快了，使文件破損發生概率減低了很多，但並沒有本質解決這個問題。

另外， 由於是進程和文件後綴名進行關聯，也造成了一個缺陷 ：很多編程類軟體，復雜制圖軟體的編譯，曬圖等操作，都是很多進程同時操作某個文件，這個時候進行進程和文件關聯顯然太牽強了，因為進程太多了。即使進行關聯，多個進程交替訪問文件，加密解密混在一起，極容易造成異常。所以才會出現VC等環境下如不能編譯，調試等。

其他方面，版本管理無法對比，伺服器上存放的是密文（伺服器存密文，是個極大的風險，目前沒有哪家大企業敢這么做，畢竟太依賴加密軟體，持續性沒有了），大文件速度慢等，一系列問題，無法解決。

而第三代內核縱深加密技術是在前者2個基礎之上發展而來的，每個過濾層都只做自己最擅長的事情，所以特別穩定，速度快，性能可靠，不存在第一代和第二代的問題。由於內核級縱深透明加密技術要求高，涉及技術領域廣，極其復雜，開發周期長，所以國內的能做開發的廠商不多。目前， 深信達公司推出的SDC機密數據保密系統， 給人一眼前一亮的感覺，其產品是第三代透明加密保密技術的典型產品，其產品主要特點是：

1）採用了磁碟過濾，卷過濾，文件過濾，網路過濾等一系列縱深內核加密技術，採用沙盒加密，和文件類型和軟體無關，沙盒是個容器。

2）在操作涉密數據的同時，不影響上外網，QQ,MSN等。

3）保密徹底，包括網路上傳，郵件發送，另存，復制粘貼，屏幕截取等，特別是屏幕保密，做得非常炫。

4）服務上存放的是明文，客戶端存放的是密文，文件上傳伺服器自動解密，到達客戶端自動加密。伺服器上明文，減少了業務連續性對加密軟體的依賴。

5）不但可以針對普通文檔圖紙數據進行保密需求，同時更是研發性質的軟體公司( 游戲 ，通訊，嵌入式，各種BS/CS應用系統)源代碼保密首選。

㈣ 加密軟體公司哪家好

域之盾通過部署專業強大的企業數據加密軟體、圖紙加密軟體來對電腦文件進行加密，防止文件私自攜帶出去的行為，以保護電腦文件的安全。

1. 透明加解密
系統根據管理策略對相應文件進行加密，用戶訪問需要連接到伺服器，按許可權訪問，越權訪問會受限，通過共享、離線和外發管理可以實現更多的訪問控制。
2. 泄密控制
對打開加密文檔的應用程序進行列印、內存竊取、拖拽和剪貼板等操作管控，用戶不能主動或被動地泄漏機密數據。
3. 審批管理
支持共享、離線和外發文檔，管理員可以按照實際工作需求，配置是否對這些操作進行強制審批。用戶在執行加密文檔的共享、離線和外發等操作時，將視管理員的許可權許可，可能需要經過審批管理員審批。
4. 離線文檔管理
對於員工外出無法接入網路的情況可採用系統的離線管理功能。通過此功能授權指定用戶可以在一定時間內不接入網路仍可輕松訪問加密數據，而該用戶相應的安全策略仍然生效，相應數據仍然受控，文檔許可權也與聯網使用一樣。
5. 外發文檔管理
本功能主要是解決數據二次泄密的威脅，目的是讓發出的文檔仍然受控。通過此功能對 需要發出的文件進行審批和授權後，使用者不必安裝加密客戶端即可輕松訪問受控文件，且可對文件的操作許可權及生命周期予以管控。

6. 審計管理
對加密文檔的常規操作，進行詳細且有效的審計。對離線用戶，聯網後會自動上傳相關日誌到伺服器。
7. 自我保護
通過在操作系統的驅動層對系統自身進行自我保護，保障客戶端不被非法破壞，並且始終運行在安全可信狀態。即使客戶端被意外破壞，客戶端計算機里的加密文檔也不會丟失或泄漏。

㈤ 文件過濾驅動使用雙緩存機制是不是意味著物理內存也雙倍增加了

對的。
更好的了解雙緩沖機制原理,雙緩沖動機,以及如何去應用雙緩沖去解決一些問題,比如說編程問題、生活中事例等。
雙緩存類 * android雙向緩存, * 先緩存到內存,在緩存到SD卡 * 取的時候先取內存,如果內存沒有就去SD裡面取。

㈥ windows 文件系統驅動

網上搜楚狂人有一篇教程，還不錯

㈦ 如何卸載反病毒文件系統過濾驅動

您好：

這樣的情況可能是因為您以前安裝的安全軟體並沒有徹底卸載干凈回導致的軟體沖突，建議答您使用騰訊電腦管家的軟體管理裡面的卸載功能將以前安裝的安全軟體卸載干凈，並使用垃圾清理功能清理完卸載殘留以後再安裝新的安全軟體就可以了，並建議您使用騰訊電腦管家保護您的電腦，您可以點擊這里下載最新版的騰訊電腦管家：騰訊電腦管家最新版下載

騰訊電腦管家企業平台：http://..com/c/guanjia/

㈧ windows10文件驅動過濾

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 下使用() 函數。並且把以上幾種在不同環境下使用要處理的問題也做了簡單的介紹。且在 Q33 里介紹了在 CIFS 碰到的 FILE_COMPLETE_IF_OPLOCKED 問題的解決方法。

㈨ 如何構造一個簡單的USB過濾驅動程序

一、基本原理抄 我們知道，WDM（和KDM）是分層的，在構造設備棧時，IO管理器可以使一個設備對象附加到另外一個初始驅動程序創建的設備對象上。與初始設備對象相關的驅動程序決定的IRP,也將被發送到附加的設備對象相關的驅動程序上。

㈩ Load File Filter Driver failed 指的是什麼意思

裝載文件過濾驅動失敗