I=B4m trying to write a control programm, to monitor an application.
One of the functions of the control program is to frequently check for
the existence of the application and (re-)launch it, in case it isn=B4t
open.

if(!FindWindow("MyApplication",0))
{
....
ShellExecuteEx(...);
}

I=B4m running into a problem, in case the application crashes, where
Windows displays the error message like "This application has caused
an error and must be closed".
In this case my control program cannot relaunch the application, until
I click the OK button below the error message.

Obviously this shouldn=B4t happen in the first place and I will have to
fix the bug in my application, but meanwhile I=B4d like to find a way to
close the crashed application without any mouse or keyboard input.
Either some setting in Windows, or something in the application that
causes the application to silently close in case of crash and prevents
the Windows message from popping up, or something in the control
program, that can detect the crash and close the frozen application
programmatically.

Is there a way to do this?

Piranha schrieb:

> Either some setting in Windows, or something in the application that
> causes the application to silently close in case of crash and prevents
> the Windows message from popping up, or something in the control
> program, that can detect the crash and close the frozen application
> programmatically.

Use Structured Exception Handling (__try/__except) around the entry
function of your program, and call SetErrorMode to disable the message
boxes.

Piranha wrote:
> I´m trying to write a control programm, to monitor an application.
> One of the functions of the control program is to frequently check for
> the existence of the application and (re-)launch it, in case it isn´t
> open.
> 
> if(!FindWindow("MyApplication",0))
> {
> ...
> ShellExecuteEx(...);
> }

Just a note: Using CreateProcess(), you get a handle to the process which
you can conveniently use with WaitForSingleObject().

> I´m running into a problem, in case the application crashes, where
> Windows displays the error message like "This application has caused
> an error and must be closed".
> In this case my control program cannot relaunch the application, until
> I click the OK button below the error message.

If Markus' suggestion doesn't help, I'd try to regularly ping the
application with a special window message, to see if it still responds.

Good luck!

Uli

-- 
Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

On 12 Nov., 15:17, Ulrich Eckhardt <eckha...@satorlaser.com> wrote:
> Piranha wrote:
> > I=B4m trying to write a control programm, to monitor an application.
> > One of the functions of the control program is to frequently check for
> > the existence of the application and (re-)launch it, in case it isn=B4t
> > open.
>
> > if(!FindWindow("MyApplication",0))
> > {
> > ...
> > ShellExecuteEx(...);
> > }
>
> Just a note: Using CreateProcess(), you get a handle to the process which
> you can conveniently use with WaitForSingleObject().
>
> > I=B4m running into a problem, in case the application crashes, where
> > Windows displays the error message like "This application has caused
> > an error and must be closed".
> > In this case my control program cannot relaunch the application, until
> > I click the OK button below the error message.
>
> If Markus' suggestion doesn't help, I'd try to regularly ping the
> application with a special window message, to see if it still responds.
>
> Good luck!
>
> Uli
>
> --
> Sator Laser GmbH
> Gesch=E4ftsf=FChrer: Thorsten F=F6cking, Amtsgericht Hamburg HR B62 932

Thanks for the answers, yet I didn=B4t really get the solution.
A few days ago I had asked about try and catch, there I figured out,
it doesn=B4t catch all possible errors, therefore I can=B4t apply any
Exception Handling, simply because I never get the exception.
For example, I was using memset() in 2 threads simultanous, where
memset() isn=B4t thread safe.
Whenever both threads called memset at same time, the threads would
crash, but the main thread including its message loop would keep
runnning, meaning the crashed thread would cause Windows to popup the
error messagebox, while the main thread didn=B4t throw any exception.

Logic, in this case I could ping the application as often as I like,
since the main thread is still running it might even respond correctly
(not sure if that=B4s always the case), only FindWindow() will fail,
because Windows replaces the applications window with a ghost window
of same content when popping up the error.
Either way, I still don=B4t know, how I could prgramatically close the
Ghost window and terminate the application, even if I detect the
crash.
If the main thread is still responding, I might get a WM_CLOSE
through, but how could I do that without a valid HWND and what if it
is completely frozen?
Windows seems to have a method of terminating a frozen application and
cleanup the system, at least one can click OK in the errror message
and the application closes without I have to restart the PC, but how?

Piranha schrieb:

> Thanks for the answers, yet I didn�t really get the solution.

You'd need to read more attentively.

