Application Not Responding
Kevin Black
I need to detect when my app is not responding, ie. when you get a MYAPP
[Application Not Responding] in the Close Program box. I'm looking at
having a small service application that fires off every few minutes and
checks for app not responding. If this occurs then service app will log the
fact, kill the main app and restart it and send an e-mail message to a
predesignated address.
Something Like:
if MAIN_APP then // Check that
MAIN_APP is running
if MAIN_APP not_responding then // Check to see if it's
responding
begin //
NOT responding
Kill MAIN_APP
Restart MAIN_APP
Log Entry
E-Mail fault details
end
else
begin
// NOT active for some reason
Start MAIN_APP
Log Entry
E-Mail fault details
end
Is there a component or simple API call that I can use to do this.
Note: I know I can setup a messaging link between the two apps and see if I
get a response at reqular intervals, but I really didn't want the main app
to have to do anything to prove it was not only alive, but functioning as
well.
Thanks,
Kevin
Maarten Wiltink
>Hi,
>
>I need to detect when my app is not responding, ie. when you get a MYAPP
>[Application Not Responding] in the Close Program box. I'm looking at
>having a small service application that fires off every few minutes and
>checks for app not responding. If this occurs then service app will log
the
>fact, kill the main app and restart it and send an e-mail message to a
>predesignated address.
<snip>
>Note: I know I can setup a messaging link between the two apps and see if
I
>get a response at reqular intervals, but I really didn't want the main app
>to have to do anything to prove it was not only alive, but functioning as
>well.
And yet, I think this is what you have to do. Consider: the only
thing you _can_ notice when a program is "not responding" is that
it does not answer your messages. So you'll have to send (post,
really) those and see if you get an answer. Then when you _don't_
get it, you can assume the program hangs.
Probing a program without looking at it is like estimating colour
with your eyes closed. You can't see if you don't look.
Groetjes,
Maarten Wiltink
Kevin Black
That's not quite what I meant. I was thinking along the lines that the
operating system can figure out that an app is 'not responding' so there
must be a call (you would think) to access this data??? Again I'm happy to
post a message and have the app respond with a post back, but if the info
has already been generated or is available and my little service app can
access this info there's no reason for the main app to become (conciously)
involved.
Now if the info is dynamic, ie. the windows system call actually
interrogates the app waiting for some sort of response, then I've got to
assume that every winapp has an in-built responder of some sort, which I
suspect is unlikely??
Regards,
Kevin
Maarten Wiltink <mwilt...@hccnet.nl> wrote in message
news:9gn8on$7ii$1...@news1.xs4all.nl...
Maarten Wiltink
>Maarten,
>
>That's not quite what I meant. I was thinking along the lines that the
>operating system can figure out that an app is 'not responding' so there
>must be a call (you would think) to access this data??? Again I'm happy
to
>post a message and have the app respond with a post back, but if the info
>has already been generated or is available and my little service app can
>access this info there's no reason for the main app to become (conciously)
>involved.
I doubt that such a call exists.
>Now if the info is dynamic, ie. the windows system call actually
>interrogates the app waiting for some sort of response, then I've got to
>assume that every winapp has an in-built responder of some sort, which I
>suspect is unlikely??
It is called the windows procedure. Please tell me you do
know about window procedures.
Groetjes,
Maarten Wiltink
Sterling Bates
Essentially the OS could do it two ways: first is to probe the apps message
queue on each time slice. If the messages go through, it thinks it's alive.
The other way is to send it a message and wait for it to come back (just as
you described earlier). I imagine they both accomplish the same thing, and
it's probably easier to code the latter. If you look in the WinAPI helps
under messaging you'll find a SendMessageTimeout function that you could
use.
There is no "not_responding" application status per se.
Sterling
"Kevin Black" <kevin...@megabit.com.au> wrote in message
news:3b2f...@news.iprimus.com.au...
Kevin Black
Thanks, and I've already used the API functionality to send and receive
messages between apps. I was just trying to cut the main apps workload
(it's busy acquiring and compressing images so it's pretty busy). Since the
app is security focussed and generally unattended, I need to know if it goes
splat so that remedial action can be taken hence the query.
Regards,
Kevin
Sterling Bates <no...@nowhere.com> wrote in message
news:9gr3o2$khe$1...@news3.cadvision.com...
Maarten Wiltink
>Sterling,
>
>Thanks, and I've already used the API functionality to send and receive
>messages between apps. I was just trying to cut the main apps workload
>(it's busy acquiring and compressing images so it's pretty busy). Since
the
>app is security focussed and generally unattended, I need to know if it
goes
>splat so that remedial action can be taken hence the query.
The main application would just have to respond to a single
message every once in a while. Not much work really.
Realistically, if the acquisition/compression is enough work
that you need to worry about it crashing, it sounds like it's
at least several hours of computation. Probing it with a single
message every ten seconds or so is completely negligible.
Groetjes,
Maarten Wiltink
Kevin Black
> Realistically, if the acquisition/compression is enough work
> that you need to worry about it crashing, it sounds like it's
> at least several hours of computation. Probing it with a single
> message every ten seconds or so is completely negligible.
You miss the point, the system is acquiring, compressing and storing a
single large image, it is acquiring, compressing and storing images from 9
cameras through our proprietary board (it's a security system). We do not
(as yet) have hardware compression built into the board. It is continuously
cycling from camera to camera at a frame rate of abou six 384x256 24bit
colour images per second with one camera (permanent duty cycle, separate
daughter board) capturing AVI (incl sound) at about 12 frames/sec. This
ensures that the system is fully occupied all the time. Every interruption
to this intense duty cycle is significant and we'd like to keep it to a
minimum.
If the system crashes or if the application locks up we need to know, it
means that 9 cameras have stopped acquiring images. In a service station
(gas station for those of US descent) we have the AVI camera over the point
of sale and the other 8 cameras monitoring pumps, rest room entrances etc
etc. If there's an incident/robbery and our system is dead (and we didn't
know about it, big trouble in little china).......
And, sure we could have image acquisition based on alarm activation (we have
software motion detect and 8 dry contact alarm inputs to the board), but our
customers want continuous monitoring and recording.
Regards,
Kevin
Kevin Black
compressing and storing a single large image.......
Kevin Black <kevin...@megabit.com.au> wrote in message
news:3b37...@news.iprimus.com.au...
Bruce Roberts
"Kevin Black" <kevin...@megabit.com.au> wrote in message
ISTM that it would make more sense to have the capturing software post "I'm
up" messages at appropriate times in their processing. The monitor then just
has to run timers for each of the captures that are active, resetting the
interval whenever a message is received.
Maarten Wiltink
>Maarten,
>
>> Realistically, if the acquisition/compression is enough work
>> that you need to worry about it crashing, it sounds like it's
>> at least several hours of computation. Probing it with a single
>> message every ten seconds or so is completely negligible.
>
>You miss the point, the system is acquiring, compressing and storing a
>single large image, it is acquiring, compressing and storing images from
9
>cameras through our proprietary board (it's a security system). We do not
>(as yet) have hardware compression built into the board. It is
continuously
>cycling from camera to camera at a frame rate of abou six 384x256 24bit
>colour images per second with one camera (permanent duty cycle, separate
>daughter board) capturing AVI (incl sound) at about 12 frames/sec. This
>ensures that the system is fully occupied all the time. Every
interruption
>to this intense duty cycle is significant and we'd like to keep it to a
>minimum.
OK, I had assumed it was an off-line system. But it's not, and
that changes things. I would suggest integrating crash detection
into the board. Also, if you can't currently spare _any_ cycles,
you really should put a slightly faster CPU in there. Why is
this thing running Windows anyway?
>If the system crashes or if the application locks up we need to know, it
>means that 9 cameras have stopped acquiring images. In a service station
>(gas station for those of US descent) we have the AVI camera over the
point
>of sale and the other 8 cameras monitoring pumps, rest room entrances etc
>etc. If there's an incident/robbery and our system is dead (and we didn't
>know about it, big trouble in little china).......
>
>And, sure we could have image acquisition based on alarm activation (we
have
>software motion detect and 8 dry contact alarm inputs to the board), but
our
>customers want continuous monitoring and recording.
All this just means one thin: Think Embedded.
And since I don't, I'll shut up now. (-:
Groetjes,
Maarten Wiltink
Kevin Black
> this thing running Windows anyway?
History, paradigm change and development under Linux started. You are not
the first to ask this question:)
> All this just means one thin: Think Embedded.
> And since I don't, I'll shut up now. (-:
We have looked at the RTXX type OS and it would probably be a good thing,
but the initial costs were prohibitive (for our shoe-string budget anyway)
so Linux looks the go. We know of one system built with our image capture
boards used in 'in-vehicle' surveilance where a cut down Linux kernel was
used.
Thanks,
Kevin