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 3 rd -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
| Share this post : |
|
|
|
|
|
|
|
|
<br/>
Microsoft
