WaitForSingleObject() and Process termination,...
in [Win32 Kernel]
|
From: Kerem Gümrükcü on 18 Feb 2010 00:26 Hi, yes it is and it looks like this <code> DWORD dwProcessID = PROCESSID; WFSO(HANDLE); try_again: #If CHECKPROCESSISTH32LISTED(dwProcessID) SLEEP(500); goto try_again; #endif //process is no more </code> It looks similar to this and it works reliable so far,... Regards Kerem -- ----------------------- Beste Gr�sse / Best regards / Votre bien devoue Kerem G�mr�kc� Latest Project: http://www.pro-it-education.de/software/deviceremover Latest Open-Source Projects: http://entwicklung.junetz.de ----------------------- "m" <m(a)b.c> schrieb im Newsbeitrag news:O0Drz4DsKHA.4220(a)TK2MSFTNGP05.phx.gbl... > okay - so obviously you are prepared for the three scenarios that I > mentioned, and are not concerned about them, so this process termination > signal is just a shunt into your polling cycle - right? > > "Kerem G�mr�kc�" <kareem114(a)hotmail.com> wrote in message > news:uWwNXz$rKHA.6004(a)TK2MSFTNGP04.phx.gbl... >> Yes, that true, i am polling, thats >> exactly what i am doing here, since >> everything else has no meaning,... >> >> Regards >> >> K. >> >> -- >> ----------------------- >> Beste Gr�sse / Best regards / Votre bien devoue >> Kerem G�mr�kc� >> Latest Project: http://www.pro-it-education.de/software/deviceremover >> Latest Open-Source Projects: http://entwicklung.junetz.de >> ----------------------- >> >> "m" <m(a)b.c> schrieb im Newsbeitrag >> news:eDNTc49rKHA.5356(a)TK2MSFTNGP02.phx.gbl... >>> Is this a process that you have spawned? I am not sure what you >>> high-level objective is, but in general this is an inherently unreliable >>> design since the OS does not expose any UM mechanism to synchronize with >>> its internal actions and you therefore must poll. This means that you >>> could find process that don't exist, miss processes that do exist & miss >>> the entire lifetime of a process. >>> >>> "Kerem G�mr�kc�" <kareem114(a)hotmail.com> wrote in message >>> news:e6PwmS8rKHA.4360(a)TK2MSFTNGP05.phx.gbl... >>>> Hi rogero, >>>> >>>>> Isn't getting a WFSO return all you need >>>> >>>> no, unfortunately not. Whenever WFSO >>>> returns, i have to actualize a internal list >>>> of running/dead processes and this is the >>>> problem. When WFSO returns and i assume >>>> that the process is dead, do a list refresh, >>>> the process still exists in the OS tables and >>>> the list is not valid. Doing something like >>>> Sleep(...) is fine, but not reliable, since this >>>> depends on the os load at the moment and >>>> when os is under heavy load, then it possibly >>>> is not enough time. But i solved it another way >>>> using a simple "goto". When WFSO returns >>>> i do make a snapshot and check if the process >>>> is still listed in. If yes, i just wait for a 500ms >>>> then try the snapshot again, and if the process >>>> is still there,....and so on until its not there. Its >>>> mostly a matter of max 1 sec and everything is >>>> fine, since its inside a thread (access to the list >>>> secured by snyc primitves!). Sometimes its 1 >>>> sec. somtimes even 3, depending on the OS load. >>>> So i think this is a good solution. If you have a >>>> better one, please let me know,... >>>> >>>> Regards >>>> >>>> Kerem >>>> >>>> -- >>>> ----------------------- >>>> Beste Gr�sse / Best regards / Votre bien devoue >>>> Kerem G�mr�kc� >>>> Latest Project: http://www.pro-it-education.de/software/deviceremover >>>> Latest Open-Source Projects: http://entwicklung.junetz.de >>>> ----------------------- >>>> >>>> "rogero" <roger.orr(a)gmail.com> schrieb im Newsbeitrag >>>> news:80daf462-7b7e-4d74-bb8b-1a512b97a133(a)k19g2000yqc.googlegroups.com... >>>>> On Feb 16, 7:04 pm, Kerem G�mr�kc� <kareem...(a)hotmail.com> wrote: >>>>>> Hi, >>>>>> >>>>>> > You've not closed your handle to the process? >>>>>> >>>>>> i did but this is not the point. When the process >>>>>> dies and my WFSO returns and when i wait for >>>>>> a few seconds (Sleep(...)) inside my thread, then >>>>>> the snapshot does not contain the process anymore. >>>>>> Its a matter of synchronization. So the point is: The >>>>>> process dies, the handle gets signaled, but the OS >>>>>> still keeps some information of the object in its >>>>>> structures,...or why does CT32S still return that >>>>>> information. I dont know why the internall >>>>>> NtQuerySystemInformation function call (on vista >>>>>> at least CT32S uses it) still returns that information. >>>>> >>>>> Nor do I: it usually seems to skip terminated processes >>>>> whose EPROCESS entry is waiting until the last handle is closed. >>>>> (In this state you can still open the process handle, but can't to do >>>>> much with the returned handle except query the exit code.) >>>>> >>>>> Isn't getting a WFSO return all you need >>>>> >>>>> Roger. >>>>
From: Ben Voigt [C++ MVP] on 18 Feb 2010 14:25 > So i think this is a good solution. If you have a > better one, please let me know,... It is not. Calling sleep is never a solution to anything. Just filter out processes which have already exited (use GetProcessExitCode, or WFSO with zero timeout).
From: m on 18 Feb 2010 18:38 That really wasn't what I was asking, but you have just shown a good example of a goto loop (something widely discouraged)! To restate: I assume that code that calls this code is expecting the conditions that I mentioned and that this code is a shunt into a polling cycle to optimize the case where a process that you care about has exited. If not, then as Ben Voigt says, Sleep() isn't a solution, but a way to decrease the probability of failure. "Kerem G�mr�kc�" <kareem114(a)hotmail.com> wrote in message news:ezp$krFsKHA.4220(a)TK2MSFTNGP05.phx.gbl... > Hi, > > yes it is and it looks like this > > <code> > > DWORD dwProcessID = PROCESSID; > > WFSO(HANDLE); > > try_again: > > #If CHECKPROCESSISTH32LISTED(dwProcessID) > SLEEP(500); > goto try_again; > #endif > > //process is no more > > </code> > > It looks similar to this and it works > reliable so far,... > > Regards > > Kerem > > -- > ----------------------- > Beste Gr�sse / Best regards / Votre bien devoue > Kerem G�mr�kc� > Latest Project: http://www.pro-it-education.de/software/deviceremover > Latest Open-Source Projects: http://entwicklung.junetz.de > ----------------------- > > "m" <m(a)b.c> schrieb im Newsbeitrag > news:O0Drz4DsKHA.4220(a)TK2MSFTNGP05.phx.gbl... >> okay - so obviously you are prepared for the three scenarios that I >> mentioned, and are not concerned about them, so this process termination >> signal is just a shunt into your polling cycle - right? >> >> "Kerem G�mr�kc�" <kareem114(a)hotmail.com> wrote in message >> news:uWwNXz$rKHA.6004(a)TK2MSFTNGP04.phx.gbl... >>> Yes, that true, i am polling, thats >>> exactly what i am doing here, since >>> everything else has no meaning,... >>> >>> Regards >>> >>> K. >>> >>> -- >>> ----------------------- >>> Beste Gr�sse / Best regards / Votre bien devoue >>> Kerem G�mr�kc� >>> Latest Project: http://www.pro-it-education.de/software/deviceremover >>> Latest Open-Source Projects: http://entwicklung.junetz.de >>> ----------------------- >>> >>> "m" <m(a)b.c> schrieb im Newsbeitrag >>> news:eDNTc49rKHA.5356(a)TK2MSFTNGP02.phx.gbl... >>>> Is this a process that you have spawned? I am not sure what you >>>> high-level objective is, but in general this is an inherently >>>> unreliable design since the OS does not expose any UM mechanism to >>>> synchronize with its internal actions and you therefore must poll. >>>> This means that you could find process that don't exist, miss processes >>>> that do exist & miss the entire lifetime of a process. >>>> >>>> "Kerem G�mr�kc�" <kareem114(a)hotmail.com> wrote in message >>>> news:e6PwmS8rKHA.4360(a)TK2MSFTNGP05.phx.gbl... >>>>> Hi rogero, >>>>> >>>>>> Isn't getting a WFSO return all you need >>>>> >>>>> no, unfortunately not. Whenever WFSO >>>>> returns, i have to actualize a internal list >>>>> of running/dead processes and this is the >>>>> problem. When WFSO returns and i assume >>>>> that the process is dead, do a list refresh, >>>>> the process still exists in the OS tables and >>>>> the list is not valid. Doing something like >>>>> Sleep(...) is fine, but not reliable, since this >>>>> depends on the os load at the moment and >>>>> when os is under heavy load, then it possibly >>>>> is not enough time. But i solved it another way >>>>> using a simple "goto". When WFSO returns >>>>> i do make a snapshot and check if the process >>>>> is still listed in. If yes, i just wait for a 500ms >>>>> then try the snapshot again, and if the process >>>>> is still there,....and so on until its not there. Its >>>>> mostly a matter of max 1 sec and everything is >>>>> fine, since its inside a thread (access to the list >>>>> secured by snyc primitves!). Sometimes its 1 >>>>> sec. somtimes even 3, depending on the OS load. >>>>> So i think this is a good solution. If you have a >>>>> better one, please let me know,... >>>>> >>>>> Regards >>>>> >>>>> Kerem >>>>> >>>>> -- >>>>> ----------------------- >>>>> Beste Gr�sse / Best regards / Votre bien devoue >>>>> Kerem G�mr�kc� >>>>> Latest Project: http://www.pro-it-education.de/software/deviceremover >>>>> Latest Open-Source Projects: http://entwicklung.junetz.de >>>>> ----------------------- >>>>> >>>>> "rogero" <roger.orr(a)gmail.com> schrieb im Newsbeitrag >>>>> news:80daf462-7b7e-4d74-bb8b-1a512b97a133(a)k19g2000yqc.googlegroups.com... >>>>>> On Feb 16, 7:04 pm, Kerem G�mr�kc� <kareem...(a)hotmail.com> wrote: >>>>>>> Hi, >>>>>>> >>>>>>> > You've not closed your handle to the process? >>>>>>> >>>>>>> i did but this is not the point. When the process >>>>>>> dies and my WFSO returns and when i wait for >>>>>>> a few seconds (Sleep(...)) inside my thread, then >>>>>>> the snapshot does not contain the process anymore. >>>>>>> Its a matter of synchronization. So the point is: The >>>>>>> process dies, the handle gets signaled, but the OS >>>>>>> still keeps some information of the object in its >>>>>>> structures,...or why does CT32S still return that >>>>>>> information. I dont know why the internall >>>>>>> NtQuerySystemInformation function call (on vista >>>>>>> at least CT32S uses it) still returns that information. >>>>>> >>>>>> Nor do I: it usually seems to skip terminated processes >>>>>> whose EPROCESS entry is waiting until the last handle is closed. >>>>>> (In this state you can still open the process handle, but can't to do >>>>>> much with the returned handle except query the exit code.) >>>>>> >>>>>> Isn't getting a WFSO return all you need >>>>>> >>>>>> Roger. >>>>>
From: Hector Santos on 18 Feb 2010 19:23 You are not testing the result of WFSO? Why? Kerem G�mr�kc� wrote: > Hi, > > yes it is and it looks like this > > <code> > > DWORD dwProcessID = PROCESSID; > > WFSO(HANDLE); > > try_again: > > #If CHECKPROCESSISTH32LISTED(dwProcessID) > SLEEP(500); > goto try_again; > #endif > > //process is no more > > </code> > > It looks similar to this and it works > reliable so far,... > > Regards > > Kerem > -- HLS
First
|
Prev
|
Pages: 1 2 3 Prev: How to get notification when a new process is started Next: VSS Fails on InitializeForBackup. |