Microsoft is constantly making changes to how things work in Windows (and then not really telling anyone about them). I spend a lot of time at the command prompt because it’s faster and easier than trying to wade through the GUI to perform many tasks. In fact, it’s because I spend all of this time at the command prompt that I wrote both Administering Windows Server 2008 Server Core and Windows Command-Line Administration Instant Reference.
What many people don’t know is that the command prompt application, CMD.EXE, doesn’t include its own user interface processing features. This means that items like the message pump are handled by some other application. Until Windows 7, Windows would rely on the Client Server Runtime Subsystem (CSRSS.EXE) to provide the required services every time you started a command prompt. The CSRSS.EXE process would handle the message processing for the command session. (This same process used to handle the message processing for other calls as well, such as printf() used in C/C++ application development—see C++ All-In-One Desk Reference For Dummies for details.)
Unfortunately, CSRSS.EXE runs using the LocalSystem account privileges, which represents a security hole. Yes, there are significant advantages for using this account for local services, but most user mode applications don’t require such high privileges. As a result, Microsoft introduced the ConHost.EXE worker process in Windows 7. This worker process is started by CSRSS.EXE, but runs at the least privilege required by the user to perform tasks as the command prompt. There is one copy of ConHost.EXE for each command prompt that you open. If you’re running Windows 7, you’ll now see this process in the Windows Task Manager every time you open a command prompt as shown here:
This new entry will also show up when you run command line utilities, such as TaskList. What this means is that when working with Windows 7, you need to account for ConHost.EXE in any scripts you create and be aware of the effect of this new service on your code. The use of ConHost.EXE does indeed make things a lot more secure. It also makes it possible to debug the internals of console applications with greater ease when you’re using a low-level debugger (see Inside Windows Debugging, written by Tarik Soulami, a book I’m currently technically editing for details). In short, this is a better, but different way to do things.
I’d like to provide a special thank you to Tarik for the insights he provided for this post. Please contact me at John@JohnMuellerBooks.com for any questions you might have about ConHost.EXE.