Unhandled Exception within a try catch

[Simon Tamman {Uchiha Jax}]

Now this is bugging me.
I just released software for a client and they have reported an unhandled
stack overflow exception.

My first concern is that the entirity of the UI and any threaded operations
are all within Try Catches to help me locate the problem and the origination
of any problem by specifiying an error code in the "Catch" section.
So theoretically this shouldn't have been possible (at which point we all
say "yeah, right...."(in a sarcastic manner)). However.......

I get the data files from the client and try to run those files in my
install (from an .msi) of the application. I get the same unhandled
exception.
However when I then run the program within Visual Studio (which has not been
changed since the .msi was produced) I don't get an unhandled error. I get
my error code instead!

The call originates in a seperate thread, this thread fires an event which a
form has subscribed to. The form eventhandler calls the data object which is
stored within a .dll and initiates the process that causes the exception.
The method in the seperate thread where the event is fired is Try Catched,
the method in the form that utilises the data object is Try Catched. The
method within the data object itself is NOT Try-Catched.

Is it the case that VS studio is hiding the true results of such an
exception? If a thread executes a method in a .dll and the .dll method calls
throws an exception will that not be caught by a Try Catch in the
originating method?

Please advise, as this confuses the hell out of me.

 

[Guest]

In Visual Studio (Tools -> Options -> Debugging -> Inbreak mode, only stop
execution of the current process)

This check box makes me feel like Visual Studio stops all running processes
by default.
And so It handles the exceptions differently than the released version.
It is just a guess ofcourse...

 

[Stoitcho Goutsev \(100\) [C# MVP]]

Simon,

I don't have an answer for your question, but I want you to consider that
there is one special group of exception - OutOfMemoryException,
StackOverflowException and ExceutionEnglineException that should be treated
in a special way. What makes them unique is that they are not thrown by
framework's or users code, but rather from the CLR itself when something
goes wrong and the state of the runtime engine is not stable.



Depending on the circumstances when one of these is thrown, it might be even
not possible to catch it. Even more it is most likely that when such
exception is thrown the *finally* blocks in the code (if any) are not going
to execute. This is because, for example in a case of stack overflow, in
order to prepare and throw the exception as well as for the code to catch
and recover from it more stack space could be required. CLR may find
possible to discover stack overflow situations before it runs out of stack
memory and in this case it will throw an exception that can be caught. If
the guard page for the stack gets overridden. that's it, the CLR throws an
exception and terminates the application and no handlers are executed.

Because of this even if the code caches such exception the code should never
try to recover from it. It should log the exception and terminate the
application.



The only sure thing that can be used to catch stack overflow is to install
Windows SEH handler. Since v2.0 .NET framework provides a class that can be
used to install such cases - RuntimeHelpers.

For more info I'd suggest reading the following article.



http://msdn.microsoft.com/msdnmag/issues/05/10/Reliability/



Why you can handle the exception in your machine, but on the client machine
it shows up as unhandled I guess it is because of different runtime
environments. For example you may have more memory installed that the user.
It is just a wild guess though.




HTH

Stoitcho Goutsev (100) [C# MVP]



"Simon Tamman {Uchiha Jax}"

 

[Simon Tamman {Uchiha Jax}]

Oh yes, stupidity is as always the answer.

If an exception happens write it in the error log.---------------

void WriteError(Exception ex, string errorCode)
{
CheckFileSize(Constants.ErrorLog);
WriteToLog(ex, errorCode);
MessageBox.Show(errorCode);
}

CheckFileSize(string path)
{
try
{
FileInfo fi = new FileInfo(path);
if(fi.Length>0)
{
int kb = fi.Length/1024;
if(bk>1024)
{
fi.Delete();
}
}
}
catch(Exception ex)
{
WriteError();
}
}

Instant StackOverFlow because I didn't check to see if the fileInfo exists
(hence if it doesn't it throws an exception which makes it checkagain and
round and round).
Now that's stupid.

This error didn't occur on my machine because the log was already there. On
a client machine it hadn't been created yet.
Thanks for your help and sorry for wasting your time with my foolishness. I
at least hope you got a giggle out of it.


"Simon Tamman {Uchiha Jax}"

 

[Bruce Wood]

I get the data files from the client and try to run those files in my

install (from an .msi) of the application. I get the same unhandled
exception.
However when I then run the program within Visual Studio (which has not been
changed since the .msi was produced) I don't get an unhandled error. I get
my error code instead!

I don't remembre the gory details, but the upshot is that calls /
events within a WinForms app are handled differently under the debugger
than when running directly under Windows.

When you run the app under the debugger, all calls to event delegates
proceed as you would expect: the event is raised and the event handlers
are called one by one directly from the point at which the event is
raised.

Under Windows, under some circumstances that I can't recall, certain
events cause a return to the Windows message loop, which then calls the
event delegates directly. (Or something like that... I'm probably
making a mess of this explanation.)

The bottom line is that when you run your WinForms application directly
rather than under the debugger, you will notice on your stack dumps
that methods that you thought were being called from events in your
code are in fact being called directly from the O/S. So, when the
method in question bombs, the try...catch in your own code doesn't
catch the exception because the call isn't being made from your code,
it's being made directly from Windows.

The only way to catch these exceptions is by subscribing to
AppDomain.UnhandledException and Application.ThreadException events.

 

[Jon Skeet [C# MVP]]

Simon Tamman {Uchiha Jax}

Thanks for your help and sorry for wasting your time with my foolishness. I
at least hope you got a giggle out of it.

It's never a waste of time when an explanation is presented afterwards.
Someone may well have a similar problem, find your post, and get an
idea of where to go.

It's *much* better than the "It's all right, I've fixed it" posts we
sometimes get which don't say anything about what was wrong.

So thanks, and best of luck with the rest of the project