TerminateProcess How to

Как мога да разбера кога процеса е напълно завършил след викане на TerminateProcess (всички файлове които използва вече са затворени)..

имам ли право да ползвам WaitForSingleObject след TerminateProcess... пробвах с него но няма ефект

int Proc;
HANDLE hProc;
STARTUPINFO si;
ZeroMemory(&si,sizeof(si));
PROCESS_INFORMATION pi;
Proc=CreateProcess(NULL,ComandLine,NULL,NULL,TRUE,NORMAL_PRIORITY_CLASS,NULL,".",&si,&pi);
if(!Proc)
{
Application->MessageBox("I can't start Load. Please check all files.","Error",MB_OK);
return -111;
}
hProc=pi.hProcess;
Application->ProcessMessages();
char S[256];


...............

for(;;){
if(StopTesting)
TerminateProcess(hProc,-1);
DWORD Ret=WaitForSingleObject(hProc,1);
if(Ret==WAIT_OBJECT_0)
{
break;
}
}
ми върши работа.

Значи, проблема ми е че като kill-на app-то което съм пуснал с CreateProcess не се kill-ват child процесите му.. anyway.. намерих едно тъпо решение

sigurno znaesh de, ama TerminateProcess ne e napravena za da se vika ot prostosmyrtni? Naj-veroqtno trqbva da si opravish prilojenieto (osven ako ne pishesh debugger de)....

Dev. environment правим и трябва компилацията да може да се прекъсва... проблема беше че компилатора пуска други процеси и когато терминираме компилатора другите процеси продължават докато не приключат .. както и да е.. намерихме вече решение

sto ne go spodelis da znaeme i nie kak stava

Става много просто:
при успех на CrateProcess в последния параметър се връща ID-то на процеса, който си създал. След TerminateProcess можеш да изброиш всички живи процеси с API фунциите CreateToolhelp32Snapshot, Process32First, Process32Next. Последните две функции пълнят структура PROCESSENTRY32, която има поле th32ParentProcessID. Е от тука сравняваш стойността на това поле със стойността върната ти от CreateProcess и разбираш кои са му били дъщерните процеси.
п.п. ако случайно работиш на NT4.0 това няма да сработи, просто защото тези API функции не са имплементирани там. има и други начини но те са по-завъртяни, но са поне още 2-3, а също така не са толкова кратки за обяснение.

a ako ima child na umrql ve4e child proces?

ex:
parent -> child1 -> child2

later..

parent e jiv
child1 e umrql ve4e
child2 e jiv no nema vrazka sas parent

vav 2000 i nagore ima nqkakvi jobove mozebi sas tqh se pravi nesto takova nqkoj da se e zanimaval stqh ?

мдааа, много уместна бележка.
не бях се сетил за това.
имаш частично решение на проблема ако създадеш процеса с флага CREATE_NEW_PROCESS_GROUP в параметъра dwCreationFlags, но то обхваща само подмножество от всички ситуации (т.е. 1. ако дъщерните процеси са конзолни; и 2. ако обработват събитието CTRL_BREAK_EVENT ).

работил съм с джобове ( имам предвид jobs, не съм джебчия ), те не то помагат да решиш този проблем.

да се create'не процес със флаг ала дебъг.
И тогава с малко гимнастика като утрепеш мастер процеса - всичко останало ще бъде киллнато също.

kakvo imas vpredvid pod 'c малко гимнастика '
os-a li se gi iztrepe (zarad debug-a , 4estno kazano s tva ne sam se zanimaval nikogash) ili pak se gledash dali sa tvoite procesi i ti se si gi trepes po nqkakv kriterii

има един начин да го направиш, но не ти го препоръчвам, защото използва недокументирани функции/структури/константи на Windows-а. Това е функциятя NtQueryInformationProcess от NtDll.dll с втори параметър ProcessBasicInformation, в инфото попълнено от функцията вземаш стойността на PebBaseAddress от структурата PROCESS_BASIC_INFORMATION, което е указаел към друга структура, TEB, от нея вземаш полето ProcessGroup.
Ако създадеш първия процес с флага CREATE_NEW_PROCESS_GROUP, можеш по ID-то на процеса уникално да идентифицираш всичките му дъщерни, поддъщерни и под-под-...-дъщерни процеси.
п.п. трябва да си мноооооооого на зор за да го ползваш това. аз не бих

да се направи някакъв диспечер или нещо подобно, който може да не прави нищо но да го има...
Не съм ползвал такива неща - просто идеи от един колега, дето и той само ги е гледал ама не ги е правил...

maj tova e kulturnia na4ina pone za win2000 i nagore


[линк]

Call CreateJobObject before spawning the killable process.
Call CreateProcess to spawn the killable process. (Create this process suspended.)
Call AssignProcessToJobObject to associate the new process with your Job object. Note that if the new process spawns any additional processes, the new processes are automatically assigned to this same job. That's why you must spawn this new process suspended. If you didn't, the new process could spawn a child process before MainApp had a chance to associate the first process with the Job.
Call ResumeThread to resume the spawned process's primary thread.
Now, MainApp determines when the Job is done by waiting on the Job object, or MainApp can forcibly kill all processes in the Job object by calling TerminateJobObject. Note that you can kill all processes associated with a Job object regardless of whether these applications are console or GUI applications.
There are several more cool things that you can do with Job objects on Windows NT 5.0. I strongly encourage you to examine the documentation and prepare for the future.