<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

依據本人日前提交的《ISA服務異常診斷思路與步驟》中描述的診斷思路，今天連同客戶方工程師對ISA故障進行了再次調試。時間為10點至18點。

今天計劃如下調試工作：

1. 繼續進行數據包分析、采用更加專業的網絡分析工具及數據包分析軟件、檢測在ISA通信過程中是否存在異常信源、特殊結構數據包、攻擊攜帶的淹沒數據報、重點對PSP軟件采用的協議與信令進行元數據分析，考量以上內容中可能出現的對ISA服務失敗的誘因。

2. 再次對之前診斷過程中存在疑慮的問題進行剖析、對Cache、DNS、防火墻系統策略與用戶策略的一致性問題、ISA內核dump參數進行確認。

3. 確認SYN攻擊是否是造成ISA服務失敗的主要原因。

4. 以上步驟如不湊效、重新安裝Windows、重新部署ISA并導入原有配置及策略。

實際調試進展

1. 今天上網用戶為5用戶、會話數為175個、經過對數據包抓包、分析

采用wireshark1.0.1軟件進行數據包分析、在進行數據包分析過程中、系統再次失敗，數據包分析中發現ISA通訊中存在大量的WinSocket請求、其中這些請求中AFD數據塊大量重復產生、查看每個會話中數據報文內容、我們可以分析到存在以下問題：

l WinSocket請求較多、雖然Socket鏈接本身是正常的，但是問題出在，許多Socket連接在會話結束后，該連接占用的系統資源沒有被正常釋放掉、由于Socket連接會消耗操作系統的核心轉儲資源，如非分頁文件池、windows核心態系統緩存、windows用戶態系統緩存、上位內存區域等重要資源，因此此請求需要進一步分析連接請求的釋放存在哪些異常。

l TCP半連接數非常多、這些半連接數在整個網絡當中有相當一部分是由05016用戶發出的，經過查看ISA日志、由迅雷進程引起。通過分析迅雷的原理、迅雷軟件本身具備P2P性質、而且每個迅雷的版本采用的P2P方式都有不同、有的采用隨機端口、有的采用高位端口、有的走UDP協議、有的走HTTP的80端口、因此對于迅雷不宜采用ISA策略的限制方式，而應該考慮限制迅雷進程的帶寬與流量。

l 分析部分數據包、數據包內容中有異常數據，在一個數據會話中，我們可以看到

0000140000001D4669FF866BD7E17338.......Fi..k..s8
7E086870F25CA3CB7F56140000005000~.hp./...V....P.
00001000000030304530344342363332......00E04CB632
3030352E6578650F0000003232312E32005.exe....221.2
33392E3137302E31313600050C00000F39.170.116......
0000003232312E3233392E3137302E31...221.239.170.1
3136520000001000000030303044383716R.......000D87
354434454638303030300F000000473A5D4EF80000....G:
003232312E3233332E3231382E313738.221.233.218.178
00050C00000F0000003232312E323333.........221.233
2E3231382E3137385500000010000000.218.178U.......
3030443046383341373932463030303000D0F83A792F0000
73662E6578650F0000003231392E3132sf.exe....219.12
382E3230352E31333800050C00000F008.205.138.......
00003231392E3132382E3230352E3133..219.128.205.13
384E00000010000000303030433736308N.......000C760

存在多個數據轉發源、進一步分析還是迅雷的問題，看來要防止如何將這種不斷增長的源控制在一個正常的非分頁文件池大小內才是關鍵。

2. 非分頁文件池問題

非分頁文件池是操作系統中內存管理的非常重要的一部分。其管理機制如下：

Windows2000/XP內存管理器位于Ntoskrnl.exe文件中，硬件抽象層中沒有內存管理器的任何部分。

內存管理器是完全可重入的，支持多進程并發執行。

內存管理器組成部分：

1） 一組執行體系統服務程序：用于虛擬內存的分配、回收和管理。

