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进程的申请过程：

最后别忘记了，迁移之前的应用程序全面测试哦！