Background
Last year I compiled a portable blog/web-server system that I can run from a flash-drive. It’s great and works wonderfully, especially on XP. The problem is that when it’s run in Windows 7, each console program spawns two process, the process itself, plus a copy of conhost.exe
.
Problem
In the case of the portable blog system, each one of its server components (MySQL’s mysqld.exe
, Apache’s two instances of httpd.exe
, VisualSVN’s two instances of visualsvnserver.exe
, and PHP’s multiple instances of php-cgi.exe
) spawns an instance of conhost.exe
. At this moment (with no copies of php-cgi.exe
active, I have five instances of conhost.exe
running, using up next to no CPU cycles, but consuming 22MB of memory (in addition to the 80MB that the actual processes are currently using).
Research
Since Windows 7 was released (and I think possibly since Vista), I have on several occasions tried to figure out exactly what purpose the various (new) host processes (e.g., conhost.exe
, dllhost.exe
, and taskhost.exe
) do and whether they are actually necessary. I have tried killing them and found that the console programs continue to work, both for programs that use a console window, and those that don’t (like servers).
I am already familiar with the whole csrss.exe
⇨ Windows Vista ⇨ conhost.exe
and have seen that same (almost verbatim) explanation numerous times. The problem is that everybody simply copy-pastes that same explanation which is not helpful. All it says is that in XP-, console applications where “hosted by” or “run under” csrss.exe
, but in Windows 7, they were moved to conhost.exe
for security. The security aspect makes sense, but it says nothing about what it means to host it or why/when it’s necessary (or whether it’s possible to avoid it if not necessary). Even Raymond Chen’s discussion on the matter glosses over why console apps are hosted differently at all.
The closest thing I can find to a detailed, technical explanation is a Microsoft blog post which seems to reinforce the idea that it’s merely about the console app’s GUI and window. This leaves me wondering even harder whether conhost.exe
is necessary for windowless programs like these servers. If there is no window at all, then why should I have to waste resources and clutter the process-space with unnecessary processes? Why can’t Windows detect when it’s unnecessary and avoid it? SecurityMatt’s response was also slightly useful in regards to a technical explanation, but again, not enough of the information I’m looking for.
I’m not the only one who has tried to figure out a way to stop unnecessary instances of conhost
. This person asked about disabling it and was told simply “it’s not possible” with no further effort or thought about it. Hugh D and “Hardly a feature” pointed out the issue with numerous, redundant instances of conhost
(at least with csrss
, there was only a single copy running), including the resource usage and lingering instances after their child processes have ended. I Laufer questioned whether/when it’s even necessary.
Observations and Solution Attempts
If they are not actually necessary at all times (again, I have not seen any ill effects from killing them), then I suppose I could (very irritatingly) work-around the issue by replacing the servers with batch-files that run the servers, wait, and then kill the copy of conhost
that they cause to run. Of course this requires a quick and easy way of determining which one it is. FallenGameR asked how to get the instance of conhost.exe
associated with a console program of a given PID but did not get an answer. I would think that simply retrieving the PID of the parent process should do the trick (no, ProcessExplorer is not an option, an automated/scriptable solution is required), but not only would that require creating some sort of framework to get the PID of the child (instead of simply running it and being done with the task), but it would also mean figuring out a way to make it compatible with XP as well (e.g., checking the image-name of the parent process). This blog post gives one way, but it requires PowerShell and is hardly ideal, not to mention it says nothing about the ramifications of running the script.
Question(s)
Perhaps Microsoft figure that nobody uses command-prompts anymore (*cough*Windows 8*cough*) and so assumed that it’s not a big deal to burden them, but there are definitely scenarios where multiple console apps are running and having each and every one spawn an extra, memory-consuming, PID-using process is awful, and trying to work around it is, at best, horribly inconvenient.
Does anybody have definitive, authoritative information on the matter? Again, I have already read the generic explanation; I am wondering:
- Why console applications must (still) be handled differently at all
- Under what specific circumstances they need to have
conhost
- What the consequences are of killing
conhost
- If there’s any way to stop/prevent/disable/block it or at least an easy way to quickly deal with it aftwards?
conshost.exe
still spawning?conhost.exe
was the Windows' equivalent of a PTY, andcmd.exe
was the shell.