今天，將向大家介紹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進程的申請過程：

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