Win 7的新功能：控制台主機（ConHost.exe）

今天，將向大家介紹Windows 7 / Windows Server 2008 R2的新功能－控制台主機（ConHost.exe）。

其實，不論是作為普通用戶還是企業管理員，我們在日常的Windows應用和維運過程中都會或多或少的使用到控制台應用程式。控制台應用程式是沒有使用者介面的，我們需要透過命令提示字元（CMD，這可不是DOS，很多人混淆不清）對其進行輸入、輸出操作。

那麼大家來回想一下，Windows自帶了哪些控制台應用程式呢？

其實最典型的就有cmd.exe、nslookup.exe和telnet.exe等。

在早期的Windows版本中，所有代表非GUI活動的應用程式（即控制台應用程式）要在桌面上執行時，都透過系統進程Csrss.exe進行協調。當控制台應用程式需要接收字元時，會在Kernel32.dll中呼叫一個小型的「控制台APIs」以讓Kernel32產生LPC來呼叫CSRSS。此時CSRSS會對控制台視窗的輸入佇列進行檢查和校驗，並將字元模式的結果透過Kernel32傳回控制台應用程式進行關聯。早期Windows版本中控制台應用程式對訊息的處理機制如下圖所示：

這樣的處理機制就已經產生了一個問題：即使一個控制台應用程式在普通使用者的上下文環境中執行，但Csrss.exe始終是運行在本機系統帳戶權限下的。因此，某些情況下「壞人」開發的惡意軟體就有可能透過本機系統帳戶權限執行的Csrss.exe取得到更多特權。這種攻擊模式被稱為Shatter Attack。

而到了Win7和Windows Server 2008 R2時代，所有控制台應用程式都被放到了一個新的上下文進程ConHost.exe中來執行，而ConHost（控制台主機）與控制台程式運行在相同安全級的上下文環境當中，取代了發出LPC訊息請求到CSRSS中進行處理這種機制，而是去請求ConHost。因此，任何應用程式企圖利用訊息請求來導致特權的自動提升都不會成功。下圖為Windows7與Windows Server 2008 R2中所採用新機制的示意圖：

ConHost取代了在控制台應用程式對I/O處理方式的永久性變化，使用者無法透過登錄或群組原則強制將Windows還原到「傳統模式」控制台的行為（機制）。因此，使用者需要在升級到Windows7或Windows Server 2008 R2之前對應用程式進行全面的測試。請不要忘記，雖然有的應用程式大部分功能都透過GUI來實現，但仍然在後台透過控制台或其它功能介面對資料進行批量處理。因此，在遷移或等級之前進行全面的應用程式功能測試是非常必要的。

當有應用程式無法在Windows7中正常使用時，我們應先測試使用管理員權限再次執行看問題是否發生，其實再使用Process Monitor來監控此應用程式對檔案或登錄機碼是否正常的存取權。如果排除以上問題應用程式還是無法正常運作，您則需要考慮聯絡ISV或其開發人員了。

如果應用程式發生崩潰，相應的崩潰轉儲檔案是最有利於開發人員和ISV找到問題癥結的。如果應用程式停止回應，您可以嘗試使用ADPlus來抓取它及與其相關的ConHost.exe進程Dump。控制台應用程式可以共用Windows控制台的許多子進程，例如：當使用者從CMD視窗啟動Telnet，則Telnet.exe會成為Cmd.exe的子進程。在此種情況下，ConHost.exe主機則同時處理父進程和子進程的訊息實例。透過使用Process Explorer我們便可以確認ConHost.exe正在處理哪些進程：

您也可以用Windows7資源監視器功能中自帶的「分析等待鏈」功能來查看ConHost.exe進程的申請流程：

最後別忘記了，遷移之前的應用程式全面測試哦！