2） 一個轉換無效和訪問錯誤陷阱處理程序：用于解決硬件檢測到的內存管理異常，并代表進程將虛擬頁面裝入內存。

3） 運行在六個不同的核心態系統線程上下文中的幾個關鍵組件：

——工作集管理器：優先級16，每秒鐘被平衡集管理器（一個內核創建的系統線程）調用一次。

——進程/堆棧交換程序：優先級23，完成進程和內核線程堆棧的換入和換出操作。

——已修改頁面寫入器：優先級17，將修改鏈表上的臟頁寫回到適當的頁文件。

——映射頁面寫入器：優先級17，將映射文件中臟頁寫回磁盤。

——廢棄段線程：優先級18，負責系統高速緩存和頁面文件的擴大和縮小。

——零頁線程：優先級0，將空閑鏈表中的頁面清零。

地址空間的布局：

Win32環境下，32位的地址空間轉化為4GB的虛擬內存。默認情況下，將一半（2GB）分配給用戶進程，另一半（2GB）分配給操作系統。

Windows2000/XPAdvancedServer版本和Windows2000/XPDataCenter版本支持一個引導選項（Boot.ini中通過/3GB標識激活），允許用戶擁有3GB地址空間，留1GB給操作系統。

對于要訪問整個3GB地址空間的進程，進程映像文件必須在映像頭設置IMAGE-FILE-LARGE-ADDRESS-AWARE標識，否則系統將保留第3個GB的地址空間。可以通過指定鏈接標識/LARGEADDRESSAWARE來設置該標識。如果與此鏈接程序開關相鏈接，則可以使用3GB用戶方式地址空間。

2GBWindows2000/XP用戶地址空間分布

——NULL指針分配的分區：0x0～0xFFFF

——進程私有地址空間：0x10000～0x7FFEFFFF

——64KB拒絕訪問區域：0x7FFF0000～0x7FFFFFFF，阻止線程跨過用戶/系統邊界傳送緩沖區。

Windows2000/XP用戶地址空間系統變量

——MmHighestUserAddress：描述最高用戶地址（對于x862GB用戶空間為0x7FFEFFFF）

——MmUserProbeAddress：描述最高用戶地址＋1

性能計數器：Windows2000/XP中可利用性能計數器得到系統虛擬內存的使用信息，和單個進程地址空間的使用情況。

x86系統地址空間分布

——0x80000000~0x9FFFFFFF：引導系統（Ntoskrnl.exe和Hal.dll）和非分頁緩沖池初始部分的系統代碼。

——0xA0000000~0xA3FFFFFF：系統映射視圖（如Win32k.sys）或者會話空間。

——0xA4000000~0xBFFFFFFF：附加系統頁表項（PTE）或附加系統高速緩存。

——0xC0000000~0xC03FFFFF：進程頁表和頁目錄，描述虛擬地址映射的結構。

——0xC0400000~0xC07FFFFF：超空間和進程工作集列表。

——0xC0800000~0xC0BFFFFF：未使用區域，不可訪問。

——0xC0C00000~0xC0FFFFFF：系統工作集鏈表，描述系統工作集的工作集鏈表數據結構。

——0xC1000000~0xE0FFFFFF：系統高速緩存，用來映射在系統高速緩存中打開的文件的虛擬空間。

——0xE1000000~0xEAFFFFFF：分頁緩沖池，可分頁系統內存堆。

——0xEB000000~0xFFBDFFFF：系統頁表項和非分頁緩沖池。

——0xFFBE0000~0xFFFFFFFF：系統性故障轉儲信息和硬件抽象層（HAL）使用區域。

會話空間：用來映射一個用戶的會話信息。

——進程創建時，會將會話空間映射到屬于該進程會話的頁面。

——會話是由進程和其他系統對象組成，每個會話有私有的GUI數據結構，以及Win32子系統進程（Csrss.exe）和登錄進程（Winlogon.exe）的拷貝。

