Propblem with TerminateProcess
in [Win32 Kernel]
|
From: Emil Dotchevski on 6 Feb 2010 18:19 On Feb 6, 2:14 pm, Hector Santos <sant9...(a)nospam.gmail.com> wrote: > Emil Dotchevski wrote: > > You mean it worked? > Righ (it worked). But its an illusion. I ran it a few more times with > 100 and it didn't provided the expected result at least one time in > the loop. Interesting. I am also using XP SP3 and on my system it fails almost 100% of the time. It is possible that it's not Vista/Win7 that fixes it, it seems plausible that if the computer is fast enough it works simply because the process manages to get past a certain point in its execution, at which point it just works fine. > You simply have no control of where TerminateProcess() will kill the > process. You are the mercy of the system context switching forced or > natural. I know. In general, the exit code would be different if the child manages to call ExitProcess before TerminateProcess manages to kill it. However, in my actual use case (not the code I posted) I know that the process isn't executing because I call TerminateProcess in response to a debugging notification that a process is starting; and in the code I posted, I know the process being killed doesn't call ExitProcess (though now that I think about it, it might actually call ExitProcess before it reaches main, which would indeed explain the observed behavior.) > "Do not terminate a process unless its threads are in > known states. If a thread is waiting on a kernel object, it > will not be terminated until the wait has completed. This can > cause the application to hang." > > Could that mean that unless the child reaches the main (thread) entry > point, that TerminateProcess() exit code MAY NOT be reliable? I don't think it could mean that. Nothing in the documentation hints on the exit code not being reliable under any circumstances. > You Terminated the Process, you KNOW that the exit code > is regardless of what anything else said. It is 42 PERIOD! > Who cares what the "System" says it is. It has to be 42 and > nothing else. This logic is not valid in general. Consider that the exit code isn't always consumed by the process that calls TerminateProcess. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
From: Hector Santos on 7 Feb 2010 13:48 Emil Dotchevski wrote: > Interesting. I am also using XP SP3 and on my system it fails almost > 100% of the time. It is possible that it's not Vista/Win7 that fixes > it, it seems plausible that if the computer is fast enough it works > simply because the process manages to get past a certain point in its > execution, at which point it just works fine. But its still an illusion - a hope that it will work fine under "some" ideal conditions but not others. That is what people here are trying to tell you. Have you tried your code under a single CPU machine? Have your tried putting a class instance before the main entry point, like this: class cfoobar { public: cfoobar() { if (strstr(GetCommandLine(),"inf")) { ExitProcess(1); } } } foobar; How does it behave with no sleep, Sleep(0), Sleep(1) before TerminateProcess()? You will be totally surprise on how the posting code is totally unreliable in expected behavior. You might even see access (5) violations. Even try putting a infinite loop in the cfoobar constructor and you might get it lock. >> You Terminated the Process, you KNOW that the exit code >> is regardless of what anything else said. It is 42 PERIOD! >> Who cares what the "System" says it is. It has to be 42 and >> nothing else. > > This logic is not valid in general. Consider that the exit code isn't > always consumed by the process that calls TerminateProcess. In my view, if you know this non-consistent behavior can occur, then you really have no choice but to lock it in that 42 is a parent process global condition when it calls TerminateProcess(hProcess,42). Not graceful in ideal "code" integration, but what choice do you have? None. Not the code requirements you are looking for. -- HLS
From: Boba on 7 Feb 2010 14:05 I'd love to see the results of your test run for XP3 & Win7 on the same hardware.
From: Hector Santos on 7 Feb 2010 15:22 Emil Dotchevski wrote: > On Feb 6, 2:14 pm, Hector Santos <sant9...(a)nospam.gmail.com> wrote: >> Emil Dotchevski wrote: >>> You mean it worked? >> Righ (it worked). But its an illusion. I ran it a few more times with >> 100 and it didn't provided the expected result at least one time in >> the loop. > > Interesting. I am also using XP SP3 and on my system it fails almost > 100% of the time. The only machine/OS I can duplicate almost 100% is on my old development machine Window 2000, single intel CPU machine. Not on my XP SP3/Multi-core box. Random failure (unexpected result). -- HLS
From: Paul Baker [MVP, Windows Desktop Experience] on 8 Feb 2010 10:55
> "Emil Dotchevski" <emildotchevski(a)gmail.com> wrote in message > news:823dbb82-a5e1-40ca-8d9e-fcea24415598(a)m27g2000prl.googlegroups.com... > Hector, thanks for trying the code. > On Feb 5, 7:48 pm, Hector Santos <sant9...(a)nospam.gmail.com> wrote: > > In my view, what you are presuming that TerminateProcess() will always > > be correct, regardless if the child process was successfully loaded > > and started. > ...or return an error. .... or already finished :) |