Thoughts from the EPS Windows Server Performance Team
Happy Monday everyone. It’s Day Five of our Launch Series. Today, we’re going to cover a new feature in Windows 7 / Windows Server 2008 R2 – Console Host (ConHost.exe). A good number of companies and individuals out there still run “console” applications. A console application is one that does not have a GUI, but instead relies on text input and output via a command prompt window of some sort. Windows still contains a few classic examples of console applications; Cmd.exe, NSLookup.exe, and TelNet.exe come to mind as shown below:
In previous versions of Windows, all GUI activity on behalf of non-GUI applications that ran on the desktop (console applications) was brokered by the system process CSRSS.exe. When a console application wanted to receive characters, it called one of a small set of “Console APIs” implemented in Kernel32.dll, and Kernel32 made an LPC call to CSRSS. CSRSS checked the input queue associated with the console window and returned the appropriate character-mode input through Kernel32 back to the console application. The Console application message handling mechanism in previous Windows versions looked like this:
The problem with this was that even if an application ran in the context of a regular user’s account, CSRSS.EXE runs under the Local System account. So it was possible under certain circumstances for malware to exploit weaknesses in an application in order to execute code under the more privileged Local System account in CSRSS.EXE. This kind of exploit is known as a “shatter attack” and is discussed in more detail on Wikipedia.
This exposure was addressed in Windows 7 and Windows Server 2008 R2 by running the console messaging code in the context of a new process, ConHost.exe. ConHost (Console Host) runs in the same security context as its associated console application. Instead of issuing an LPC request to CSRSS for message-handling, the request goes to ConHost. As a result, any attempts to exploit the message-handing code of the application will not result in an automatic escalation of privileges. Below is a depiction of the new mechanism for console messaging with console messaging moved from CSRSS.EXE to CONHOST.EXE:
ConHost represents a permanent change in the way that console application I/O is handled. There is no registry key or group policy setting that can force Windows to revert back to “legacy mode” console behavior. So you know what I’m going to say…TEST your application(s) on Windows 7 and Window Server 2008 R2 before deploying the new operating systems. And, keep in mind that some applications might have a GUI for most functions but still use console interfaces for batch or other functions. So, FULLY TEST your applications.
If an application does not function as expected on Windows 7, first test basic ConHost functionality by running some of the built-in Windows console applications we mentioned earlier. If these work, then it would seem that ConHost itself doesn’t have any issues. Be sure you are running the application under a user account that has the required user rights and permissions. As a test run it as an administrator. You may want to simultaneously run Process Monitor to catch any file or registry permissions issues.
If the application still fails, the next step should be to contact the application vendor or developer(s). My intuition and experience tell me that you are laughing at me right now. Let me guess… The guy who wrote the app and used to work out of his garage has moved on to bigger and better things, or the vendor no longer supports that version. If you find yourself in that sort of situation, upgrading or replacing the application is probably going to be your best long-term solution. In the short-term, you may want to consult our Knowledge Base or contact Microsoft Support or search the web to see if there are any known issues with your specific application. Keep in mind that we do not support 3rd-party applications. If the application was written internally by your application developers, Microsoft Developer Support may be able to assist.
If the application is crashing, obviously the crash dump will be of the most benefit to the application developer or vendor. If the application is hanging, you can use a tool such as AdPlus to simultaneously dump the application process and its associated ConHost.exe process. A console application can share its console window with many child processes. For example, when an application like TelNet is launched from a Cmd window, TelNet.exe becomes a child process of Cmd.exe. In this case, the same instance of ConHost.exe hosts message-handling for both the parent and child processes. Use Process Explorer to determine which ConHost.exe process is associated with which application process as shown below:
You can also use the “Analyze Wait Chain” feature of Resource Monitor to determine on which ConHost.exe process the application process is waiting as shown below:
This is one of those changes that takes a little getting used to. As I’ve said before thoroughly test your applications as a part of your deployment plan. Well – we’ve reached the end of Day Five. Guess what – I’m not on the hook for tomorrow’s post! Tomorrow we’ll start to take a look at Printing and Document Services on Windows 7 and Windows Server 2008 R2. Dane Smart is writing tomorrow’s post on What’s New in Printing and Printing Performance Enhancements.
- Jim Martin
thanks for the explanation.
ps: you're using process explorer! :D
Wow. Now that the console is out of csrss, I can dream of implementing an ssh server.. Could intercept or even write one's own conhost.exe, right? Assuming the the conhost protocol (client in kernel32.dll?) is somewhere...
This functionality is hardly a feature on a Server system, I have noticed that for every console application that runs on the server a corresponding ConHost.exe process runs, each one consuming approximately 3.7 MB, now say we have 1000 console apps running on our servers then we have lost 3.7GB of ram in addition to all the handles and resources that these apps consume under the covers as well as the CPU cycle loss, hardly fitting for a performance blog. You can hardly call this functionality fitting for a server, maybe for a Windows 7 desktop yeah!!. This needs a redesign or massive workaround for end users/developers or you're going to suffer from a lack of uptake of this Server platform for serious applications development. Interestingly these applications dont have a UI so why the overhead of ConHost.exe?.
A Well Authored Article, good information describing the rationale behind the ConHost utility.
How does that efect performance, if there are many applications that right to my console window?
How to find pragmatically conhost pid having console app pid?
I do not understand any of this. What does it mean; someone help me.
Is it possible to have cmd.exe end and leave its associated conhost.exe module still running? I have about 50 conhost.exe instances displayed in my process explorer. I am running an application that runs a DOS program from time to time. But I expect once the DOS program completes execution that the cmd.exe process and any collateral programs like conhost.exe to end.