Задний план

В прошлом году я собрал портативную систему для блогов и веб-серверов, которую можно запускать с флешки. Это здорово и прекрасно работает, особенно на 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, ужасно, и пытаться обойти его, в лучшем случае, ужасно неудобно.

У кого-нибудь есть точная, авторитетная информация по этому вопросу? Опять же, я уже прочитал общее объяснение; Мне интересно:

1. Почему консольные приложения должны (все еще) обрабатываться по-другому вообще
2. При каких конкретных обстоятельствах они должны иметьconhost
3. Каковы последствия убийстваconhost
4. Есть ли какой-нибудь способ остановить / предотвратить / отключить / заблокировать его или хотя бы простой способ быстро справиться с ним назад?

1. Консольные приложения должны обрабатываться по-разному, поскольку под ядром NT (которое лежит в основе всех 2000, XP, Vista, Windows 7 и Windows 8) они являются гражданами второго сорта. В архитектуре системы Unix каждый процесс во время создания имеет стандартные потоки ввода, вывода и ошибок, связанные с ним; Терминальный ввод-вывод реализован в терминах этих потоков (stdin, поступающий с клавиатуры, и stdout / stderr, идущий к терминалу), и требуются дополнительные усилия со стороны процесса, который не желает использовать эти потоки или имеет их файловые дескрипторы открыты.

   В архитектуре Windows NT, которая, хотя и не является прямым потомком VMS, была разработана более или менее одной и той же командой, верно и обратное; вновь порожденный процесс по умолчанию не имеет подключенных к нему потоков ввода-вывода, и такого понятия, как «терминал», не существует. Программы, которые хотят вести себя немного более Unixy-способом, могут запросить (путем объявления времени компиляции), что система создаст для них окно консоли и подключенные к нему потоки ввода / вывода; система будет делать это, но поскольку Windows, в отличие от Unix, не предоставляет вам терминалы бесплатно, требуется значительное количество дополнительных усилий для их создания, то есть раньше csrss.exeи сейчас conhost.exe.

   Что касается разницы между ними, ваша ссылка «Вряд ли особенность» объясняет это вполне адекватно; короче говоря, он существует для обхода уязвимости в предыдущей итерации весьма секретного консольного API Windows, который допускал повышение привилегий в версиях NT, более старых, чем Windows 7. (Vista, к сведению, не имеет conhost.exe, что соответствует его статус Windows Миллениум семейства NT.)

2. Любая программа, которая хочет эквивалент Unix stdin / stdout / stderr, нуждается в консоли, следовательно, экземпляр conhost.exe . Иммигранты из Unix-land, такие как Apache, PHP и др., Захотят получить эти потоки, поэтому система автоматически создаст conhost.exeдля них экземпляр , независимо от того, отображают ли они окно или нет. Теоретически, было бы возможно изменить исходный код, например, для Apache, так, чтобы он не требовал терминала, и скомпилировать его как приложение с графическим интерфейсом Windows вместо консольного приложения, чтобы система не чувствовала необходимость его создания a conhost.exe. Предполагая, что это также возможно на практике, похоже, никто не заботился об этом. Возможно, вы будете первым.

3. Убийство данного conhost.exe факта почти наверняка отключит консольный ввод-вывод для любого процесса, запущенного под этим экземпляром. Возможно, вас это не волнует, потому что вы имеете дело с серверными процессами, которые в любом случае не делают ничего интересного в консольных потоках ввода-вывода, поэтому, вероятно, нет причин не убивать их conhost.exe. Если есть сомнения, убейте их и посмотрите, не сломается ли что-нибудь.

4. Нет способа предотвратить создание экземпляра Windows conhost.exeпри запуске программы, которая запрашивает консольный ввод-вывод; единственный способ сделать это - перекомпилировать его, чтобы Windows не считала его консольным приложением. Однако, предполагая, что уничтожение родительского процесса данного сервера conhost.exeникоим образом не повлияет на его функциональность, вы должны иметь возможность убить их всех сразу, выполнив taskkill /f /im conhost.exeприглашение Run или окно консоли - предпочтительно первое, так как последний, вероятно, умрет и почти наверняка перестанет работать, как только его родительский conhost.exeэкземпляр будет убит. Опять же, если сомневаетесь, убейте их и посмотрите, не сломается ли что-нибудь.

Консольное приложение запущено с DETACHED_PROCESS флагом, не получает ни консольный, ни дочерний процесс conhost. Проблема в том, что флаг не применяется к внукам, поэтому он будет работать только с процессами, которые вы запускаете напрямую (если вы даже можете найти утилиту, которая позволяет вам указать этот флаг).

Другой вариант, который может сработать, - это если консольный процесс вызывает FreeConsole()функцию. Некоторые серверные приложения поддерживают параметр -d или -detach, но это, вероятно, более распространено в системах * nix ...

Быстрое решение, которое может работать на вас. При связывании вашего приложения добавьте / SUBSYSTEM: WINDOWS к параметрам. Вы также можете использовать editbin.exe для изменения существующего исполняемого файла.

Это предотвращает появление Windows conhost.exe для вашего приложения.