——會話管理器進程（Smss.exe）負責創建新的會話。

地址轉換機制

用戶應用程序以32位虛擬地址方式編址，每個虛擬地址與一個稱作“頁表項”（PTE）的結構有關，它包含了虛擬地址映射的物理地址。

1． 虛擬地址變換

x86系統利用二級頁表結構實現虛擬地址向物理地址的變換。

x86系統中，32位虛擬地址分成三個部分：頁目錄索引（10bit）、頁表索引（10bit）、字節索引（12bit）。

虛擬地址變換的基本步驟：

——內存管理的硬件設備定位當前進程的頁目錄；

——頁目錄索引指出頁目錄項在頁目錄中的位置，頁目錄項中的頁框號描述了映射虛擬地址所需頁表的位置；

——頁表索引指出頁表項在頁表中的位置，頁表項描述了虛擬頁面在物理內存的位置；

——當頁表項指向的頁面有效時，字節索引指明物理頁內所需數據的地址；若所指頁面無效，則交由內存管理器的故障處理程序處理。

2． 頁目錄

每個進程都有一個單獨的頁目錄，用來映射進程所有頁表的位置，其物理地址被保存在核心進程（KPROCESS）塊中。

進程切換時，操作系統設置一個專用的CPU寄存器來通知硬件設備新進程頁目錄所在地址。

頁目錄是由頁目錄項（PDE）組成，每個頁目錄項4字節。x86中，描述4GB虛擬地址空間需要1024張頁表，因此頁目錄索引10位。

3． 進程頁表與系統頁表

進程頁表是每個進程私有的，而系統頁表被所有進程共享。

當進程創建時，系統空間的頁目錄項初始化為指向現存的系統頁表，但各個進程的系統空間不完全相同。當系統頁表更新時，內存管理器不會立刻更新所有進程頁目錄，而是當進程訪問新的虛擬地址時才更新進程頁目錄。

性能監視器中的空閑系統頁表項計數器表示了可用系統頁表項的數目，也可在HKLM/SYSTEM/CurrentControlSet/Control/SessionManager/MemoryManagement/SystemPages中設置需要的頁表項數量。

4． 頁表項

有效的頁表項有兩個主要的域：

（1）包含數據的物理頁面的頁框號，或內存中某頁面的物理地址的頁框號；

（2）一些描述頁的狀態和保護限制的標志位。

——訪問位：某頁首次被讀寫時，置為“1”

——修改位：某頁首次被寫時，置為“1”

——寫位：為0時，對應頁只讀，為1時，對應頁可讀寫

——多處理器的x86系統中，有個附加的由軟件實現的寫位，用來表示某頁已經被一個運行在多個處理器上的線程寫入。

x86中（非PAE系統），映射4GB地址空間需要1024張頁表，每個頁表含1024個頁表項，每個頁表項4字節，因此頁表索引為10bit。

5． 快表TLB

x86提供了關聯存儲器數組形式的高速緩存，稱為快表。它是一個向量，其存儲單元能被同時讀取并與目標值比較。

快表中每個項的標志符部分保存了虛擬地址的一部分，數據部分保存了物理頁號及對應頁的保護類型和狀態。

將常用的虛擬地址記錄在快表項中，減少了對內存的訪問，加快了虛擬地址到物理地址的變換。

如果一個虛擬地址不在快表中，它可能仍在內存中，需要對內存多次訪問來找到它。當一個頁表項由無效變為有效時，內存管理器會調用內核例程將新頁表項裝入快表，x86中，裝入快表不需要軟件干預。

用戶空間內存分配方式

首先介紹兩個與內存分配相關的數據結構（虛擬地址描述符和區域對象），然后介紹三種管理應用程序內存的方法。

1． 虛擬地址描述符

