(When) is CONHOST.EXE actually necessary?

1. Console applications must be differently handled because under the NT kernel (which underlies all of 2000, XP, Vista, Windows 7, and Windows 8) they are second-class citizens. In the Unix system architecture, every process at creation time has the standard input, output, and error streams attached to it; terminal IO is implemented in terms of these streams (stdin coming from the keyboard, and stdout/stderr going to the terminal), and extra effort is required on the part of a process which doesn't wish to make use of those streams or have their file descriptors open.

   In the Windows NT architecture, which while not a lineal descendant of VMS was developed by more or less the same team, the opposite is true; a newly spawned process by default has no I/O streams connected to it at all, and there is no such concept as a "terminal". Programs which wish to behave in a slightly more Unixy fashion may request (by compile-time declaration) that the system create for them a console window, and input/output streams connected to it; the system will do so, but since Windows, unlike Unix, doesn't give you terminals for free, a considerable amount of additional effort is required to create one, thus formerly csrss.exe, and now conhost.exe.

   As for the difference between the two, your "Hardly a feature" link explains it quite adequately; in short, it exists to work around a security flaw in the previous iteration of Windows's highly recondite console API, which allowed for privilege escalation in versions of NT older than Windows 7. (Vista, FYI, does not have conhost.exe, which is befitting of its status as the Windows Millennium of the NT family.)

2. Any program which wants the equivalent of Unix stdin/stdout/stderr needs a console, hence an instance of conhost.exe. Immigrants from Unix-land, such as Apache, PHP, et al., are going to want these streams, hence the system's automatic instantiation of conhost.exe for them, whether they actually display a window or not. In theory, it would be possible to modify the source for e.g. Apache such that it required no terminal, and compile it as a Windows GUI application instead of a console application, so that the system wouldn't feel the need to spawn it a conhost.exe. Assuming it's also possible in practice, no one seems to have cared enough to do so. Perhaps you will be the first.

3. Killing a given conhost.exe will almost certainly disable console IO for whatever process is running under that instance. You probably don't care about that because you're dealing with server processes that aren't doing anything interesting on the console IO streams anyway, so there's probably no reason not to kill their conhost.exes. If in doubt, kill them off and see if it breaks anything.

4. There is no way to prevent Windows from instantiating conhost.exe when a program is launched which requests console IO; the only way to do so would be to recompile it so that Windows doesn't regard it as a console application. However, assuming that killing a given server process's parent conhost.exe doesn't impair its functionality in any way you care about, you should be able to kill them all at once by issuing taskkill /f /im conhost.exe in a Run prompt or a console window -- preferably the former, since the latter will probably die, and almost certainly cease to work, as soon as its parent conhost.exe instance is killed. Again, if in doubt, kill them off and see if it breaks anything.

A console application started with the DETACHED_PROCESS flag does get a console nor a conhost child process. The problem is that the flag does not apply to grand-children so it will only work with the processes you start directly (if you even can find a utility that allows you to specify this flag).

The other option that might work is if the console process calls the FreeConsole() function. Some server applications support a -d or -detach parameter but this is probably more common on *nix systems...

Quick solution that may work for you. When linking your application add /SUBSYSTEM:WINDOWS to the options. You could also used editbin.exe to modify an existing executable.

This prevents windows from spawning a conhost.exe for you application.