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 nowconhost.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.)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 ofconhost.exefor 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 aconhost.exe. Assuming it's also possible in practice, no one seems to have cared enough to do so. Perhaps you will be the first.Killing a given
conhost.exewill 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 theirconhost.exes. If in doubt, kill them off and see if it breaks anything.There is no way to prevent Windows from instantiating
conhost.exewhen 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 parentconhost.exedoesn't impair its functionality in any way you care about, you should be able to kill them all at once by issuingtaskkill /f /im conhost.exein 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 parentconhost.exeinstance is killed. Again, if in doubt, kill them off and see if it breaks anything.
(Когда) действительно необходим CONHOST.EXE?
Фон
В прошлом году я собрал портативную систему для блогов и веб-серверов, которую можно запускать с флешки. Это здорово и прекрасно работает, особенно на XP. Проблема в том, что при запуске в Windows 7 каждая консольная программа порождает два процесса, сам процесс и его копию conhost.exe.
проблема
В случае переносимой системы блогов каждый из ее серверных компонентов (MySQL mysqld.exe, два экземпляра Apache, два экземпляра httpd.exeVisualSVN visualsvnserver.exeи несколько экземпляров PHP php-cgi.exe) порождает экземпляр conhost.exe. В этот момент (без php-cgi.exeактивных копий у меня есть пять экземпляров conhost.exeработы, использующих почти без циклов ЦП, но потребляющих 22 МБ памяти (в дополнение к 80 МБ, которые в настоящее время используют реальные процессы).
Исследование
Поскольку Windows 7 был выпущен (и я думаю, что, возможно, так как Vista), я на несколько раз пытались выяснить, точно какая цель различные (новый) хост - процессы (например, conhost.exe, dllhost.exe, и taskhost.exe) делать, и являются ли они на самом деле необходимо. Я попытался убить их и обнаружил, что консольные программы продолжают работать, как для программ, которые используют окно консоли, так и для тех, которые не (например, серверы).
Я уже знаком со всей « csrss.exeWindows Vista»conhost.exe и видел такое же (почти дословно) объяснение много раз. Проблема в том, что все просто копируют и вставляют то же самое объяснение, которое не помогает. Все это говорит о том, что в XP- консольных приложениях, которые «размещены» или «работают под» csrss.exe, но в Windows 7 они были перемещены в conhost.exeцелях безопасности. Аспект безопасности имеет смысл, но он ничего не говорит о том, что означает его размещение или почему / когда это необходимо (или возможно ли избежать этого, если в этом нет необходимости). Даже в дискуссии Раймонда Чена по этому вопросу скрывается, почему консольные приложения вообще размещаются по-разному.
Наиболее подробное техническое объяснение, которое я могу найти, - это сообщение в блоге Microsoft, которое, кажется, подтверждает идею о том, что речь идет только о графическом интерфейсе и окне консольного приложения. Это заставляет меня задуматься о том conhost.exe, необходимы ли такие программы без окон, как эти серверы. Если окна вообще нет, то зачем мне тратить ресурсы и загромождать пространство процессов ненужными процессами? Почему Windows не может определить, когда это не нужно, и избежать этого? Ответ SecurityMatt также был немного полезен в отношении технического объяснения, но, опять же, недостаточно информации, которую я ищу.
Я не единственный, кто пытался найти способ остановить ненужные случаи conhost. Этот человек спросил о его отключении, и ему просто сказали «это невозможно» без каких-либо дополнительных усилий или мыслей об этом. Хью Д. и «Едва ли это особенность» указали на проблему с многочисленными избыточными экземплярами conhost(по крайней мере csrss, если была запущена только одна копия), включая использование ресурсов и длительные экземпляры после завершения их дочерних процессов. Я Лауфер усомнился, / когда это даже необходимо.
Наблюдения и попытки решения
Если они на самом деле не нужны во все времена (опять же, я не видел каких-либо побочных эффектов от их убийства), то я полагаю, что мог бы (очень раздражающе) обойти проблему, заменив серверы пакетными файлами, которые запускают серверы, подожди, а потом убей копию того, conhostчто они заставляют бежать. Конечно, это требует быстрого и простого способа определить, какой это. FallenGameR спросил, как получить экземпляр, conhost.exeсвязанный с консольной программой с заданным PID, но не получил ответа. Я бы подумал, что простое получение PID родительского процесса должно помочь (нет, ProcessExplorer не является опцией, автоматизированный / скриптовыйрешение требуется), но это не только потребует создания какой-то структуры для получения PID ребенка (вместо того, чтобы просто запустить его и выполнить задачу), но это также будет означать поиск способа сделать его совместимым с XP (например, проверка имени-образа родительского процесса). Этот пост в блоге дает один способ, но он требует PowerShell и вряд ли идеален, не говоря уже о том, что он ничего не говорит о последствиях запуска скрипта.
Вопросы)
Возможно, Microsoft считает, что никто больше не использует командные подсказки (* кашель * Windows 8 * кашель *), и поэтому предположил, что не стоит их обременять, но есть определенные сценарии, когда несколько консольных приложений работают и имеют каждое из них. порождать дополнительный, требующий памяти процесс, использующий PID, ужасно, и пытаться обойти его, в лучшем случае, ужасно неудобно.
У кого-нибудь есть точная, авторитетная информация по этому вопросу? Опять же, я уже прочитал общее объяснение; Мне интересно:
- Почему консольные приложения должны (все еще) обрабатываться по-другому вообще
- При каких конкретных обстоятельствах они должны иметь
conhost - Каковы последствия убийства
conhost - Есть ли какой-нибудь способ остановить / предотвратить / отключить / заблокировать его или хотя бы простой способ быстро справиться с ним назад?
3 ответа на вопрос
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...
Быстрое решение, которое может работать на вас. При связывании вашего приложения добавьте / SUBSYSTEM: WINDOWS к параметрам. Вы также можете использовать editbin.exe для изменения существующего исполняемого файла.
Это предотвращает появление Windows conhost.exe для вашего приложения.
Похожие вопросы
-
2
Windows 7 Home Premium запоминает пароли общего доступа к сети?
-
4
Как заблокировать выровненные по правому краю панели инструментов в Windows 7, чтобы они не выглядел...
-
4
Функция Windows 7 «Aero Snap» в Ubuntu GNOME
-
-
3
Мой второй жесткий диск не виден в Windows 7
-
7
Как заменить Блокнот в Windows 7?
-
2
Как расположить значки панели задач Windows 7 в 2 ряда?
-
1
Проблемы во время сна на Windows 7
-
6
Как управлять функцией привязки Windows 7 с помощью двух мониторов?
-
10
Как мне обновить Windows 7 RC до Windows 7 RTM?
-
3
Какая защита от шпионского ПО доступна для Windows 7?