虛擬地址描述符（VAD）用來描述哪些虛擬地址已經在進程地址空間中被保留。對個進程，內存管理器都維持一棵虛擬地址描述信息樹，用來描述進程地址空間狀態。

當進程保留地址空間，或映射一個內存區域時，就創建一個VAD來保存分配請求所提供的信息。當線程首次訪問一個地址時，需找到一個包含被訪問地址的VAD，利用所得信息填充頁表項。

2． 區域對象

區域對象在Win32中也稱文件映射對象，表示可以被兩個或多個進程共享的內存塊，也可被映射到頁文件或外存文件。

主要作用

——將可執行映像裝入內存

——訪問高速緩存文件中的數據

——將文件映射到進程地址空間，不必進行文件I/O

每個打開文件都有一個單獨的區域對象指針結構，由三個32位指針組成：指向數據控制區域的指針、指向共享的高速緩存映射的指針、指向映像控制區域的指針。

CreatFileMapping函數可以創建區域對象；OpenFileMapping打開有名字的區域；可通過句柄繼承或句柄復制訪問區域對象；設備驅動程序可使用ZwOpenSection，ZwMapViewOfSection，ZwUnmapOfSection函數操縱區域對象。

3． 以頁為單位的虛擬內存分配方式

適合于大型對象或結構數組

進程地址空間的頁面有三種狀態：空閑、被保留、被提交；保留和提交功能是通過Win32VirtualAlloc和VirtualAllocEx函數實現的。

應用程序可以同時進行保留和提交，也可以先保留地址空間，當需要時再向地址空間提交物理頁面，這樣可以減少內存的使用。

VirtualFree或VirtualFreeEx函數用來回收頁面或釋放地址空間。回收的內存仍然被保留，而釋放的內存是空閑的。

4． 內存映射文件

適合于大型數據流文件以及多個進程之間的數據共享

內存映射文件用來保留一個地址區域，并將磁盤文件提交給該區域，用于3個目的

——加載和執行.exe和.dll文件，可節省應用程序啟動所需時間

——訪問磁盤數據文件，減少文件I/O

——實現多個進程間的數據共享

利用區域對象實現這些功能，因為區域對象可以鏈接到打開的磁盤文件（映射文件），或已提交的內存（提供共享內存）。

進程要訪問非常大的區域對象，可以通過調用MapViewOfFile函數映射區域對象的一部分（區域視圖），并指定映射范圍。

5． 堆功能

內存堆的應用程序內存管理方法適合于大量的小型內存申請

堆是保留的地址空間中一個或多個頁組成的區域，可由堆管理器進一步劃分和分配

堆管理器用來分配和回收可變內存，其函數位于Ntdll.dll和Ntoskrnl.exe中。

進程啟動時有一個缺省堆，通常為1MB，它在進程生命周期中不能被釋放；而HeapCreat函數創建的私有堆可以用HeapDestroy來釋放。

從缺省堆中分配內存時，先調用GetProcessHeap函數得到句柄，再調用HeapAlloc和HeapFree來分配和回收內存塊。

系統內存分配

系統初始化時，創建了兩種動態大小的內存緩沖池來分配系統內存，ExAllocatePool函數可從緩沖池中分配和回收內存：

——非分頁緩沖池：由長駐物理內存的系統虛擬地址區域組成。

——分頁緩沖池：系統空間中可以被分頁和換出的虛擬內存區域。

兩種非分頁緩沖池：一般情況下使用；4頁緩沖池在非分頁緩沖池已漫且不允許分配失敗時使用。

分頁緩沖池：單處理器系統3個，多處理器系統5個

分頁/非分頁緩沖池初始大小依賴于系統物理內存大小，可設置HKLM/SYSTEM/CurrentControlSet/Control/SessionManager/MemoryManagement的NonpagedPoolSize和PagedPoolSize值改變緩沖池大小。

快速內存分配機制——后備鏈表：僅包含固定長度的塊，因此不必查找適合分配大小的空閑內存。

