時代的浪潮呼嘯而去，Windows似乎已死在了沙灘上。今天已沒有多少人還會從頭到尾研讀Windows時代下的那些經典書籍，以及MSDN了吧？這是由一個名為System Internals的公司開發的軟體，只有兩名員工。後來被微軟收購了，兩名員工據說也都留在微軟工作。他們的網站已經不能訪問了，當年這個網站上有不少非常有用的工具和有深度的文章。這些軟體和文章現在都歸到了Windows Sysinternals中。在Sysinternals Process Utilities這一節中，還可以看到當年的一些工具，Process Explorer, psExec, Handles等等。一 般我們使用Process Explorer來檢視程序資源使用相關的資訊。比如某個程序載入了哪些DLL（特別是當你懷疑載入了版本錯誤的dll時）。當檔案刪除不掉時，也會用它 來檢視是哪個程序打開了這個檔案（類似linux下的lsof）。要知道一個程序是如何使用記憶體的，你也應該使用這個工具–而不要相信Task Manager–主要是Task Manager中使用的術語從Windows 95以來一直在變化，老實說作為一個程式設計師，我已經很難記清楚某個版本的Task Manager中所稱的某個記憶體值究竟是什麼含義。Windows這樣做是為了照顧一些非程式設計師，從而希望在術語的使用上更易懂。但對程式設計師來 講，Process Explorer的定義更準確，也沒有變更過。最後介紹一個Process Explorer的必殺技：幫你分分鐘找出CPU Hog的罪魁禍首！原理是這樣的，當一個程序陷入CPU Hog時，往往是由某個函式呼叫引起的（或者在這個函式中存在死迴圈），這個時候你去檢視執行緒棧，很容易看到具體是哪幾行程式碼在執行。就這麼簡單！當然， 你需要將符號檔案配置好，以便使得Process Explorer可以正確地還原呼叫棧。順便說一句，這並不是Process Explorer的功能，而是Windows自身提供的dbghelp.dll的能力。這個功能應該從windows 95起就存在（不過那個時候似乎沒有dbghelp.dll，我們要實現類似的功能必須自己想辦法），但我開始使用Process Explorer來調查CPU Hog應該是從2006年左右起–因為那時候我們才用上了有雙核或者超執行緒的CPU。在此之前，一旦發生CPU Hog，我們常常只有絕望地關掉機器，因為此時CPU完全被佔滿，幾乎沒有任何可能來執行任何除錯工具。我遇到過的CPU Hog的原因：程式中有引擎+指令碼結構的。比如防毒軟體，一般會有一個防毒引擎，病毒碼往往都是一小段特殊的指令碼。有時候這些指令碼在某些情況下導致引擎陷入死迴圈。正則表示式也是由正則表示式引擎，正則表示式和被匹配的模式構成的，平常測試時無法發現問題，但有時候特殊的模式會觸發正則表示式引擎陷入死迴圈。這似乎是我在查CPU Hog問題時遇到的比較多的一個坑。迴圈中的上邊界是一個變數，但被錯誤賦值成無限大的一個值；或者迴圈中出現錯誤導致迴圈次數變數的自增被忽略。在多執行緒程式中，如果對一個List之類的結構進行遍歷，但又錯誤地修改了迭代器指向。本質上還是跟2是一致的。網路攻擊迫使CPU要處理大量的事務。這種情況下一般會伴隨網路頻寬增加–當然你要知道你的正常頻寬消耗是多少。還有一次遇到防毒引擎的錯。防毒引擎查到一個檔案染毒時，一般應該將其清除或者隔離。放入隔離區的檔案是不能訪問、執行的，防毒引擎也不會再對它進行處理。但有一次遇到防毒引擎隔離檔案失敗，對一個檔案反覆查殺和隔離，從而導致CPU Hog。

　　由Sysinternals開發的一個高階的Windows系統和應用程式監視工具，目前已併入微軟旗下。此版本的Process Explorer 不僅結合了Filemon（檔案監視器）和Regmon（登錄檔監視器）兩個工具的功能，還增加了多項重要的增強功能。包括穩定性和效能改進、強大的過濾選項、修正的程序樹對話方塊（增加了程序存活時間圖表）、可根據點選位置變換的右擊選單過濾條目、整合帶原始碼儲存的堆疊跟蹤對話方塊、更快的堆疊跟蹤、可在 64位 Windows 上載入 32位 日誌檔案的能力、監視映像（DLL和核心模式驅動程式）載入、系統引導時記錄所有操作等。