WaitForNextEvent() - does not timeout despite the proper flag?   

Hi all,

I have a C# app that uses WMI to launch a process on a remote machine, and 
needs to wait for that process to shut down before moving on.  After I've 
setup a ManagementEventWatcher with the following WQL:

select * from __InstanceDeletionEvent within 1 where TargetInstance ISA 
'Win32_Process'

...I call ManagementEventWatcher.WaitForNextEvent() in an infinite loop.  I 
don't want to wait for an artificially long time, thus the 'within 1'.

Within the loop, I compare the Process ID returned with my own process's ID 
(obtained as the "ProcessID" output parameter of Win32_Process.Create()), 
and break out of the loop if it matches.  If it doesn't match, the loop 
starts again and waits for .WaitForNextEvent() to return (blocking my app). 
For the most part, this works great; with debug messages, I can watch any 
number of (unrelated) processes as they shut down on the remote machine and 
my loop keeps going.

However, here's a strange thing:

If my connection to the remote machine is slow (eg, over VPN, while a large 
download is taking place), then more often than not, it seems like my app 
"misses" the process shutdown notification, and worse, the call to 
.WaitForNextEvent() does NOT timeout as it should--it blocks indefinitely, 
instead of aborting after the timeout value I specified in 
ManagementEventWatcher.Options.Timeout.  I can see that .WaitForNextEvent() 
does unblock whenever a process shuts down; I just never get notified that 
my process *did* shut down (typically my process is pretty quick to run and 
shut down.  I can "artificially" force a timeout within my loop by comparing 
timestamps in each loop iteration, so at least whenever a process shuts down 
on the remote machine, I can abort if I've waited for too long...however, if 
nothing is happening on the remote machine, it can sit there and wait 
forever (or, at least, until something else--unrelated--happens to shut 
down, unblocking the call to .WaitForNextEvent() so I can check timestamps).

I *know* my app gets launched by Win32_Process.Create(); all it does is 
create a small file, which is typically done within a second or two.  If it 
didn't run at all, there's nothing else that could create that file.

I'm starting to think that my process might have launched and shut down 
before my event watcher is setup and starts waiting, but that still doesn't 
explain why, if nothing ever happens to shut down on the remote machine, 
.WaitForNextEvent() doesn't time out.  That's the most important thing, 
because if .WaitForNextEvent() doesn't respect my timeout and can block 
indefinitely, then my only alternative is to start pooling and check running 
processes on the remote machine at given intervals (yuck!).  I also suspect 
I still wouldn't be any better off, as my remote process might have 
launched/shut down already by the time I've obtained the list of running 
processes...thus I'd *still* be waiting for nothing, before I decide to 
timeout...

Looking for the file as an indication that the remote process has shut down 
is not an option--it may take a second or two for it to complete, and don't 
want to make the wrong assumption while the remote process still isn't done 
with it...

Thoughts?

date: Wed, 23 Jul 2008 17:01:56 -0400   author:   Homer J. Simpson

Re: WaitForNextEvent() - does not timeout despite the proper flag?   

Nobody?

What group/forum might be more appropriate?

"Homer J. Simpson"  wrote in message 
news:exRnpdQ7IHA.1428@TK2MSFTNGP06.phx.gbl...
> Hi all,
>
> I have a C# app that uses WMI to launch a process on a remote machine, and 
> needs to wait for that process to shut down before moving on.  After I've 
> setup a ManagementEventWatcher with the following WQL:
>
> select * from __InstanceDeletionEvent within 1 where TargetInstance ISA 
> 'Win32_Process'
>
> ...I call ManagementEventWatcher.WaitForNextEvent() in an infinite loop. 
> I don't want to wait for an artificially long time, thus the 'within 1'.
>
> Within the loop, I compare the Process ID returned with my own process's 
> ID (obtained as the "ProcessID" output parameter of 
> Win32_Process.Create()), and break out of the loop if it matches.  If it 
> doesn't match, the loop starts again and waits for .WaitForNextEvent() to 
> return (blocking my app). For the most part, this works great; with debug 
> messages, I can watch any number of (unrelated) processes as they shut 
> down on the remote machine and my loop keeps going.
>
> However, here's a strange thing:
>
> If my connection to the remote machine is slow (eg, over VPN, while a 
> large download is taking place), then more often than not, it seems like 
> my app "misses" the process shutdown notification, and worse, the call to 
> .WaitForNextEvent() does NOT timeout as it should--it blocks indefinitely, 
> instead of aborting after the timeout value I specified in 
> ManagementEventWatcher.Options.Timeout.  I can see that 
> .WaitForNextEvent() does unblock whenever a process shuts down; I just 
> never get notified that my process *did* shut down (typically my process 
> is pretty quick to run and shut down.  I can "artificially" force a 
> timeout within my loop by comparing timestamps in each loop iteration, so 
> at least whenever a process shuts down on the remote machine, I can abort 
> if I've waited for too long...however, if nothing is happening on the 
> remote machine, it can sit there and wait forever (or, at least, until 
> something else--unrelated--happens to shut down, unblocking the call to 
> .WaitForNextEvent() so I can check timestamps).
>
> I *know* my app gets launched by Win32_Process.Create(); all it does is 
> create a small file, which is typically done within a second or two.  If 
> it didn't run at all, there's nothing else that could create that file.
>
> I'm starting to think that my process might have launched and shut down 
> before my event watcher is setup and starts waiting, but that still 
> doesn't explain why, if nothing ever happens to shut down on the remote 
> machine, .WaitForNextEvent() doesn't time out.  That's the most important 
> thing, because if .WaitForNextEvent() doesn't respect my timeout and can 
> block indefinitely, then my only alternative is to start pooling and check 
> running processes on the remote machine at given intervals (yuck!).  I 
> also suspect I still wouldn't be any better off, as my remote process 
> might have launched/shut down already by the time I've obtained the list 
> of running processes...thus I'd *still* be waiting for nothing, before I 
> decide to timeout...
>
> Looking for the file as an indication that the remote process has shut 
> down is not an option--it may take a second or two for it to complete, and 
> don't want to make the wrong assumption while the remote process still 
> isn't done with it...
>
> Thoughts?
>

date: Thu, 31 Jul 2008 11:25:50 -0400   author:   Homer J. Simpson