> A few days ago I had asked about try and catch, there I figured out,
> it doesn�t catch all possible errors, therefore I can�t apply any
> Exception Handling, simply because I never get the exception.

Read about "structured exception handling". It's different from C++
exception handling.

On 12 Nov., 19:53, Markus Schaaf <msch...@elaboris.de> wrote:
> Piranha schrieb:
>
> > Thanks for the answers, yet I didn=B4t really get the solution.
>
> You'd need to read more attentively.
>
> > A few days ago I had asked about try and catch, there I figured out,
> > it doesn=B4t catch all possible errors, therefore I can=B4t apply any
> > Exception Handling, simply because I never get the exception.
>
> Read about "structured exception handling". It's different from C++
> exception handling.

Ahhh, got it, at least I got something to read.
Hopefully I=B4ll understand it.
Thanks.

On Nov 12, 9:08=A0am, Piranha <eu_pira...@gmx.net> wrote:

> For example, I was using memset() in 2 threads simultanous, where
> memset() isn=B4t thread safe.

memset is thread safe.

DS

Piranha wrote:
[..fullquote..]
> Thanks for the answers, yet I didn´t really get the solution.

Which of the two suggestions are you talking of?

> A few days ago I had asked about try and catch, there I figured out,
> it doesn´t catch all possible errors, therefore I can´t apply any
> Exception Handling, simply because I never get the exception.

Two things:
1. As mentioned, there are C++ exceptions and win32 SEH. Note that you
actually can catch SEH exceptions using try/catch, but you must tell the
compiler to do that. I wouldn't do so generally though, because it is not
portable.
2. You have multiple threads, and each thread has its own stack and each
thread on its own can cause exceptions. An unhandled exception will pop up
an error message, created in the context of that thread, but other threads
will at first be unaffected of this. Only after acknowledging the message
box the program is terminated as a whole.

Note also that Markus suggested calling SetErrorMode() in order to disable
the message boxes and directly terminate the program. Did you try that?

> For example, I was using memset() in 2 threads simultanous, where
> memset() isn´t thread safe.

David already mentioned it, typical implementations of memset() are
thread-safe. At least it's not memset() itself which causes problems
between threads. Take care though that some compilers still have a
non-threadsafe runtime library, which you shouldn't use when using multiple
threads.

Uli

-- 
Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

On 15 Nov., 09:43, Ulrich Eckhardt <eckha...@satorlaser.com> wrote:
> Piranha wrote:
>
> [..fullquote..]
>
> > Thanks for the answers, yet I didn=B4t really get the solution.
>
> Which of the two suggestions are you talking of?
>
> > A few days ago I had asked about try and catch, there I figured out,
> > it doesn=B4t catch all possible errors, therefore I can=B4t apply any
> > Exception Handling, simply because I never get the exception.
>
> Two things:
> 1. As mentioned, there are C++ exceptions and win32 SEH. Note that you
> actually can catch SEH exceptions using try/catch, but you must tell the
> compiler to do that. I wouldn't do so generally though, because it is not
> portable.
> 2. You have multiple threads, and each thread has its own stack and each
> thread on its own can cause exceptions. An unhandled exception will pop u=
p
> an error message, created in the context of that thread, but other thread=
s
> will at first be unaffected of this. Only after acknowledging the message
> box the program is terminated as a whole.
>
> Note also that Markus suggested calling SetErrorMode() in order to disabl=
e
> the message boxes and directly terminate the program. Did you try that?
>
> > For example, I was using memset() in 2 threads simultanous, where
> > memset() isn=B4t thread safe.
>
> David already mentioned it, typical implementations of memset() are
> thread-safe. At least it's not memset() itself which causes problems
> between threads. Take care though that some compilers still have a
> non-threadsafe runtime library, which you shouldn't use when using multip=
le
> threads.
>
> Uli
>
> --
> Sator Laser GmbH
> Gesch=E4ftsf=FChrer: Thorsten F=F6cking, Amtsgericht Hamburg HR B62 932

Thanks for the extra info.
I=B4ve put a mutex around memset() and it=B4s working fine for now,
whether the problem originates in memset() itself or a runtime
library, for the moment I=B4m happy with it, maybe my compiler gets an
update by the time my program exceeds version 0.0001 alpha.

SetErrorMode() was a real useful hint, meanwhile I=B4ve managed to
bypass the popup with it.

So all in total I=B4d say thanks to everyone, I apreciate all the help.