WaitForSingleObject() and Process termination,...
in [Win32 Kernel]
|
From: Kerem Gümrükcü on 17 Feb 2010 06:30 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: m on 17 Feb 2010 09:33 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: Leo Davidson on 17 Feb 2010 11:32 On Feb 17, 11:30 am, Kerem Gümrükcü <kareem...(a)hotmail.com> wrote: > 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 I'm not sure if it will work but have you tried opening a handle to each process in the snapshot and checking if the handle is signalled (via WFSO with a zero timeout)? That seems like it should work, unless you're not allowed to open such handles (but that in itself could be another indicator that the process has stopped).
From: Kerem Gümrükcü on 17 Feb 2010 13:06 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: m on 17 Feb 2010 21:00 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. >>>
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 Prev: How to get notification when a new process is started Next: VSS Fails on InitializeForBackup. |