Фон

Минулого року я склав портативну систему блогу / веб-сервера, яку можна запускати з флешки. Це чудово і працює чудово, особливо на 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для безпеки. Аспект безпеки має сенс, але він нічого не говорить про те, що означає його розміщення або чому / коли це необхідно (або чи можна уникнути цього, якщо не потрібно). Навіть дискусія Реймонда Чена з цього приводу вирішує питання, чому консольні програми взагалі розміщені по-різному.

Найближче, що я можу знайти до детального, технічного пояснення, - це повідомлення в блозі Майкрософт, яке, здається, посилює думку про те, що мова йде лише про графічний інтерфейс та вікно програми консолі. Це ще більше цікавить мене, чи conhost.exeпотрібно це для таких програм без вікон, як ці сервери. Якщо вікна взагалі немає, то чому я маю витрачати ресурси і захаращувати процесний простір непотрібними процесами? Чому Windows не може визначити, що це непотрібно, і уникнути цього? SecurityMatt в відповідь також був трохи корисний щодо технічного пояснення, але знову - таки, не вистачає інформації , я шукаю.

Я не єдиний, хто намагався знайти спосіб зупинити непотрібні випадки conhost. Ця людина запитав про відключення, і йому сказали просто "це неможливо", не докладаючи жодних зусиль і не думаючи про це. Х'ю Д і "Навряд чи функція" вказали на проблему з численними зайвими примірниками conhost(принаймні csrss, запускається лише одна копія), включаючи використання ресурсів та затримані випадки після закінчення їхніх дочірніх процесів. Я Лауфер запитав, чи / коли це навіть потрібно.

Спостереження та спроби рішення

Якщо вони насправді не потрібні постійно (знову ж таки, я не бачив жодних негативних наслідків від їх вбивства), то, гадаю, я міг би (дуже дратує) вирішити проблему, замінивши сервери batch-файлами, на яких працює сервер. , зачекайте, а потім вкажіть копію, 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 кожен процес під час створення має приєднані до нього стандартні потоки введення, виведення та помилок; термінал IO реалізується з точки зору цих потоків (stdin, що надходить з клавіатури, і stdout / stderr, що йде до терміналу), і потрібні додаткові зусилля з боку процесу, який не бажає використовувати ці потоки або мати їх дескриптори файлів відкриті.

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

   Щодо різниці між ними, ваше посилання "Навряд чи функція" пояснює це досить адекватно; коротше кажучи, він існує для усунення вад безпеки в попередній ітерації висококондиційного консольного API консолі Windows, що дозволило ескалацію привілеїв у версіях NT, старших за Windows 7. (Vista, FYI, не має conhost.exe, що підходить для його статус тисячоліття Windows сімейства NT.)

2. Будь-яка програма, яка хоче еквівалент Unix stdin / stdout / stderr, потребує консолі, отже, примірник conhost.exe. Іммігранти з Unix-land, такі як Apache, PHP та ін., Захочуть ці потоки, отже, автоматична інстанція системи conhost.exeдля них, незалежно від того, відображають вони вікно чи ні. Теоретично можна було б змінити джерело, наприклад, для Apache таким, що йому не потрібен термінал, і скомпілювати його як додаток для графічного інтерфейсу Windows замість консольного додатка, щоб система не відчувала необхідності нерестувати його conhost.exe. Якщо припустити, що це також можливо на практиці, схоже, ніхто не піклувався про це. Можливо, ти будеш першим.

3. Вбивство заданого conhost.exeшару майже напевно відключить консольний вхід для будь-якого процесу, що працює під цим екземпляром. Вам, мабуть, це не цікаво, оскільки ви маєте справу з серверними процесами, які так чи інакше не роблять нічого цікавого в потоках IO консолі, тому, ймовірно, немає причин не вбивати їх conhost.exe. Якщо ви сумніваєтесь, вбийте їх і подивіться, чи щось порушує.

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

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

Інший варіант, який може працювати, це якщо процес консолі викликає FreeConsole()функцію. Деякі серверні програми підтримують параметр -d або -detach, але це, мабуть, частіше в * nix системах ...

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

Це заважає Windows нерестувати conhost.exe для вашої програми.