好了，在Windows 2000資源工具包中有一個稱作PS的Visual Basic指令碼，它是90個使用Windows 2000中某些新型基礎結構（WMI，亦即Windows系統管理工具）的VB示範樣本中的一員。
WMI允許對許多在Windows 2000之前不能被訪問的資訊進行訪問，而更重要的或許是，WMI允許在網路範圍內訪問那些以前只能在本機進行訪問的資訊。
因此，通過PS VBS指令碼，你將能夠在遠端系統上輕易地對行程列表進行觀察。這裡還有一個能夠在遠端系統上殺死行程的VB指令碼。
如果你還沒有看過Windows 2000工具包中這90個零散的VB指令碼示例的話，我極力推薦你去看一下。
但我們的首要問題是，無論在工作站還是在伺服器上，如果行程看上去很慢，到底是什麼正在執行著呢？
對我來說，找出究竟是什麼正在執行著的最快方法，就是彈出工作管理器，翻到行程選擇項，並按CPU耗用時間片段進行排序。
在我們這麼做之前，先讓我們將工作管理器作為我們的第一個行程瀏覽工具加以介紹，儘管工作管理器或許被看作是一個使用起來相當簡單而清楚的工具，但選擇項的名稱及所列示的資訊仍可能不十分明確。因此，讓我們彈出在幻燈片中提及的工作管理器。
有3種方法來啟動工作管理器。我將使用其中最快的一種，即組合鍵Ctrl+Shift+Esc。我按下Ctrl+Shift+Esc，我們看到的預設選擇項是應用程式選擇項。
現在，如果我問你，這一列表是關於什麼的，你會如何回答呢？
不，這不是一個應用程式列表；不，這也不是一個行程列表。事實上，它是關於帶有一套非常特殊的格式位的頂級可視視窗的列表，換言之，這是一個視窗列表，但表中的視窗並非系統中所有的視窗，也不是桌面上所有的可視的視窗，但總的來說，它是一個頂級且可視的視窗列表，你能通過在工作列上直接點擊或按Alt+Tab組合鍵來看到。
現在，視窗由線程擁有，而線程由行程擁有，這就是為什麼存在將視窗映射到行程上這一選項的原因所在。
如果我點擊滑鼠右鍵，轉入行程，它將把我帶到以高亮度顯示的行程選擇項，現在，我點擊滑鼠將其置為反色（藍色），就顯示出擁有視窗的線程和擁有線程的行程。這裡，我們看到了在視窗和行程之間的映射。現在，再次回到應用程式選擇項。
既然我們現在已知這是一個視窗列表，那麼這個狀態列又意味著什麼呢？好的，視窗並沒有執行。執行意味著擁有視窗的線程沒有執行，而無回應則意味著擁有視窗的線程正在執行，它在後台執行。
換言之，一個執行著的視窗就是一個正在接受滑鼠輸入，也就是圖形用戶界面輸入的視窗。
擁有視窗的線程當前處於等待狀態，而你可以在該視窗上進行點擊。
因此，視窗的常態是執行狀態。再重複一次，執行意味著擁有視窗的線程正等待你在該視窗上進行點擊。視窗並沒有執行。
無回應是當視窗看上去被掛起時你所看到的狀態指示，或者說，該狀態在視覺上暗示你，當你在視窗上方移動滑鼠時，該視窗將不會標記出回應。你看到了什麼？
一個沙漏。
沙漏簡單地意味著擁有視窗的線程當前不接受圖形用戶界面輸入。它並不一定意味著應用程式被掛起。該線程可能正忙於其它工作，或許只是在等待磁牒或網路上的IO，並且不久會轉回到接受視窗輸入的狀態下。
因此，當線程轉回到等待圖形用戶界面輸入的常態時，無回應有時僅僅是對線程自身的清除。當然，如果應用程式真的被掛起，並且線程將不會返回到視窗輸入狀態，那麼，該視窗將顯示為不再做出回應，你可以點擊結束工作，該功能將向擁有視窗的線程發出一條資訊以釋放視窗。
在應用程式選擇項上的結束工作選項不會關閉行程，且不一定關閉視窗。它發出一條友好的Mr. Thread資訊，詢問你是否要釋放或關閉該視窗。這就是它所發出的資訊。
讓我們通過執行一個記事本拷貝來執行一次結束工作的快速演示，輸入一些未經儲存的文字並嘗試關閉視窗。
我將在工作管理器中選項記事本視窗，按下結束工作並注意在左邊發生了什麼。
記事本收到了關閉視窗的請求並予以拒絕，我將不再重複上述操作，因為你尚未儲存你所做的修改。與此同時，工作管理器對那個你要求它去關閉並釋放的視窗已等得不耐煩了。
換言之，那個你要求釋放並關閉的視窗仍舊在那裡。於是，工作管理器說道，嗨，我們不能結束這個程序。
因為工作管理器正在等候來自於你的回應以返回視窗並檢查程序點擊取消的狀態，所以它事實上已關閉這個視窗。如果你選項馬上結束該程序，你將會失去一切未經儲存的資料。
按下現在結束按鈕在某種意義上是一個危險的操作，因為這樣一來就殺死了擁有線程的行程，而該線程已經在進行到半截的行程中處於啟動狀態。
它一直在更新磁牒上的文件，進行網路IO，誰知道呢？故而，當你選項現在結束時，務必要小心從事，因為，擁有視窗的線程其所在的行程會從系統中釋放，而沒有任何挽留的餘地。
現在，讓我們看一下行程選擇項。
這裡的行程是指一系列行程，這些行程如我們前面所講，是由它們所執行的可執行程序實例來識別的，這就是行程選擇項中的第一列給出了映射名稱的原因。請注意，這裡並沒有行程名稱列。行程並不擁有獨立於其所歸屬實例的映射名稱。換言之，如果你執行5個記事本拷貝，你將會看到5個稱為Notepad.exe的行程。
它們是如何彼此區別的呢？其中一種方式是通過它們的行程ID，因為每個行程都擁有其獨一無二的編碼。該行程ID由Windows NT或Windows 2000產生，並可以循環使用。因此，行程ID將不會越編越大，它們能夠得到循環利用。
第三列是被行程中的線程所佔用的CPU時間百分比。它不是CPU的編號，而是被行程佔用的CPU時間百分比。在當前的展示中，我的系統基本上是空閒的。
儘管系統看上去每一秒左右都只使用一小部分CPU時間，但該系統空閒行程仍舊耗用了大約99%的CPU時間。我們過一會兒將看到有關現象。
第四列，CPU時間，是CPU被行程中的線程累計佔用的小時、分鐘及秒數。請注意，我對行程中的線程使用佔用一詞。這並不一定意味著那就是行程已耗用的CPU時間總和，因為，如我們一會兒將看到的，NT計時的方式是，當特定的時鐘間隔激發時，無論誰恰巧處於當前的線程中，它都將計算到CPU週期之內。
通常情況下，在大多數NT系統中，時鐘以10毫秒的間隔執行。每10毫秒NT的心臟就跳動一下。有一些驅動程式程式碼片段執行並顯示誰是當前的線程。
讓我們將CPU時間的最後10毫秒記在它的帳上。因此，如果一個線程開始執行，並在持續執行8毫秒後完成，接著，第二個線程開始執行並持續了2毫秒，這時，時鐘激發，請猜一猜這整整10毫秒的時鐘週期到底記在了哪個線程的帳上？
答案是第二個線程。因此，NT中存在一些固有的不準確性，而NT恰是以這種方式進行計時，實際情況也如是，大多數32位操作系統中都存在一個關於間隔的計時機制。
請記住這一點，因為，有時當你觀察線程所耗用的CPU總和時，會出現儘管該線程或許看上去已執行過數十萬次，但其CPU時間佔用量卻可能是零或非常短暫的現象，那麼，上述解釋便是原因所在。上述是我們在工作管理器的行程選擇項中所能看到的基本資訊列。
現在，如果你在檢視表單中選項列，該功能將允許你增加一些諸如IO計數器、IO讀寫等關於行程細節的額外列。
這是Windows 2000的新特性，並能夠允許以逐個行程的方式檢視IO活動。在NT 4.0中，IO計數器是覆蓋全系統和所有磁牒的。
以逐個行程的方式跟蹤IO操作是不可能的。就理解行程活動而言，這一附加功能是非常重要的，因為，現在我們能夠看到系統上發生的IO是哪個行程所導致的。我已經增加了線程計數器，它表示行程中所包含的線程數量；我還增加了句柄計數器，它代表開啟對象的數量
。在本次講座的後續部分，我們還將回頭看一看開啟句柄的有關內容。
最後，讓我們轉到效能選擇項。效能選擇項顯示了200到300個能夠通過效能監視器來顯示的NT內核效能計數器中的13個計數器的值。
我們再次看到了通常使用效能監視器工具來觀察的核心繫統效能計數器的一個小子集，而這上面的某些標籤或許還不夠清楚。例如，記憶體使用欄與物理用途並沒有什麼關係。
這是系統中全部專用且指定的虛擬記憶體。我們將不會深入到這些細節中去，只是應搞清該顯示區域中的一些項目可能使你在對系統容量限制做出決策之前能夠進行深入推敲。
這就是在外殼上的工作管理器。它是一個快捷工具。使用這個工具，你可以在一個緩慢的系統上發現那些令人討厭的行程究竟是誰。這裡再次彈出工作管理器，按下Ctrl+Shift+Esc組合鍵，進入行程選擇項，按下CPU耗用情況，按CPU利用率對工作管理器的輸出進行排序。
請記住，每次使用工作管理器時，它均按行程ID進行排序，儘管行程ID並不是一個非常有用的排序順序。因此，工作管理器並不能在你每次使用後儲存有關設定。
如果你希望按CPU耗用百分比進行排序，則必須按下CPU列。這是一種能夠迅速找出哪個或哪些行程正在耗用系統中CPU時間的建立捷逕。
現在，讓我們轉入行程檢視器實用程序，也就是PViewer.exe。
這是我們將要執行的Windows 2000支持工具中的一個，它顯示了關於我們在後面將要進行的對系統行程加以研究的試驗中所需的行程和線程的更多細節。現在，我們將通過依次按下開始選單/程序/ Windows 2000支持工具/工具/行程瀏覽器來啟動行程檢視工具。初始顯示區域是一個系統上的行程列表。請注意，有一種方法能夠對遠端工作站或伺服器名稱進行選項。
與使用工作管理器檢視行程不同，只要你擁有對遠端工作站或伺服器上註冊表的訪問許可，你就能夠檢視遠端行程列表。這是因為，多數工具所顯示的基本行程和線程資訊實際上是通過執行註冊表查詢得以從系統恢復到NT效能記數器上的。
現在，據我們所知，行程檢視工具必須使用效能記數器機制的原因之一是，根據總分數檢視列表中的第一個行程。
那並不是一個真正的行程，也沒有在工作管理器列表中予以披露，但如果你曾經使用過效能監視器的話，你會看到多數包含多重實例（例如行程對像）的效能計數器均擁有一個叫做劃線總額的特殊內建實例名稱，這裡的劃線總額就是一個被選項與效能監視器配合使用從而在所有對象實例範圍內快速匯總計數器數值的實例。
若你想對多種對象的一個或多個計數器進行快速匯總，行程檢視則可謂是效能計數器機制中一個非常便利的特性。
Pviewer的智能程度尚不足以顯示這一點。它以行程的方式來顯示。但它並不是一個行程。列表中第一個真正的行程是CMD。
現在，請注意這些按可執行程式文件名的字母順序來對行程進行排序的地方。CMD是按字母順序排列的第一個可執行程序的檔案名。
別忘了，工作管理器是按行程ID進行排序的。工作管理器以十進制數來顯示行程ID，而Pviewer則在映射名稱後以十六進制數顯示行程ID。
在優先時間與用戶時間之間存在著明顯的區分，這就提供了有關與在操作系統內部相比，每個行程在應用程式中耗費多少時間的指示。
在講座的以後部分，我們還將回頭來看優先權與用戶時間的對比，但應記住，Pviewer是使你能夠更密切關注行程所佔用的CPU時間從而掌握在應用程式與操作系統之間的時間耗用區別的工具之一。
現在，當我按下從行程到行程，並將行程列表向下滾動時，在底部的顯示區域中什麼發生了變化？那就是線程列表。因為，如果你還對我們前面所作的描述有印象的話，該知道每個行程都包括一套線程。
這些線程對每個行程來說都是專用的。顯然，每個行程中的線程列表均應與下一個行程中的線程列表有所區別。
如果我選定一個線程並點擊它，進而將線程列表向下滾動，請注意在顯示區域的最底端發生了什麼改變。
Pviewer顯示區域的最底端給出了包括優先級數值（從1到30之間）在內的每個線程的資訊。
上下文切換的次數也就是NT選項執行該線程的次數。現在，這兒有個線程看上去有點特別。它已被選執行了58次，但其僅佔用了1%秒的CPU時間。
你還記得這種背離現象的原因嗎？在以10毫秒為一週期的時鐘間隔被激發時，該線程肯定未處於當前狀態。
還有一個例子，在服務主機中的行程5看上去根本沒有執行過，但請大家看一看其上下文切換次數——76次。該線程被選項執行了76次。
它實際上執行了76次。但它在以10毫秒為一週期的時鐘間隔被激發時從未處於當前狀態。因此，如果我們向上回到行程列表處，可看到該行程總共耗用的CPU時間僅為0.871秒，這一數值顯然沒有反映出該行程中所有線程在執行時所耗用的CPU時間總和。
現在，請記住，我們將不會丟失CPU週期。NT也不會丟失CPU週期的軌跡。
它只是以10毫秒的增量來計量各線程的CPU佔用時間，因此，線程有時是被誤計時的，但隨著時間的推移，這種誤差會被抵銷，而不會成為真正的問題。
再就是行程檢視工具。關於該工具的另一個說明是，如果你偶爾通過選定一個不同的電腦名稱並按下連接鈕來它檢視遠端系統的話，一個按鈕就會消失。你會因此失去一部分功能，消失的按鈕就是殺死行程按鈕。
殺死行程功能消失的原因是……你們還記得Pviewer是如何在行程列表中得以檢索的嗎？是通過註冊表。當我通過註冊表檢視遠端行程列表時，我能夠從遠端查詢該註冊表，並讀取行程列表，但註冊表並非一種控制機制。
我並不能通過註冊表殺死一個行程。因此，如果你想殺死另一台電腦上的行程，有兩個工具可以辦得到。一個是Windows 2000資源工具包中的殺死行程指令碼——kill.bbs。
它使用Windows 2000中新的WMI（亦即Windows管理規範）來訪問那些遠端行程控制操作，以前通過網路不能這樣使用。
另一個工具是資源工具包中稱作遠端殺死（remote kill）的客戶伺服器應用程式，該工具需要在你想要控制行程的遠端伺服器系統上安裝伺服器端程序。
無論是通過kill.bbs還是遠端殺死客戶伺服器應用程式，你都可以殺死一個行程。這兩個工具均存在於Windows 2000資源工具包中。
現在，我們已使用兩個工具檢視了行程列表，而該列表則表現為平面結構。列表中沒有顯示父子關係，但事實上，當我們轉入下一張幻燈片後，我們會看到NT保留了關於哪個行程新增了哪個行程的有關資訊。
換言之，誰是父親？誰是兒子？該層次結構通過Windows 2000支持工具包中一個稱作Tlist的工具顯示出來。
現在，Tlist代表工作列表，但它也真的顯示出行程列表。事實上，工作這個術語並不一定就意味著存在於NT內核中的一切。
我將彈出指令行方式，並在該方式中鍵入TList/t。
Tlist所做的就是產生一個關於每個行程來自何處的父子關係展示，它通過使用簡單的縮排格式來顯示誰是父親、誰是兒子。然而，Tlist充其量也只能與NT所記錄的資訊具有同等智能。
我們回到幻燈片上，會注意到如果父行程已死，Tlist則將該行程向左對齊。這是因為NT只記錄了父行程的ID。
如果你的父親已不在世，就無法追溯出你的祖父是誰。
當Tlist發現一個子行程的父行程已不再執行時，就會將該行程向左對齊，並以此指明該行程是個孤兒。現在，當看到一個沒有父行程的子行程時，就沒有什麼可值得稀奇的了。當你註銷時，你的交互會話中的所有行程都會刪除。
NT並不會因父行程消失而同時失去子行程。
回來看Tlist/t的輸出，我們會看到，在我的系統上，explore.exe剛才就是一個孤兒，它沒有父行程，其原因就在於當你登入網路時，登入行程就會執行一個進而使用Explore的程序，而這個中介程序會在它完成使命時退出。
Explore的全部子行程代表了今天我開始講座以來執行的所有程式。例如，我從Internet Explorer實例開始。我執行了指令行方式。
從指令行方式中，我又執行了PowerPoint和Tlist，而此時我也正通過執行Tlist來產生顯示區域。
就在展示上一張幻燈片時，我們還從開始按鈕執行了行程檢視工具，而開始按鈕又由Explorer所擁有。
TList/t是一個重要的診測工具，因為，通過掌握某一行程的父行程或觀察該行程在系統行程層次（或樹型）結構中所處的位置，你能夠迅速對該行程的來源進行分類。如果這個行程是Explorer的一個子行程，則該行程必然是從桌面圖形用戶界面開始執行的。
如果這個行程是某一系統行程的子行程，則該行程必然是NT的某一片段。我們將在下下節中詳細解剖系統行程樹中的所有行程。因此，我們將先行回到顯示區域的上半部分。
Windows 2000工作管理器中的新選項是結束行程樹。
但是，關於我前面所說的Windows NT沒有保留比父行程ID更多的資訊，那麼，如果你試突結束行程工作樹並且來自樹中的所有行程均不再執行的話，將會有什麼發生呢？
工作管理器將會發現來自同一父行程的所有子行程嗎？
讓我們進行一個快速演示。
我將轉到指令行方式，並通過鍵入CMD從該指令行方式中啟動另一作為子行程的指令行方式。
現在，我們將從第二個行程中執行畫筆（亦即MS Paint）。這樣一來，我們就有了一個樹結構——一個指令行方式新增了另一個指令行方式，而另一個指令行方式新增了畫筆（亦即MS Paint）。讓我們通過執行Tlist/t來看一看該樹狀結構是如何顯示的。
這裡，我們看到了父指令行方式、子指令行方式以及作為孫子的MS Paint。
而問題是究竟發生了什麼，首先，如果我退出這個編號為712的中介指令行方式，將會有什麼發生呢？
好的，讓我們轉到該中介指令行方式並鍵入EXIT，會留下什麼呢？畫筆仍然存在。
因此，當父行程退出時，子行程並不也隨之退出。
這就出現了一個有趣的問題。如果我們現在通過按下Ctrl+Shift+Esc組合鍵彈出工作管理器，轉至應用程式選擇項，選第一個指令行方式，按下滑鼠右鍵，轉入行程，進而找到擁有視窗的行程，這就是指令行方式的實例——CMB.exe，亦即擁有第一個視窗的行程。
現在，如果我在行程樹上按下滑鼠右鍵，Windows 2000會發現畫筆嗎？請記住，畫筆是該指令行方式的孫子。讓我們來試一試，按下行程樹。工作管理器警告我說，終止一個行程可能引起資料遺失——這是因為並不存在清除線程的機會。
於是我接著做下去，按下是。畫筆仍舊執行。為什麼？再次解釋一下，這是因為NT只保留新增行程者的蹤跡，卻並不保留祖父或孫子的蹤跡。所以，請記住，你正在使用新的結束行程樹選項。
現在，讓我們看一下行程活動中另一個重要的資訊片段，也就是哪個文件被哪個行程開啟。Windows 2000或Windows NT中並未附帶相應的工具來實現上述功能，然而這又的確是一項非常重要的診測工作，因為，如果你遇到一個文件鎖死錯誤，該檔案肯定是被本機工作站或伺服器上的某一行程所開啟。
不使用這張幻燈片上提及的工具，你就無法找出是誰開啟了文件。
|