>>>>I have a little exe which needs to monitor a certain resource. To make sure it's always on, I run it via task scheduler (so far so good, that works), however just in case it may get stuck, I want to recycle it. So I've set the task scheduler to stop the existing instance if it's already running. That doesn't work.
>>>>
>>>>The exe has practically no GUI, save for a toolbar with an exit button, and it sits in infinite Read Events state. The exit button works fine - deletes the objects, executes a Clear Events and the app exits gracefully.
>>>>
>>>>However, the task scheduler doesn't kill it. I've set it to run a new instance every 5 minutes (just for testing) and sure enough, after half an hour I have 5-6 of them stacked up. Now I guess I should bindevent() to something, just don't know what. I've tried _screen's QueryUnload() - doesn't fire (not even when I click the closebox manually). Tried _screeen.hwnd with wm_close, wm_quit and wm_destroy, doesn't fire.
>>>
>>>Fix your EXE so it doesn't get stuck ;) Only half joking, if you can do that a lot of cruft goes away.
>>
>>It doesn't. But Justin Case is my friend.
>>
>>>Otherwise maybe something like http://www.sevenforums.com/general-discussion/224903-how-close-exit-some-program-using-task-scheduler-windows-7-a.html ?
>>
>>That's more complicated, also what Hugo said - involves more files, more setup.
>>
>>Well, since this is already running on a timer, I'll check seconds() at start and on timer, and if over the specified interval, seppuku.
>>
>>But I'd really want to know which message am I getting from Windows when task scheduler tries to close, and why I can't bind to _screen.queryunload()...
>
>Dunno about seppuku - in general you can't have a watchdog in the process you want to watch. If it sticks, so does the watchdog. For example, if you're using a VFP timer, I understand there are some circumstances where it doesn't fire.

This is all much simpler... at the end of the timer event, I'll simply check for seconds() since start. If too much, quit. That's how watcher watches itself :).

>Alternate approach: Launcher launches mEXE once per minute. mEXE does not hang around, it performs the monitoring action once, then terminates. Probably less chance of getting stuck

This is the approach I was considering for another similar process

>This alternate approach won't be useful if mEXE binds to something and waits for external events.
>
>As for your other shutdown attempts not working:
>
>- Are Task Scheduler and mEXE running in the same context i.e. a logged-in user session?

No, its own login. Same as mine, but runs even if I'm not logged in.

>- Have you set your scheduled task(s) to run with elevated privileges?

No, in each case in production it's run under an account which has the privileges it needs (in this case, full read/write/delete on a folder), While testing, my account which is admin (though I didn't even try to do a "run as admin").

>- Dunno if it would have an effect, but is it possible you've set SYS( 2340 ) to 1 instead of the default 0?

It's one of those which I never needed, never touched.