473,320 Members | 1,914 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

Unhandled Exception within a try catch

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.

Nov 25 '05 #1
5 3358
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...

--
Rainier van Slingerlandt
(Freelance trainer/consultant/developer)
www.slingerlandt.com
"Simon Tamman {Uchiha Jax}" wrote:
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.

Nov 25 '05 #2
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/is...0/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}"
<i_**********************************@NOSPAMhotmai l.com> wrote in message
news:oe****************@newsfe7-gui.ntli.net...
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.

Nov 25 '05 #3
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}"
<i_**********************************@NOSPAMhotmai l.com> wrote in message
news:oe****************@newsfe7-gui.ntli.net...
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.

Nov 25 '05 #4
> 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.

Nov 25 '05 #5
Simon Tamman {Uchiha Jax}
<i_**********************************@NOSPAMhotmai l.com> wrote:

<snip>
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 :)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Nov 25 '05 #6

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

4
by: Craig831 | last post by:
First off, I apologize if this gets long. I'm simply trying to give you all enough information to help me out. I'm writing (almost finished, actually), my first VB.Net application. It's a forms...
4
by: Frank | last post by:
Hi, I made a handler for unhandled errors. But before that is executed, VB.NET gives me the standard error window. In VB6 there was a setting (errortrapping) about handling errors in the design...
5
by: Lucvdv | last post by:
Can someone explain why this code pops up a messagebox saying the ThreadAbortException wasn't handled? The first exception is reported only in the debug pane, as expected. The second (caused by...
5
by: mattiassich | last post by:
The following code causes unhandled exception on the line: New ManagementObjectSearcher(query) Dim mos As System.Management.ManagementObjectSearcher Dim moc As...
5
by: Samuel R. Neff | last post by:
When you have an unhandled exception in vb.net how do you view the exception information in the debugger? In C# the debugger creates a local variable that points to the exception and you can...
0
by: Colmeister | last post by:
I recently read Jason Clark's excellent article on Unhandled Exceptions (http://msdn.microsoft.com/msdnmag/issues/04/06/NET/default.aspx) and have attempted to incorporate the features he talks...
3
by: Nick | last post by:
Hi there, This probably wont make much sense but I'm getting an unhandled exception being thrown in the following line... Try While True Redraw control as necessary End While Catch ex as...
15
by: Mark Lewis | last post by:
I have a weird error trapping problem. When running the IDE everything works fine but not when running in an EXE I get the Unhandled Exception Error message box intead of the one in my Try....Catch...
4
by: Vlad | last post by:
I am having problems using the file.create method within a function that is called when looping through an array of filepaths. If I call my function with a hardcoded file path --C:\Temp.txt the...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.