若后備鏈表為空時，必須從分頁或非分頁緩沖池中進行分配。可使用ExInitializeNpagedLookasideList和ExInitializePagedLookasideList函數按照頻繁分配的數據結構大小創建后備鏈表。

缺頁處理

對無效頁面的一次訪問稱為缺頁錯誤，由內存管理故障處理程序解決。

1． 四個基本類型的無效頁表項

頁文件：所需頁沒有駐留在內存，而是駐留在頁文件中，并引發頁面調入操作。

請求零頁：所需頁是零頁面，此時會給進程工作集添加一個由零初始化的頁。

轉換：所需頁面在內存中的后備鏈表、修改鏈表或修改尚未寫入鏈表。此時從鏈表中刪除此頁，并添加到工作集。

未知：頁表項為0，或頁表不存在。此時需檢查VAD以確定虛擬地址是否被提交。

2． 一個特例——原型頁表項

區域對象第一次被創建時，同時創建原型頁表項，它用于實現頁面共享。

當共享頁面為有效時，進程頁表項和原型頁表項都指向包含數據的物理頁。

當共享頁面無效時，進程頁表項指向原型頁表項，而原型頁表項描述被訪問的頁面的狀態（活動/有效、轉換、修改尚未寫入、請求零頁、頁文件、映射文件6種）

3． 頁面調入I/O

當必須向文件（頁或映射文件）發出讀操作來解決缺頁問題時，將產生頁面調入I/O。

頁面調入I/O操作是同步的，線程會一直等待I/O完成。

當進行調頁I/O時，進程中的其他線程仍可以同時處理缺頁錯誤，因此在I/O結束時頁面調度程序必須識別如下情況：沖突頁錯誤、頁面從虛擬地址空間中被刪除、頁面保護限制發生變化、原型頁表項引發錯誤。

4． 沖突頁錯誤

同一進程中的另一線程或另一進程也對正在被調入的頁面產生缺頁錯誤，稱為沖突頁錯誤。

頁面調度程序檢測到沖突頁錯誤時，會對頁框號數據庫項中的特定事件發出等待操作。當I/O完成后，第一個獲得頁框號數據庫鎖的線程負責執行完成頁面調入操作。

5． 頁文件

虛擬存儲器在磁盤上的部分稱為頁文件。內存＝物理內存＋頁文件。

性能計數器可以檢查被提交的進程私有內存使用情況，但無法確切知道一個進程提交的私有內存中有多少常駐內存，多少在頁文件中。

Windows2000/XP最多支持16個頁文件。

系統啟動時，會話管理器進程讀取頁文件鏈表，并檢查HKLM/SYSTEM/CurrentControlSet/Control/SessionManager/MemoryManagement/PagingFiles打開頁文件，如果沒有，則創建一個缺省的20MB頁文件。系統運行期間不能刪除打開的頁文件。

系統進程為每個頁文件都維持一個打開的句柄，Ntdll.dll中的NtCreatePagingfile系統服務程序可增加一個新頁文件。

工作集

工作集即在物理內存中保持的虛擬頁面的子集，分進程工作集和系統工作集。

1． 頁面調度策略

取頁策略：內存管理器利用請求式頁面調度算法及簇方式將頁面裝入內存。當缺頁中斷時，將出錯頁面和它附近的一些頁面裝入內存，這樣可減少讀取外存的次數。

置頁策略：當線程收到頁錯誤時，內存管理器要使用“置頁策略”來確定在物理內存中放置虛擬頁面的最佳位置。

如果當頁錯誤發生時物理內存已滿，“置頁策略”要決定哪一個虛擬頁面必須從內存中刪去來為新的頁面騰出空間。多處理器系統中，采用局部先進先出（FIFO）策略，而單處理器系統中，采用最近最久未使用（LRU）替換策略。

2． 工作集管理

