А вообще это фокус (с запуском из памяти/ресурса) мне потребовался только для одной цели:
чтобы пользователь не снимал через диспетчер задач программу.
То есть, есть два EXE-модуля, один из которых основное приложение (для связи). В нём есть поток, который контролирует наличие в памяти второго EXE-модуля (и запускает при отсутствии). А второй EXE-модуль только и делает, что контролирует наличие в памяти первого EXE-модуля (и запускает при отсутствии).
Всё бы хорошо, но TaskManager позволяет снимать дерево процессов. И в этом случае они оба умирают.
Хотел организовать запуск первого EXE-модуля из второго (и наоборот) через маленькую прокладку (из памяти), а не напрямую, чтобы TaskManager потерял информацию о том, кто чьим родителем является, и не сумел снять оба процесса "как дерево".

Может быть для этого есть иной путь?

Добавлено @ 13:25

думаю - не от железа. вот почему:
один из компов, где валится, имеет проц: Intel: 586 - Family 15 Model 2 Stepping 9.  (памяти 512, 2792мГц) - XP
на 3-х других компах с таким же ЦПУ - работает (количество памяти на них разное: 64, 256, 640) /где 64 - Win2K, на двух других XP/,
(1800мГц, 2000мГц, 2000мГц)


второй, где не работает: AMD Sempron: 586 - Family 15 Model 44 Stepping 2. (памяти 512, 1800МГц)


Это сообщение отредактировал(а) wadim - 31.12.2008, 13:26

запускай "партнера" через .bat-файл(start bla-bla).

Alexeis, независимо от документированности, этот код не должен валить "чистую"(нет потенциально глюкавого ПО с kernel-mode составляющими) систему. иначе это просто мега-баг.

wadim, варианта два: если эти бсоды случаются только в момент запуска твоего приложения, то это баг защитного/руткитного драйвера, который похукал какие-либо из вызываемых в этом куске функций и одурел(не смог обработать) от "неправильного" запуска.
если же эти бсоды бывают и в другое время, то надо прогнать тесты железа - мемтесты всякие, да эвересты...

НЕТ, падений системы в другое время замечено не было.
А последний эксперимент был поставлен после полной деинсталляции антивиря.
Не может ли влиять настройка стека? - Ведь в приведённом коде указатель стека от CMD не меняется на тот, который хотел бы иметь ресурс EXE-файла. 
Может быть он в некоторых случаях указывает на недоступную память? 
Или, может быть мой компилятор (а это Clarion 55), где-то ещё у себя в теле имеет какую-либо зависимость от указателя стека?

(Насколько я знаю, он /Clarion/ организует псевдо-потоки, а не потоки Windows, по принципу примерно как в Windows-98. Кстати программа рассчитана на работу и в среде Win-98, но тогда она не использует многого, в том числе, обсуждаемого механизма. Т.е., под Win-98 проблема не стоит)

Это предложение, полагаю, убогое. Нужно записать на диск bat-файл, 2) стартовать его, например, через CreateProcess, 3) удалить его с диска.
Скорее альтернативой может быть: 1) записать на диск запускающую программу-прокладку, 2) стартовать её через CreateProcess, 3) удалить её с диска.
Но хотелось-то - не оставлять следов на диске! Зачем излишество писания/читания на/с диск(а) ?

Можно "присоседиться" к чужому процессу (выделить память VirtualAllocEx), создать у него поток, который будет вести контроль. Желательно присоседиться к критичному для системы процессу, чтобы его нельзя было выгрузить. Вот только это тоже вирусоподобная деятельность. Правильнее всего сделать драйвер режима ядра, который будет мониторить. Это не попадает под вирусоподобную деятельность. Такой драйвер не выгрузить из юзермода.

Alexeis, я пробовал связаться с тобой через icq. Это возможно, или ты всех посылаешь, кто не в твоём списке ?

Дело в том, что у рассматриваемого программного средства предусматривается возможность обновления. на данный момент 53 версия. Два EXE-модуля обновляются нормально. А смогу ли я обновлять ПО, если одна из его составляющих будет драйвером ?

И ещё: некоторые пользователи имеют права админа, а некоторые нет !

Это сообщение отредактировал(а) wadim - 31.12.2008, 16:49

IMHO, ошибка заключается в самом алгоритме запуска.
Например, один из способов получения "имени" процесса
основан на работе с PEPROCESS.PSECTION_OBJECT.PSEGMENT.PCONTROL_AREA.PFILE_OBJECT
Каждая из структур в этой цепочке имеет кучу полей, 
которые должны быть корректно заполнены (или, по крайней мере, "обнилены").
Т.к. это не делается, то попытка работать с любым полем любой из этих 
подструктур (например, при аудите), может привести к BSOD. 
Что в общем-то и наблюдается 

Но самое главное другое: все это едрунда по сравнению с Новым Годом !
А посему, всех поздравляю ! ))

P.S.
 Первая часть поста написана искючительно для того, чтобы его не удалили
 как злостный флуд