Propblem with TerminateProcess
in [Win32 Kernel]
|
From: m on 3 Feb 2010 21:17 What is it that you are trying to do that a delay of a few ms from process creation to a call to TerminateProcess() is not okay? You should be aware that you can see delays much longer that that as a matter of course with Windows scheduling and you should be aware that if this is an anti-malware application, you have no chance of success with this approach. "Emil Dotchevski" <emildotchevski(a)gmail.com> wrote in message news:d5dbc27e-aaa7-45ec-a619-460c487dbdbf(a)x1g2000prb.googlegroups.com... > On Feb 3, 4:40 pm, David Lowndes <Dav...(a)example.invalid> wrote: >> >On my system (XP SP3) the test below fails nearly 100% of the time. >> So presumably, once in a blue moon it's OK? > > Right. I suspect it succeeds if the system randomly happens to do > something else that slows the TerminateProcess down. Like me hitting > Ctrl+F5 frantically. :) > >> >When it fails, the process being killed returns zero (instead of 42.) >> >> What happens if you wait a short time after starting the process >> before terminating it? > > The more Sleep I add before calling TerminateProcess, the more likely > it is for the program to work correctly; Sleep of about 5 ms makes it > work almost always on my computer. However, my real use case is such > that I can't afford to Sleep, and the process I'm killing is launched > by a 3rd party program. > > By the way, I get feedback that the code I posted works on Win7. > > Emil Dotchevski > Reverge Studios, Inc. > http://www.revergestudios.com/reblog/index.php?n=ReCode
From: Emil Dotchevski on 3 Feb 2010 21:40 On Feb 3, 6:17 pm, "m" <m...(a)b.c> wrote: > What is it that you are trying to do that a delay of a few ms from process > creation to a call to TerminateProcess() is not okay? In principle it is not OK to address race problems with delays, is it? > You should be aware > that you can see delays much longer that that as a matter of course with > Windows scheduling and you should be aware that if this is an anti-malware > application, you have no chance of success with this approach. I think this is outside of the scope of my question, but here's what I really want to get working: Process P0 ("my program") is the debugger for process P1. P0 gets notified when P1 launches a process P2. In that notification handler, I want to be able to kill P2 such that P1 gets an exit code of my choosing. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
From: Stefan Kuhr on 4 Feb 2010 03:01 Hi Emil. On 2/4/2010 3:40 AM, Emil Dotchevski wrote: > On Feb 3, 6:17 pm, "m"<m...(a)b.c> wrote: >> What is it that you are trying to do that a delay of a few ms from process >> creation to a call to TerminateProcess() is not okay? > ><snip> > Process P0 ("my program") is the debugger for process P1. P0 gets > notified when P1 launches a process P2. In that notification handler, > I want to be able to kill P2 such that P1 gets an exit code of my > choosing. Set up a program of yours to always be the JIT Debugger for process P2. If you always know the name of P2 in advance, this is an easy thing to do. -- S
From: m on 4 Feb 2010 19:06 No, it is not OK to address race conditions by adding delays. If one does, then one will get a program that might work the first few times, or the first few million time, but will eventually break because of an anomalous delay of some kind. The question is outside the scope of your original question - but that was the point. I couldn't think of any reason why you would care about this erratic behaviour, but now that we know something about what you are trying to achieve some other solutions present themselves. Specifically, I suggest that you try to replace the .EXE for P2 with a version that exits with the code you want. It could read this from a named pipe, a registry key or whatever. Another solution is to setup to be loaded into P2 and then ABEND from within. The problem that you have with your current design, is that the process P2 could run to completion before you get a chance to terminate it, or it could be running 'normally', or it might be embryonic and not respond well to TerminateProcess(). "Emil Dotchevski" <emildotchevski(a)gmail.com> wrote in message news:7fa69105-091a-4cfb-98fc-2738eaa66c18(a)w27g2000pre.googlegroups.com... > On Feb 3, 6:17 pm, "m" <m...(a)b.c> wrote: >> What is it that you are trying to do that a delay of a few ms from >> process >> creation to a call to TerminateProcess() is not okay? > > In principle it is not OK to address race problems with delays, is it? > >> You should be aware >> that you can see delays much longer that that as a matter of course with >> Windows scheduling and you should be aware that if this is an >> anti-malware >> application, you have no chance of success with this approach. > > I think this is outside of the scope of my question, but here's what I > really want to get working: > > Process P0 ("my program") is the debugger for process P1. P0 gets > notified when P1 launches a process P2. In that notification handler, > I want to be able to kill P2 such that P1 gets an exit code of my > choosing. > > Emil Dotchevski > Reverge Studios, Inc. > http://www.revergestudios.com/reblog/index.php?n=ReCode
From: Hector Santos on 4 Feb 2010 20:33
Emil Dotchevski wrote: > On Feb 3, 6:17 pm, "m" <m...(a)b.c> wrote: >> What is it that you are trying to do that a delay of a few ms from process >> creation to a call to TerminateProcess() is not okay? > > In principle it is not OK to address race problems with delays, is it? In "Sync 101", right, it is a taboo to synchronize using time. It is bound to rear its ugly head at some point. In theory, only in a RTOS can you make closer predictions and guarantees using time. Windows is not an RTOS. > Process P0 ("my program") is the debugger for process P1. P0 gets > notified when P1 launches a process P2. In that notification handler, > I want to be able to kill P2 such that P1 gets an exit code of my > choosing. Try using named kernel objects (Mutexes) to synchronized. This is one usage where they are good for. -- HLS |