系統初始時，所有進程缺省的工作集最大最小值相同。有“增大調度優先級”權限的進程可用SetProcessWorkingSet函數來更改缺省值，但不能超過內核變量MmMaximumWorkingSetSize中的最大值。

當物理內存變得很低時，工作集管理器自動修剪工作集，以增加可用空閑內存數量。

有一系列內核控制變量描述工作集擴展和修剪，但這些值是確定的，不能被注冊值調整。

3． 平衡集管理器和交換程序

系統初始化時創建平衡集管理器，用來對工作集進行調整。工作集管理器也是運行在平衡集管理器線程環境下的一個例程。

平衡集管理器等待兩個事件對象

——1秒周期計時器到期后產生事件，并經歷以下4步

平衡集管理器每被喚醒4次就喚醒交換程序；檢查后備鏈表，必要時調整其深度；尋找處于CPU饑餓狀態而需提高其優先級的線程；調用工作集管理器。

——內部工作集管理器事件，即工作集需要調整時

交換程序：即KeSwapProcessOrStack例程，用來尋找一段時間內一直處于等待狀態的線程，將其內核堆棧轉移以收回物理內存。

4． 系統工作集

系統工作集用來管理操作系統中可分頁的代碼和數據，其中可駐留5種頁面：系統高速緩存頁面；分頁緩沖池；Ntoskrnl.exe中可分頁的代碼和數據；設備驅動程序中可分頁的代碼和數據；系統映射視圖。

系統工作集最大最小值是在系統初始化時計算的，基于物理內存數量和系統是professional或server。

物理內存管理

頁框號數據庫用來描述物理內存中各頁面的狀態，有效頁表項指向頁框號數據庫中的項，頁框號數據庫項又指回此頁表。原型頁框號指回原型頁表項。

頁面可處于活動、過渡、后備、修改、修改不寫入、空閑、零初始化和損壞不可用8種狀態，除活動和過渡之外，其余6種組成了鏈表。

1． 動態頁鏈表

當需要一個零初始化的頁面時，首先訪問零頁鏈表，若為空，則從空閑鏈表中選取一頁并零初始化，若也為空，則從后備鏈表中選取一頁并零初始化。

——零頁鏈表是由零頁線程（優先級為0）從空閑鏈表中移過來的，當空閑鏈表中有8個或8個以上頁時激活零頁線程。

當不需要零初始化頁面時，首先訪問空閑鏈表，若為空，則訪問后備鏈表。

當進程放棄一個頁面時，如果頁面未修改過，則加入后備鏈表；如果修改過，則加入修改鏈表。

進程撤銷時，將所有私有頁面加入空閑鏈表。對頁文件支持的區域最后一次訪問結束時，頁面加入空閑鏈表。

當修改頁鏈表太大，或零初始化和后備鏈表的大小低于最小值時，喚醒“修改頁面寫回器”線程，將頁面寫回外存，并將頁面移入后備鏈表。

2． 修改頁面寫回器

由兩個系統線程組成，優先級都為17

——MiModifiedPageWriter：將修改頁寫回頁文件

——MiMappedPageWriter：將修改頁寫入映射文件

觸發修改頁面寫回器的事件

——修改頁面數量大于內核變量MmModifiedPageMaximum指定值

——可利用頁數量小于內核變量MmMinimumFreePages指定值

——MiMappedPagesTooOldEvent事件：該事件在預定的數秒后（缺省為300秒，可用注冊值修改）產生，將映射頁面寫入外存

若頁面寫入外存時正在被另一線程共享，則I/O完成后不會將此頁移入后備鏈表。

3． 頁框號數據結構

頁框號數據庫項是定長的，不同頁框號類型，包含的域也不同（參見圖4－28）

幾個基本的域

——頁表項地址：指向此頁頁表項的虛擬地址

——訪問計數：對此頁的訪問數量

——類型：該頁框號表示的頁面狀態（8種）

