過濾驅動

㈠ 過濾驅動中打開文件時如何避免重入

在處理IRP_MJ_CREATE請求時，過濾驅動可能會使用不同的屬性/許可權等打開這個文件。這種情況經常發生在第二次調用ZwCreatefile時。這會導致生成一個對FSD 過濾驅動的回調(就是重入了).因而，正常的過濾驅動就要有能力檢測這種重入的問題。
There are several ways of dealing with reentrancy ring an IRP_MJ_CREATE operation, and the appropriate solution for your particular driver will depend upon the circumstances. In addition, there are a number of techniques that might work for a single file system filter driver, but that fail when used in a multi-filter environment.
在處理IRP_MJ_CREATE操作過程中，有幾種方法可以處理重入，處理你的驅動(中的重入)的適當方法取決於你的環境。另外，有許多種技術可以在單個文件系統過濾驅動上工作，但在多層過濾的環境下可能會失效。
For Windows XP and newer versions of Windows, the best mechanism for opening a file within the filter is to use . A filter driver can call this function and specify a given device object. The IRP_MJ_CREATE that is built will be passed to the specified device object. This technique avo
ids reentrancy issues and is the best mechanism available for a filter to open a file.
對Windows xp或者更新版的Windows來說，在過濾驅動中打開一個文件的最好方法是使用.文件過濾驅動可以調用這個函數並且指定一個給定的設備對象。
For versions of Windows prior to Windows XP, this mechanism is not available. The best mechanism in this environment is to implement your own functional equivalent of . This can be done by creating a second device object for each device you are filtering.
對Windows xp以前的Windows操作系統,這種方法無效。在這種環境下最好的方法是實現你自己的與等價的功能。這可以通過給你要過濾的設備創建第二個設備對象來實現。
For example, suppose you decide to filter some given file system device object, FSDVolumeDeviceObject. You then create a device object MyFilterDeviceObject and attach it using IoAttachDeviceToDeviceStack (of course, in Windows XP you would use instead). In addition, you create a second device object MyFilterShadowDeviceObject. This device object must be assigned a name ("DeviceMyFilterDevice27", for example). The name can be anything, but it must obviously be unique. In your device extension for your two device objects, you need to track this name, and you need to maintain pointers to the respective device objects (that is, the device extension for MyFilterShadowDeviceObject should point to MyFilterDeviceObject and the device object extension for MyFilterDeviceObject should point to yFilterShadowDeviceObject). Don't forget to set the StackSize field of the device object correctly!)
例如，假設你要過濾某個特定的文件系統設備對象,FSDVolumeDeviceObject(文件系統卷設備對象).這時你要創建一個設備對象MyFilterDeviceObject 並且使用IoAttachDeviceToDeviceStack 函數(在windows xp下使用 )來掛接它。另外，你還要創建第二個設備對象yFilterShadowDeviceObject.這個設備對象必須被指定一個名字(例如"DeviceMyFilterDevice27",注: 這里指的第二個設備對象,即Shadow device object )。名字可以是任意的，但必須唯一的。在這兩個設備的設備擴展結構中,你需要跟蹤這個名字
(注，其實就是做標志，你要知道你當前是處在哪個設備中,是第一個設備對象還是Shadow object )你需要維護一些指向相應的設備對象的指針(也就是說,MyFilterShadowDeviceObject的設備擴展要指向MyFilterDeviceObject，MyFilterDeviceObject的設備擴展對象要指向MyFilterShadowDeviceObject.不要忘了正確設置設備對象的StackSize成員變數。
Now, an IRP_MJ_CREATE request arrives in your filter, specifying MyFilterDeviceObject. To open the file without experiencing reentrancy problems, you call IoCreateFile (or ZwCreateFile). Since you must pass the name of the file being opened, you construct that by using both the name you gave MyFilterShadowDeviceObject and the name that is in the FileObject of the I/O stack Location (IoGetCurrentIr
pStackLocation(Irp)->FileObject).
現在,當IRP_MJ_CREATE 請求到達你的過濾驅動時,指定了 MyFilterDeviceObject.你調用IoCreateFile(或ZwCreateFile) 打開文件就沒有重入的問題了.以後，你必須傳遞這個打開的文件的名字,這個名字是用你設置在MyFilterShadowDeviceObject中的名字和從I/O 堆棧區域中得到的文件對象中的名字一起構造的。
Since you are passing a name in that points to your second device object, the I/O Manager will build the IRP_MJ_CREATE and pass the resulting I/O request packet to your driver, but specifying MyFilterShadowDeviceObject.

當你傳遞一個指向你的第二個設備對象的名字,I/O管理器會構建IRP_MJ_CREATE 並且傳遞I/O請求的結果到你的驅動，但指定了MyFilterShadowDeviceObject.
In your IRP_MJ_CREATE dispatch handler you must detect that this is a "shadow" device object, rather than a typical filter device object. In this case, you should send the IRP_MJ_CREATE operation down to the device being filtered by MyFilterDeviceObject. Indeed, since you should not need to do any further processing, you can use IoSkipCurrentIrpStackLocation (rather than ).
在你的IRP_MJ_CREATE 分發常式處理函數中，你必須檢測它是一個"Sahdow"設備對象而不是是一個典型的過濾設備對象。在這種情況下，你必須將IRP_MJ_CREATE操作下傳到已經被 MyFilterDeviceObject過濾了的設備中。確實,此後你不需要作進一步的處理，你可以用IoSkipCurrentIrpStackLocation函數(不是).

㈡ 什麼是過濾驅動

過濾驅動就是掛載在其他驅動上，對某設備的irp進行攔截過濾作用，可以對設備專進行功能屬擴展，或是數據加密等的驅動程序。

比如：

1. 可以對寫入硬碟的數據做加密，然後讀取的時候解密，這樣對於用戶來說，根本不知道有加密解密的過程，然後存在硬碟上的數據是加密的。

2. 可以對已有驅動做一些擴展，或者改變已有驅動的功能。比如已有驅動一次只能寫1024位元組的數據，那麼過濾驅動可以擴展到任何長度，然後分段調用已有驅動就是了。

過濾驅動可以在功能型驅動的上面，稱之為上層過濾驅動，或者高層，反正就這個意思。過濾驅動在功能型驅動下面，稱之為下層過濾驅動。看示意圖：

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

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

㈣ 過濾驅動怎麼安裝

換win7的啦 就沒問題

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

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

㈥ 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 問題的解決方法。

㈦ 我的電腦上有一個網路數據包過濾驅動是什麼意思

數據包過濾（packet filtering）是一個用軟體或硬體設備對向網路上傳或從網路下載的數據流進行有選擇的控制過程。數據包過濾器通常是在將數據包從一個網站向另一個網路傳送的過程中允許或阻止它們的通過（更為常見的是在從英特網向內部網路傳輸數據時，或從內部網路向英特網傳輸）。若要完成數據包過濾，你就要設置好規則來指定哪些類型的數據包被允許通過和哪些類型的數據包將會被阻止

㈧ 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來使設備對象對應用程序可見）。
注意：由於控制設備對象是唯一不會附加到設備堆棧中的設備對象，因此控制設備對象是唯一的可安全命名的設備對象。由此，是否為文件系統過濾驅動的控制設備對象是否命名是可選的。
注意：文件系統的控制設備對象必須命名。過濾設備對象從不命名。

㈨ 過濾的過程和方法

過濾的過程和方法

過濾是通過特殊裝置將流體提純凈化的過程，過濾的方式很多，使用的物系也很廣泛，固-液、固-氣、大顆粒、小顆粒都很常見。下面是我為大家帶來的關於過濾的過程和方法的知識，歡迎閱讀。

1過濾原理

主要包括遷移、附著和脫附三個過程。

2過濾周期及反沖洗

⑴過濾周期

工程應用中，設計和運行是以水頭損失來控制過濾周期，當濾料的水頭損失達到最大允許值時，就停止過濾，沖洗濾池。

⑵反沖洗的方法

①單獨用水反沖洗：用高速水流沖洗

優點：只需一套反沖洗系統。

缺點：沖洗耗水量大，當沖洗強度控制不當時，可能產生礫石承托層松動，沖洗後濾料因水力分級呈上細下粗的分層結構狀態。

②氣水聯合反沖洗：採用空氣和水流同時沖洗。

優點：沖洗效果好，耗用水量少小，沖洗過程中不需濾層流化。

缺點：需增加空氣系統，與單獨用水沖洗相比所需設備較多。

③帶表面輔助沖洗的水反沖洗

在濾層表面設置高速水沖洗系統，利用高速水流對表層濾料加以攪動，增加濾料顆粒的碰撞機會，利用高速水流的剪切作用來提高

反沖洗效果。

3濾池的.基本構造

主要由濾料層、配水系統和承托層組成。

⑴濾料層

①顆粒濾料過濾

廢水處理中可用石英砂、無煙煤、陶粒、纖維球、聚氯乙烯球等作為濾料。

例如以石英砂作濾料時，砂粒徑為0.5～2.0mm，該值大於給水濾池的石英砂粒徑(0.5mm);反沖洗強度可取18～20L/m2/s，亦大於給水過濾時的12～15 L/m2/s。

廢水懸浮物濃度高時，為了提高濾池的納污量，延長過濾周期，可採用粗濾料、雙層或三層濾料和上向流濾池。處理廢水的上向流

濾池為下部進水，上部出水，各層濾料截污力能完全發揮，水頭損失上升緩慢。

例如，處理廢水的某上向流濾池的濾料級配由上而下分別為：上部細砂層，砂粒徑為1～2mm，層厚1500mm;中部砂層，砂粒徑為2～

3mm，層厚300mm;下部粗砂層，砂粒徑10～16mm，層厚100mm。

②多孔濾料過濾

去除毛紡、化纖和造紙等行業廢水中的懸浮細纖維而採用的篩網過濾即為多孔濾料過濾。

⑵配水系統和承托層

配水系統一般分為大阻力配水系統和小阻力配水系統兩類。

承托層一般是配合管式大阻力配水系統使用，若採用中小阻力配水系統，且配水孔眼數量多、尺寸小，配水本身已很均勻，濾料本

身不會從孔眼漏掉的話，承托層可以適當減小或省去。

4濾池的分類

濾池按濾料組成分為：單層濾料、雙層濾料、多層濾料及混合濾料濾池。

按水流方向分為：下向流、上向流、雙向流和輻向流濾池。

按濾速大小分為：慢濾池、快濾池和高速濾池。

按濾池的布置或構造分為：普通快濾池、雙閥濾池、無閥濾池、虹吸濾池、移動沖洗罩濾池和V型濾池。

按過濾驅動力分為：重力濾池、壓力濾池。

5城市污水三級處理中過濾單元的設計要點(給排水設計手冊第5冊規定)

⑴濾池的反沖洗

三級處理中對濾池反沖洗的要求高，建議採用氣、水反沖洗與表面沖洗相結合的聯合反沖洗方式。

⑵濾池池型

避免選用虹吸濾池等反沖洗能力較差的池型，而應優考慮選用移動沖洗罩濾池、V型濾池和T型濾池等表面沖洗能力較強的池型。

由於雙閥濾池和四閥濾池具有技術成熟、運行穩定、操作可靠等優點，常被採用。

⑶濾池的設計參數

與給水處理中濾池的設計參數相比，在城市污水三級處理中濾層的厚度和濾料粒徑都較大，但濾速則略小。在城市污水三級處理中

過濾單元的主要設計參數主要為：

①濾層

主要有效粒徑、濾層厚度、不均勻系數，當濾料不同時，參數也有變化

②濾速：6～10m3 /m2h

③反沖洗：採用氣水聯合反沖、水沖洗和表面沖洗時分別有不同的參數。

④工作周期：≤12h

6壓力濾池和微孔篩濾機

⑴壓力濾池

是一個密閉的鋼罐，裡面裝有和快濾池相似的配水系統和濾料等，在壓力下操作運行。

在小規模的中水處理流程中過濾單元多採用壓力濾罐，其特點是佔地少，建設周期短，有定型產品，且運行管理方便。

⑵微孔篩濾機

是利用微孔篩濾網進行固液分離，過濾機理主要是機械篩濾作用。

特點是佔地面積小，處理量大，操作管理方便，在啤酒生產廢水的預處理中獲得廣泛應用。

設計參數：

濾網孔徑為35～60μm，水力負荷：0.1～0.4m3 /m2min，水頭損失小於0.3～0.5m，反沖洗水量占總濾水量的1%～3%。

過濾的內容非常重要，在給水處理以及城市污水三級處理中都要用到濾池的設計，所以要認真復習。出題時可能出敘述性的，也有

;

㈩ 怎樣才能關閉電腦的過濾器驅動程序啊

以下為復製成分 WDM(Windows Driver Mode)是微軟公司為Windows的驅動程序設計的一種通用的驅動程序模型。相比以前的KDM和VXD來說，他的性能更高、系統之間移植更加方便。所以，隨著系統的升級，WDM已經成為Windows 2000系統下驅動程序開發的主流。作為WDM模型之中一類特殊的驅動程序，過濾器驅動程序(Filter driver)可以在不更改現有驅動程序的情況下，方便地修改、增加現有驅動程序的功能。特別是對於Windows 2000已經提供了通用驅動程序的硬體設備，通過編寫過濾器驅動程序，可以以較小的代價擴展硬體現有的功能。因此具有很強的實際應用價值。 1 Windows 2000 I／O請求處理結構如圖1所示，Windows 2000是分態的操作系統。用戶應用程序運行在用戶態，操作系統代碼(如系統服務和設備驅動程序)在核心態下運行。用戶態程序只能調用Win32子系統提供的API來同設備交互，當請求傳遞到I／O管理器時，他進行必要的參數匹配和操作安全性檢查，然後由這個請求構造出合適的IRP(IO Request Package，I／O請求包)，並把此IRP傳遞到適當的驅動程序去，並給應用程序一個消息，通知這次I／O操作還沒完成。驅動程序一般通過硬體抽象層來和硬體交互，從而完成I／O請求工作。驅動程序完成I／O操作後，他將調用一個特殊的內核服務常式來完成IRP。這時，I／O管理器把數據和結果返回給Win32和用戶應用程序。2 WDM驅動程序模型體系結構Windows驅動程序模型重新定義驅動程序分層使用了如圖2的層次結構。圖中左邊是一個設備對象堆棧。設備對象是系統為幫助軟體管理硬體而創建的數據結構。一個物理硬體可以有多個這樣的數據結構。處於堆棧最底層的設備對象稱為物理設備對象PDO(Physical Device Object)，代表了設備和匯流排之間的連接。在設備對象堆棧的中間的對象稱為功能設備對象FDO(Functional Device Object)，代表了設備的功能。在FDO的上面和下面還會有一些過濾器設備對象FIDO(Filter Device Object)。位於FDO上面的過濾器設備對象稱為上層過濾器，位於FDO下面(但仍在PDO之上)的過濾器設備對象稱為下層過濾器。匯流排驅動程序負責枚舉他的匯流排，這意味著發現匯流排上的全部設備和檢測設備何時被添加或刪除並為每個設備創建一個PDO。功能驅動程序知道如何控制設備的主要功能，他分層在匯流排驅動程序的上面。功能驅動程序創建一個功能設備對象，放在設備棧中。對匯流排上的所有設備，匯流排過濾驅動程序被加在匯流排驅動程序之上；設備過濾驅動程序僅對特定的設備添加。上層的過濾驅動程序在功能驅動程序之上，而下層過濾驅動程序在功能驅動程序之下。這種層次結構可以使I／O請求過程更加明了。I／O管理器發送的IRP，先被送到設備堆棧的上層過濾器驅動程序(FIDO)，他可以根據要求決定IRP的處理方式，是沿著設備棧繼續向下傳，或者是做一些額外的處理。依次，每一層驅動程序都可以決定如何處理IRP。高層的驅動程序可以把請求劃分成更簡單的請求並傳遞給下層驅動程序。中間層次的驅動程序進一步處理請求，將一個IRP中的請求劃分為若干個小的請求並傳給下層驅動程序。最後，最低層的驅動程序與硬體打交道。因此一些IRP在到達匯流排程序之前，在設備棧傳遞過程中可能就被過濾掉了。 3 過濾器驅動程序過濾驅動程序是一種中間驅動程序，他位於其他的驅動程序層次之間。過濾驅動程序可以監視、攔截和修改IRP流，在不影響其他驅動程序的前提下提供一些附加的功能。他的功能可分為：(1)利用過濾器驅動程序修改現有功能驅動程序的行為而不必重新編寫功能驅動程序。(2)上層過濾器驅動程序在功能驅動程序之前看到IRP，可以很方便地為用戶提供額外的特徵。還可以修正功能驅動程序或硬體存在的毛病或缺陷。(3)下層過濾器驅動程序在功能驅動程序要向匯流排驅動程序發送IRP時看到IRP。可以監視、攔截、修改功能驅動程序要執行的匯流排操作流，截獲數據，進行必要的數據處理，再將處理過的數據傳遞下去，實現一定的數據處理功能。 (4)下層過濾器驅動程序可以實現驅動程序的匯流排無關性，使功能驅動程序完全獨立於匯流排結構而不直接與設備對話。針對不同的匯流排編寫不同的下層過濾器，每個下層過濾器對應一個匯流排類型。當功能驅動程序需要與硬體對話時，他只需向相應的下層過濾器驅動程序發送IRP即可。4 過濾器驅動程序設計過濾器驅動程序設計與功能驅動程序相似。這里限於篇幅主要討論一下過濾器驅動程序設計中與功能驅動程序相區別的幾個關鍵的技術要點。4．1 DriverEntry常式DriverEntry常式是驅動程序的人口點。當I／O管理器裝入驅動程序時，他調用DriverEntry常式用來初始化驅動程序范圍的數據結構和資源，包括輸出該驅動程序的其他人口點，初始化該驅動程序使用的特定對象，並設置驅動程序系統資源。與功能驅動程序相區別的是：他必須為每種類型的IRP都安裝派遣函數，而不僅僅只是其希望處理的IRP。4．2 AddDevice常式AddDevice函數的基本職責是創建一個設備對象並把他連接到以物理設備對象PDO為底的設備堆棧中，並負責設備對象初始化。與功能驅動程序相區別的是：過濾驅動程序創建的設備對象可能是2種，一種是不命名的過濾設備對象，過濾器工作時把這個無名的設備對象連接到以物理設備對象PDO為底的設備堆棧中。一種是為了和用戶程序通信而創建的命名的設備對象並不連接到以物理設備對象PDO為底的設備堆棧中。命名可以採用2種方法：第一種方法是採用可顯示的"硬編碼"符號鏈接名，用戶態程序必須把設備名硬編碼到源代碼中；另外一種方法是使用設備介面，每個設備介面是由一個全局惟一標志符GUID標志。設備注冊為一個特定的設備介面就創建了一個符號鏈接。相關步驟如下：(1)調用IoCreateDevke創建過濾設備對象，並建立一個私有的設備擴展對象。(2)寄存一個或多個設備介面，以便應用程序能知道設備的存在。另外，還可以給出設備名並創建符號連接。(3)初始化設備擴展和設備對象的F1ag成員。(4)調用IOAttachDevkeToDeviceStack函數把新設備對象放到堆棧上。具體實現程序如下：NTSTATUS AddDevice (PDRIVER_OBJECT DriverObject， PDEVICE_OBJECT pdo){PDEVICE_OBJECT fido=NULL；／／創建沒有設備名的過濾設備對象NTSTATUS status=IoCreateDevice (DriverObjeot，sizeof (DEVICE-EXTENSION)，NULL，FILE_DEVICE_UNKNOWN，0，FALSE，&fido)；if(！NT_SUCCESS(status)) return status；／／初始化設備擴展和設備對象的Flag成員PDEVICE_EXTENSION pdx = (PDEVICE_EXTENSION)fido-＞DeviceExtension；pdx-＞DeviceObject=fido；pdx-＞Pdo=pdo；pdx-＞eDeviceType =FILTER-p.htm" target="_blank" title="FILTER貨源和PDF資料">FILTER；／／把沒有設備名的設備對象放到堆棧上PDEVICE- OBJECT fdo =IoAttachDeviceToDeviceStack (fido，pdo)；pdx-＞TopDevObj=fdo；fido-＞Flags ︱=pdo-＞F1ags&(DO_DIRECT-IO ︱DO-BUFFERED-IO ︱ DO_POWER_PAGABLE ︱DO_POWER_INRUSH)；………／／建立一個命名的設備對象創建符號鏈接CreateSymbOlicLink (DriverObject，pdo)；return STATUS_SUCCESS；}4．3 派遣常式派遣常式處理來自應用程序的打開、關閉、讀、寫等I／O請求命令。與功能驅動程序的區別是：過濾器驅動程序不能影響其他驅動程序接受IRP。對於未知的IRP或不處理的IRP過濾驅動程序的原則是必須沿設備棧傳遞下去。因此他必須為每種類型的IRP都安裝派遣函數，而不僅僅只是其希望處理的IRP。對於希望處理的IRP必須指定特殊的派遣函數，直接用CompleteIRP來完成接收到的這類IRP，不往下層傳送。這里由DispatchDeviceControl處理來自應用程序的所有希望處理的I／O操作命令。通常採用給予所有自定義的I／O請求代碼的SWITCH-p.htm" target="_blank" title="SWITCH貨源和PDF資料">SWITCH語句，而對於每個命令使用相應的處理函數。下面列出了主要的代碼框架：NTSTATUS DispatchDeviceControl (PDEVICE_OBJECT fido，PIRP Irp){NTSTATUS status；PDEVICE_EXTENSION pdx=(PDEVICE_EXTENSION)fido-＞DeviceExtension；PlO_STACK_LOCATION IrpStack =IoGetCurrentlrpStackLocation(1rp)；／／取I／O控制命令代碼ULONG IoControlCode = IrpStack >Parameters．DeviceloContr01．IoControlCode；switch(IoControlCode){case IOCTL-XXX：…… ／／處理I／O控制命令代碼case IOCTL-XXX：……default：……break；}／／完成接收到的IRPIoCompleteRequest(Irp，IO_NO_INCREMENT)；……return status；}對於不需要處理的IRP則交由DispatchAny常式處理，將IRP沿著設備棧直接傳遞下去：NTSTATUS DispatchAny(PDEVICE_OBJECT fido，PIRP Irp){PDEVICE_ EXTENSION pdx=(PDEVICE-EXTENSION)fido-＞DeviceExtension／／使堆棧指針少前進一步。IoSkipCurrentlrpStackLocation(hp)；Status=IoCallDriver(pdx-＞LowerDeviceObject，Irp)；……return status；4．4 Unload常式功能在Unload常式中，驅動程序必須釋放所有創建的對象和所有分配給驅動程序的資源。5 結 語筆者就採用在Windows提供的USB音效卡驅動程序下方插入自己編寫的下層過濾器驅動程序實現了對USB音效卡輸出的數據流的截獲並進行語音信號處理，取得了不錯的效果，現已投入實際應用。可見過濾器驅動程序作為一類特殊的驅動程序，它可以以較小的代價實現對驅動數據流的截獲，修改、增加現有驅動常需的功能，具有很強的實用性。
類別：驅動 | 添加到搜藏 | 瀏覽(254) | 評論 (0) 上一篇：VMware虛擬機中如何安裝VMWare-T... 下一篇：今天離婚，你得抱我出門 相關文章： �6�1Windows文件系統的過濾器驅動程... 最近讀者： 登錄後，您就出現在這里。 蝶舞360°jacky85chan 網友評論：