[電子報封存 ^][< 第 1 卷，第 1 期][第 1 卷，第 3 期 >]
Systems Internals 電子報第 1 卷第 2 期
1999 年 5 月 15 日 - 本期內容：
Systems Internals 的最新動向
- SDelete
- BlueScreen 螢幕保護裝置 Win2K 更新
- 「Linux 和企業版」
- 「在 NT 公用程式內」
- 我的五月 Windows NT 雜誌欄
- 部分既有資料
內部新聞
- Dr.GUI 的床邊禮儀很差
- WinDev '99 East
- Numega 驅動程式工作即將發行
- Beta 3 DDK 已發行
- Win2K 已排入佇列的微調鎖定
未來動態
- Win2K 系統檔案保護裝置 (SFP)
贊助者：WINTERNALS SOFTWARE
Sysinternals 電子報由 Winternals Software 贊助，該公司的網址為 http://www.winternals.com. Winternals Software 是領先業界的開發商，提供諸多適用於 Windows NT/2K 的先進系統工具。 Winternals Software 產品包括適用於 Windows NT 4.0 的 FAT32、ERD Commander (適用於 Windows NT 的開機磁碟功能)，以及 NTRecover。
大家好，
歡迎瀏覽 Sysinternals 電子報第二版。 電子報目前有 2700 位訂閱者，訂閱仍然強勁。
自上次電子報 Microsoft 正式發行 Windows 2000 Beta 3 以來。 Beta 3 核心的組建編號是 2031，而 NT 4.0 的初始版本核心為 1381，而 NT 3.51 的組建編號為 1025。 . 我發現奇怪的 (有點煩人)，是 Microsoft 會在每次執行作業系統的完整組建時遞增組建編號 (每個工作天)，不過，回報的核心組建編號會反映其初始公開版本。 例如，即使 NT 4.0 Service Pack 5 核心的實際組建編號遠高於 1381，核心仍會將 1381 報告為組建編號。
Windows 2000 的 Beta 3 版本是開發人員社群的喚醒呼叫。 Microsoft 已宣佈將在 10 月寄送 Windows 2000，而 Beta 3 代表即將寄送的功能完整版本，因此開發人員可以開始撰寫新產品，而不必擔心產品底層會發生變化。
Windows 2000 隨附大量新的 API、分層服務和核心增強功能。 對裝置驅動程式開發人員來說尤其明顯的一項變化是藍色當機畫面 (BSOD) 已變更。 在舊版 NT 中，BSOD 會顯示系統上所有驅動程式的連結時間和載入位址資訊，以及當機時存在的堆疊傾印。 在 Windows 2000 中，只會顯示停止代碼和相關聯的位址行 (位址行會將一或多個停用代碼參數轉譯成裝置驅動程式內的位置)，以及詳細資訊訊息。 支援訊息會建議您檢查 BIOS 和硬碟設定，並停用重組軟體和病毒掃描器，以避免再次發生當機。 Microsoft 頂級支援服務 (PSS) 會根據他們的經驗和客戶意見反應來判斷 NT 4 樣式 BSOD 對於判斷當機原因並無用處。
我個人發現載入的驅動程式清單，特別是堆疊傾印，在從使用者取得驅動程式錯誤報告時，取得此資訊比讓使用者傳送多個百萬位元組損毀傾印要容易且更快。 我經常根據堆疊傾印隔離損毀的原因，以及根據驅動程式清單中顯示的版本資訊來驗證使用者已載入的驅動程式版本。 我很想知道您的想法：您想要看到 NT 4 樣式的 BSOD 轉送至 Windows 2000，還是新的 BSOD 格式足夠嗎？ 如果您有意見，請傳送電子郵件給我。 我會在下一份電子報中報告這次非正式投票的結果。 雖然我是 BSOD 的主題，但請務必查看此問題所涵蓋之有史以來熱門系統的 Windows 2000 更新 BlueScreen 螢幕保護裝置。
感謝您！
-Mark
Systems Internals 的最新動向
SDELETE
在符合 C2 安全性評等需求的 Windows NT 4.0 中，它會實作「物件重複使用保護」。 這表示當應用程式第一次存取資源時，NT 會為檔案和記憶體資源應用程式佈建零。 例如，這可防止應用程式建立大型檔案，並檢查其內容，以查看先前儲存在磁碟上的內容。 不過，物件重複使用保護對略過標準資源相關 API 或完全略過作業系統的應用程式可存取的資源並不大。 例如，您可以使用磁碟編輯器，例如 Resource Kit 的 DiskProbe，來檢查磁碟中未配置部分的內容。 這可讓您查看先前屬於已刪除檔案的資料。
許多環境都需要「安全刪除」功能。 這項功能可讓使用者永久刪除敏感性資料，讓略過作業系統保護設施的工具看不到此功能。 加密檔案系統 (EFS) 的出現突顯出 Windows 2000 中安全刪除設施的需求。 當您加密先前未加密的檔案時，EFS 不會在釋放磁碟配置時清除包含檔案未加密資料的磁碟配置內容。 因此，即使您加密的檔案使用中版本是安全的，舊版檔案仍存在於磁碟的未配置部分，直到 NTFS 指派給這些部分的新檔案資料覆寫為止。
為了填補這個洞，我寫了 SDelete (安全刪除)。 這是命令列工具，不僅可讓您安全地刪除標準檔案，還能安全地刪除磁碟未配置部分中任何先前刪除的資料。 此外，它可與 Windows NT/2000 壓縮、加密和疏鬆檔案搭配使用，這需要使用重組 API。 SDelete 遵守國防部清除和清理標準 DOD 5220.22-M，因此您可以確定一旦刪除資料，資料就會永遠消失。
我提供 SDelete 的完整原始程式碼和其運作方式的描述，讓您能夠查看它如何使用重組 API，以便您可以驗證我的宣告，使其無法復原機密已刪除的資料。
您可以在 http://www.sysinternals.com/defrag.htm. 找到 Windows NT/2000 重組 API 上的文件 若要下載包含完整原始程式碼的 SDelete，請前往 http://www.sysinternals.com/sdelete.htm.
BlueScreen 螢幕保護裝置 Win2K 更新
Microsoft 在 Windows 2000 中對 NT 啟動畫面和藍色當機畫面 (BSOD) 版面配置所做的變更，使得系統內部 BlueScreen 螢幕保護裝置程式需要進行重大更新。 為了在 BSOD 現實主義中繼續為您提供最大的功能，我發行了 2.0 版的螢幕保護裝置。 它不僅會反映 BSOD 格式的變更，還精確地模擬 Windows 2000 啟動畫面，並完成旋轉進度等量和進度列更新。 如此真實，即使是 Windows 2000 專家使用者和開發人員，螢幕保護裝置也會愚弄。 當然，在 NT 4.0 BlueScreen 螢幕保護裝置下，仍然會顯示 NT 4.0 BSOD 和啟動畫面。
如何完美且同時不違反著作權法，重新建立 Windows 2000 啟動畫面？ 我不包含 Windows 2000 啟動點陣圖圖形與螢幕保護裝置。 相反地，我使用 DirectX 將圖形模式切換至啟動順序期間 Windows 2000 所使用的相同，然後參考 Windows 2000 核心檔案 ntoskrnl.exe 的點陣圖資源。 這些資源 (您可以藉由在 Visual Studio 中開啟 ntoskrnl.exe 的資源來檢視這些資源) 是核心所顯示的資源，這是從 Windows 9x 執行啟動圖形實際分隔檔案的方式所做的變更。 電腦 OEM 看起來不像有機會自訂 Windows 2000 中的啟動體驗...
您可以在 http://www.sysinternals.com/bluescreen.htm. 下載 BlueScreen 螢幕保護裝置 如果您有關於用螢幕保護裝置愚弄別人的幽默故事，請轉發。
您可以在 1997 年 12 月的 Windows NT Magazine NT Internals 專欄「在藍色螢幕內」中，深入了解 BSOD 的作法和原因，。 [系統內部發行集] 頁面上 http://www.sysinternals.com/publ.htm 的連結會帶您前往該專欄的線上版本。 此頁面也包含我撰寫之文章和專欄之其他線上簡報的連結。
「LINUX 和企業版」
Linux 社群在 4 月發行的 Windows NT Magazine 文章中對 Linux 核心的延展性缺陷做出的巨大回應，促使該雜誌提前發佈該文章的線上版本。 您可以在 http://www.sysinternals.com/publ.htm. 的「文章」一節中找到文章「Linux 與企業版」的連結 本文說明 Linux 核心 (2.2x) 目前版本的幾項限制，包括缺乏有效率的事件等候機制、重要的系統呼叫序列化、沒有非同步 I/O，以及 Sendfile 的不佳實作 (在 NT 中稱為 TransmitFile) 通訊端 API。 這些限制的組合可防止 Linux 在 Web 伺服器、資料庫伺服器和電子郵件伺服器等企業級應用程式中，與 NT 和其他 UNIX 展開正面競爭。
「在 NT 公用程式內」
如果您已使用 Filemon、Regmon 或 HandleEx，並想要深入了解他們告訴您的內容及其實作方式，則您會對我的 2 月 Windows NT Magazine 專欄「在 NT 公用程式內」感興趣。此專欄描述這些工具的內部功能，以及 Regmon 和 Filemon，會告訴您擷取登錄或檔案系統活動時所記錄的錯誤碼和要求類型。 本文線上版本的連結剛剛可供使用，位於 http://www.sysinternals.com/publ.htm.
我的五月 Windows NT 雜誌專欄
您是否曾經想知道 Windows NT/2000 如何組織登錄記憶體內部或磁碟上的內容？ 目前 (5 月) 的 Windows NT Magazine 問題包括我的專欄「登錄內部」，其中告訴您這一點等等。 例如，了解 Configuration Manager 核心模式子系統 (負責管理登錄的子系統) 如何查閱機碼、儲存值資料、優化搜尋，以及保護登錄磁碟上檔案的完整性。 Windows NT Magazine http://www.winntmag.com 可在 Borders 和 Barnes and Nobles 上找到。
部分既有功能
在 Windows 2000 Beta 2 發行後不久，我已取得核心映射檔的 Checked (debug) 組建 (ntoskrnl.exe)，在核心上執行字串搜尋，並想出用來建置核心的來源檔案名稱清單。 NT/2000 核心的 Checked 組建包含許多 Assert 陳述式 (一致性檢查)，其中包含 Assert 所在檔案的檔案名稱。 假設核心來源中幾乎每個具有任何重要性的檔案都會有至少一個 Assert，則清單相當完整。 將清單傾印到 JAVA 指令碼中，給了我 Windows 2000 來源樹狀目錄結構良好的檔案總管式樹狀檢視。 請參閱 http://www.sysinternals.com/nt5src.htm.
內部新聞
DR. GUI 的床邊禮儀很差
在 Microsoft Developer Network News Dr 的 3 月/4 月發行中GUI 回答了讀者提出的問題，詢問驅動程式如何關聯 (強制使用特定 CPU) 其執行緒。 Dr.GUI 會回應無法從驅動程式判斷系統上的處理器數目，而且驅動程式執行緒無法判斷其執行位置的處理器數目。 不幸的是，Dr.GUI 搞砸了這個診斷 (也許 Dr.GUI 應該堅持使用 GUI)。
NT 核心 (ntoskrnl.exe) 將 NTDDK.H 中定義的名為 KeNumberProcessors 的變數匯出為：
extern PCCHAR KeNumberProcessors;
它可以直接在驅動程式中參考，如下所示：
CHAR i;
for( i = 0; i < *KeNumberProcessors; i++ ) {
// do processor specific stuff
}
要確定驅動程式執行緒正在哪個處理器上執行，請使用 KeGetCurrentProcessorNumber()，這是另一個核心匯出，它不僅在 NTDDK.H 中定義，而且實際上記錄在 DDK 中！
Dr.GUI 為此症狀開了錯誤的處方，所以我禮貌性地透過電子郵件讓 Dr. 知道。 令人驚訝的是，Dr.GUI 甚至從未認可過該電子郵件。 我們將看看這位好 Dr. 是否會在下一期承認錯誤...
WINDEV '99 EAST
1999 East Coast 版本的 Windows 開發人員頂級會議即將來臨。 WinDev '99 East 將於 6 月 14 日至 18 日在波士頓劍橋萬豪酒店舉行。 Windows 開發領域的一些風雲人物都會蒞臨致詞，包括 Jeff Richter、Jeff Prosise 和 Don Box 等。 我會和 Jamie Hanrahan 以及 Brian Catlin 一起參加裝置驅動程式討論。我的簡報會包含一整天的 NT internals 教學，還有在 Windows NT/2K 檔案系統驅動程式編寫，以及先進裝置驅動程式開發問題等議題。 歡迎共襄盛舉，並過來打個招呼吧！
NUMEGA 驅動程式工作即將發行
Compuware NuMega Labs 即將發行功能強大的新 Windows 9x/NT/2K 裝置驅動程式開發工具組 DriverStudio。 DriverStudio 結合了所有 NuMega 的現有裝置驅動程式工具，包括 DriverAgent、DriverWorks、SoftICE 和 VtoolsD，並新增驅動程式和 FieldAgent 的新 BoundsChecker (僅限 Windows NT/2K)。
BoundsChecker 的裝置驅動程式版本提供驅動程式所使用的每個核心 API 的完整監視，而且您可以使用它來監視驅動程式與系統上任何其他裝置驅動程式的互動。 FieldAgent 可讓您將 BoundsChecker 的驅動程式版本部署到用戶端系統，讓用戶端可以收集您可以分析的追蹤。 DriverStudio 客戶的免費更新即將推出，適用於驅動程式的 TrueTime，以及適用於驅動程式的 TrueCoverage，可讓您輕鬆調整效能並涵蓋範圍來測試您的裝置驅動程式。
此套件是最終的驅動程式開發工具組，我非常推薦它 (我在 Beta 計劃中)。 在 http://www.numega.com. 深入了解
BETA 3 DDK 發行
隨著 Windows 2000 Beta 3 的發行，Microsoft 也提供了免費下載 Windows 2000 Beta 3 DDK (裝置驅動程式套件)。 您可以在 http://www.microsoft.com/ddk/ddk2kb3.htm. 取得 DDK 我希望 SDK 能夠盡快推出，因為 Beta 3 中的許多 Win32 API 截至 4 月版 MSDN 尚未記載。
Win2K 已排入佇列的微調鎖定
Windows 2000 會針對其全域鎖定使用稱為「佇列微調鎖定」的新類型微調鎖定。 Windows 2000 中的全域鎖定與 Windows NT 4.0 中的鎖定相同，包括：
KiDispatcherLock：排程器資料庫鎖定KiContext-SwapLock：執行緒交換鎖定MmPfnLock：實體頁面框架資料庫鎖定MmSystemSpaceLock：核心模式位址空間鎖定CcMasterSpinLock：快取管理員的全域同步鎖定CcVacbSpinLock：快取管理員的對應陣列鎖定
在單處理器佇列的微調鎖定上，運作方式與一般微調鎖定完全相同。 不過，在 NT 的多處理器組建上，佇列的微調鎖定明顯不同。 如同標準微調鎖定，佇列的微調鎖定會在 HAL 中實作。 核心會呼叫 HAL 函式 KeAcquireQueuedSpinlock 來取得已排入佇列的微調鎖定，並叫 KeReleaseQueuedSpinlock 用 以釋放已排入佇列的微調鎖定。 KeAcquireSpinlock 和 KeReleaseSpinlock ，核心用來取得和釋放標準微調鎖定的 HAL 函式，需要指定之微調鎖定的位址做為參數。 相反地，佇列的微調鎖定函式會採用全域微調鎖定的索引編號。 核心會初始化陣列中的全域微調鎖定，其中每個微調鎖定都有核心用來識別它們給 HAL 的預先定義索引編號。 因此，裝置驅動程式無法定義及使用佇列的微調鎖定，因為無法擴增全域佇列的微調鎖定陣列。
在 Windows 2000 中，SMP 中的每個處理器控制區域 (每個處理器都有一個 PCR) 有一個陣列，其中有許多項目，因為有佇列的微調鎖定。 每個陣列項目都包含兩個欄位：它對應之佇列微調鎖定的指標 ("spinlock" 欄位)，以及 "queue" 欄位。 在下列描述中，當我提到微調鎖定和佇列欄位時，我指的是與正在取得或釋出的微調鎖定陣列項目關聯的欄位。
KeAcquireQueuedSpinlock 運作方式如下：函式會嘗試使用連鎖交換 CPU 指令來取得微調鎖定，以將目前處理器的 DPI 位址放在微調鎖定中。 如果保留微調鎖定，函式就會在交換作業中擁有另一個處理器的 PCR 位址。 然後，函式會切換自有的 PCR 中微調鎖定欄位的低位元，將其識別為「等候中」。 接下來，它會將自己的 PCR 位址放在從微調鎖定擷取之 PCR 的佇列欄位中。 最後，它會在忙碌迴圈中等待，直到其微調鎖定欄位中的低位元被關閉，當該位元關閉時，目前處理器已被授予微調鎖定，因此它返回到獲取函式的呼叫者。
處理器取得已排入佇列的微調鎖定並完成它想要在保留鎖定時執行的處理之後，它會呼叫 KeReleaseQueuedSpinlock。 KeReleaseQueuedSpinlock 查看目前處理器的 PCR 中指定微調鎖定的佇列欄位。 如果佇列欄位為非零，則另一個處理器已在那裡「排入佇列」其PCR。 KeReleaseQueuedSpinlock 清除等候的 PCR 之微調鎖定欄位的低位元，然後清除自己的佇列欄位並傳回。 藉由清除等候的 PCR 微調鎖定欄位中的低位元，它剛剛發出下一個 CPU 的訊號，表示它可以擁有鎖定。 如果佇列欄位為零，則沒有其他處理器正在等候鎖定，而且 KeReleaseQueuedSpinlock 只會執行連鎖的交換作業來清除全域微調鎖定。
已排入佇列的微調鎖定作業是處理器「排隊」等候保留的微調鎖定的作業之一。 每個處理器透過告訴排在其前面的處理器它正在等待來自行排隊。 這會提供確定性順序，以取得佇列的微調鎖定處理器，依要求其順序取得微調鎖定。 針對標準執行緒微調鎖定，沒有這類排序。 佇列的微調鎖定有另一個更重要的優勢。 當處理器旋轉等候其微調鎖定欄位清除低位元時，它會在記憶體私下旋轉到自己的處理器。 當處理器忙碌中等候標準微調鎖定時，它會在所有處理器共用的全域微調鎖定本身上旋轉。 因此，佇列的微調鎖定具有較佳的多處理器匯流排特性，因為忙碌等候期間沒有共用快取線路存取。 此外，由於佇列微調鎖定的佇列本質，當鎖定受到數個處理器爭用時，通常比標準微調鎖定作業少。
佇列的微調鎖定是 Microsoft 為 Windows 2000 提供的多處理可擴充性的多項增強功能之一。
未來動態
Windows 2000 包含許多功能，可讓運算子錯誤和錯誤的應用程式更具彈性。 其中一個是，%systemroot%\system32 和 %systemroot%\system32\drivers 目錄下的許多 DLL 和驅動程式都受到稱為系統檔案保護裝置 (SFP) 的監視程式所保護。 您可以移至該 system32 目錄並重新命名 ntoskrnl.exe 來確認其是否存在。 監視程式會喚醒並通知您它偵測到竄改受保護的系統檔案，並正在修復它。 如果您再次檢查目錄，就會發現 ntoskrnl.exe 已神奇地取代目錄。 下次我會告訴您這如何運作。
感謝您閱讀 Systems Internals 電子報。
發佈時間：1999 年 5 月 15 日星期六下午 7:15，發佈者：ottoh