——標識：包含修改狀態、原型頁表項、奇偶校驗錯誤、正在讀取或寫入等信息。

——初始頁表項的內容

——頁表項的頁框號：指向該頁面頁表項的頁表頁的物理頁號

其他內存相關機制

1． 鎖內存

可以通過兩種方式將頁面鎖在內存中

——設備驅動程序調用核心態函數MmProbeAndLockPages，MmLockPagableCodeSection,mLockPagableDataSection,LockPagableSectionByHandle。解鎖之前鎖定的頁面一直在內存中。

——Win32應用程序調用VirtualLock函數鎖住工作集中頁面，但不能防止調頁。

2． 分配粒度

系統按照分配粒度定義的整型邊界對齊每個保留的進程地址空間區域，系統分配粒度值可通過GetSystemInfo函數找到，目前為64KB。

保留地址空間時，保證區域大小是系統頁大小倍數。

3． 內存保護機制

4種基本方式

——所有系統范圍內核心態組件使用的數據結構和緩沖池只能在核心態下訪問，用戶線程不能訪問。

——每個進程有獨立私有的地址空間，其他進程的線程不能訪問。（與其他進程共享頁面或另一進程具有對進程對象的虛擬內存讀寫權限時除外）

——除虛擬到物理地址轉換的隱含保護外，還提供一些硬件內存保護措施。

——利用共享內存區域對象的存取控制表（ACL）將對共享內存的訪問限制在適當權限的進程中。

4． 寫時復制

當進程映射區域對象的寫時復制視圖時，內存管理器直到頁面修改時才進行復制，而不是在映射視圖的同時，這樣可以節約物理內存。

5． 地址窗口擴充

地址窗口擴充（AWE）函數集可使進程能夠訪問更多的物理內存，步驟如下：

——分配要使用的物理內存：AllocateUserPhysicalPages函數（需鎖內存頁面的權限）

——創建一個虛擬地址空間作為窗口用來映射分配好的物理內存：VirtualAlloc函數和MEM_PHYSICAL標識

——將內存映射到窗口：MapUserPhysicalPages或MapUserPhysicalPagesScatter函數

AWE函數分配和映射內存的限制

——頁面不能在進程間共享

——同一物理頁面不能映射到同一進程的多個虛擬地址上

——頁保護可讀/寫

6． 物理地址擴展

物理地址擴展（PAE）的內存映射模式允許訪問64GB物理內存。

物理地址擴展模式下，虛擬地址劃分為4個域：頁目錄指針索引（2bit）、頁目錄索引（9bit）、頁表索引（9bit）、頁內字節偏移（12bit）。

物理地址擴展模式之所以能對更大范圍的內存編址，是因為頁目錄項和頁表項都由32位擴展到了64位。

我們了解了原理后，通過修改windows的內存管理配置可以有效調節非分頁文件池的問題。修改方法由于不同的操作系統版本、應用系統、硬件配置（CPU、內存）等不一致、因此此問題不具備操作方法的可復制性，需單獨對待。了解原理最重要。建議參考微軟windows開發實驗室的核心團隊出版的書籍：《深入解析windows操作系統》。

截至到2008年9月22日，經過調試后的ISA01已經穩定運行了一個星期，沒有出過服務失敗問題，至此、ISA問題已經解決。

經驗與總結：

總結

由于ISA系統封裝了windows的TCP/IP協議棧、因此，ISA故障會由多個方面引起、網絡、操作系統、策略、配置、參數、ISA后臺數據庫。所以在進行ISA診斷的時候需要2個必備條件、而這2個必備條件不具備導致了先前許多公司與技術工程師束手無策。

n 經歷ISA服務失敗的前后、保留現場進行線索收集

n 具備對網絡、交換機、windows操作系統、IT基礎服務（DNS、AD、路由）、ISA策略、SQLServer數據庫、網絡安全與攻擊防御、編程水平（WindowsSDK、DDK、T-SQL、C++）的全面掌握。

