原來windows 7之前的主機程序都是由csrss.exe完成的，所有命令行進程都使用session獨有的csrss.exe進程。在win7中，每個命令行進程都有壹個獨立的conhost作為主機。當然也有很多好處，比如之前的流程不會互相影響，不會影響csrss。畢竟，csrss還有其他更重要的任務要做。當然最重要的還是安全考慮，因為csrss是在本地系統的賬號下運行的，如果要處理窗口消息，就要承受很多威脅，比如著名的窗口消息shatter攻擊。但如果是用用戶權限的conhost處理，即使有攻擊，也只會影響低權限的主機進程。
事實上，無論是作為普通用戶還是企業管理員，在日常的Windows應用和運維過程中，我們或多或少都會用到控制臺應用。控制臺應用程序沒有用戶界面，我們需要通過命令提示符(CMD，不是DOS，很多人很困惑)輸入輸出。Windows自帶控制臺應用，如cmd.exe、nslookup.exe和telnet.exe。
在Windows的早期版本中，所有代表非GUI活動的應用程序(即控制臺應用程序)在桌面上運行時都由系統進程Csrss.exe進行協調。當控制臺應用程序需要接收字符時，它會調用Kernel32.dll的壹個小“控制臺API”讓Kernel32生成LPC來調用CSRSS。此時，CSRSS將檢查和驗證控制臺窗口的輸入隊列，並通過Kernel32將字符模式的結果返回給控制臺應用程序進行關聯。
這樣的處理機制產生了壹個問題:即使控制臺應用程序在普通用戶的上下文中執行，Csrss.exe也總是在本地系統帳戶的權限下運行。因此，在某些情況下，“壞人”開發的惡意軟件可能會通過Csrss.exe獲得更多權限，這些權限是以本地系統帳戶的權限執行的。這種攻擊模式被稱為粉碎攻擊。在win7和Windows Server 2008 R2時代，所有的控制臺應用程序都在壹個新的上下文進程ConHost.exe中執行，ConHost(控制臺主機)和控制臺程序運行在相同的安全級別上下文環境中，而不是發送LPC消息請求到CSRSS進行處理，來請求ConHost。因此，任何試圖使用消息請求來導致特權自動提升的應用程序都不會成功。