u 熟悉網絡、交換機、路由器；這里對應到網絡性能診斷、需要熟悉網絡協議、網絡服務工具、設備調試。對網絡造成的ISA故障進行排除。

u 熟悉windows操作系統原理；重點掌握windows內存管理、對winsocket封裝熟悉、否則無法發現此ISA系統的罪魁非分頁文件池錯誤進行鑒別，更加無法修正了。

u 熟悉IT基礎服務（DNS、AD、router)；這里對應到對DNS服務、AD服務正常運行，排除由此帶來的ISA問題的嫌疑。

u ISA策略與配置；解決ISA問題、當然要熟悉ISA，ISA原理本身就是網絡安全范疇、ISA方面的技能就是安裝、配置、策略了，因此這是必備技能。

u SQLServer數據庫；由于ISA內置的SQLSERVER數據庫的精簡版MSDE，MSDE本身也有內存、系統緩存等問題需要進行檢查與排除、所以務必要可以掌握OSQL的命令行使用。

u 網絡安全與攻擊防御；診斷中發現有SYN攻擊、如何去減少、一定要對網絡安全基礎知識有了解、否則也就無法去了解怎么配置改善SYN攻擊。

u 編程水平：

l WindowsSDK：許多命令行工具都存在于WindowsResourceKitTools、WindowsSupportTools、SDK中、而且在上述SYN攻擊代碼中使用了VC++編程的代碼大量調用了SDK中提供的API

l WindowsDDK：查看非分頁文件池大小務必使用DebuggingToolsforWindows(x86)、WinDbg，DDK本身是windows的內核驅動編程工具，因此要熟悉DDK命令、C++語言

l T-SQL：MSDE作為ISA后臺數據庫使用、在我上次提交的21280錯誤的排錯方法中，使用SQL語言調整MSDE的性能中使用到。

l C++；SDK/DDK中使用的API都以C++方式提供、而且在我的參考文獻《深入解析windows操作系統》中描述的內存管理原理也是用C++語言來描述的，因為原理復雜、所以采用程序原語表述更加容易理解。

系統的診斷是多維度的，不能ISA出了狀況就只關注ISA，IT系統是一個有機的系統整體、需要多維度的檢查、這樣的思路與結論才是準確的。

需要依靠多種診斷工具和軟件、但是不能完全依賴軟件報出的結果。盡量采用微軟原廠的工具來診斷。

原理的分析是最關鍵的，了解了原理才知道使用什么工具、尋找什么文獻幫助、尋求哪方面的技術支持。

建議

v 建立完善的ISA監控預警機制、逐步把服務質量與ISA性能管理結合在一起。

v 使用迅雷、電驢等P2P用戶的情況嚴重、這些軟件無法使用策略等手段來禁止、所以需要進行技術手段與管理手段結合的方式來進行：技術手段建議可以在ISA前端部署一套網絡流量/上網行為管理系統、配合終端的桌面管理系統，有效進行IT基礎環境的專責管理。管理手段建議可以和流程、人員、稽考結合在ITIL整體來體現、這樣一切結果都是流程化、統一化、避免了主觀評判與管理因素。

v 購買正版ISA、獲取微軟原廠服務支持。雖然技術支持可以尋求武漢本地公司和個人來解決、但是知識庫沒有在客戶方得到沉淀和積累、這樣對于每個類似此次問題無法從項目中得到知識庫建設的增長、自身IT人員技術水平也難以得到提升、更談不上有效的績效水平管理。

v ITIL管理不是口頭的，需要有每個子系統都與之接洽的大局觀與思路、從流程、人員、知識庫、服務監督、服務響應、考核等方面來建設。我可以安排客戶參觀ITIL與運維做的比較好的成功案例客戶供借鑒參考，如神龍、武鋼、華中電網、東風有限等。