problem with unhandled exception in Windows application

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi Everybody,

I'e got a problem with one of my Windows applications:

Some times (not very often) the application displays a message box that says

"Application has generated an exception that could not be handled".

The only information provided is the process&thread ID.
It does NOT provide a stack dump or any other information about what or
where this error is (the log in the system event viewer does not give any
more information)

The application catchs unhandled exceptions and writes the exception info to
a log file (I tried, it Works!) but in this case no log file was created.

the only options the message box gives me are to stop the application or to
run a debugger.

Now, this application runs on a client's producation computer so I don't
have any debugger on it.

How can I find out what caused this exception?

Nadav
 
in unhandled exception filter create the log file (it works), or write
the entry in the windows event logger source.
make sure unhandle applicaiton handler is applied on that (or all)
appDomains in a program.
 
I olny have 1 AppDomain in the program, and the Unhandled Exception handler
IS registered for that AppDomain.
 
Hi

For Windows Form application, you may try to handle
Application.ThreadException to catch the Unhandled exception.
SYMPTOMS
========

Unhandled exceptions that occur in Windows Form events are
not propagated up the call stack to a structured exception handler in
the
calling procedure.

CAUSE
=====

The Microsoft .NET Framework wraps the message pump in an
exception handler. The .NET Framework only handles exceptions that
reach the
message pump and that the application has not already handled.
Therefore, any
unhandled exception that reaches the message pump is not propagated up
the call
stack.

324653 PRB: Unhandled Exceptions in Windows Form Events Are Not Propagated
Up
http://support.microsoft.com/?id=324653

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Hi Peter

I do add an event handler to Application.ThreadException.
It does NOT catch this exception.

One thing I want to clarify:
In the link you provided (Unhandled Exceptions in Windows Form Events Are
Not Propagated Up) it says
"This method is then called for any unhandled exceptions that occur on that
thread".
Does this mean that I need to add an event handler to
Application.ThreadException for each thread I create?

Thanks,
Nadav
 
Hi

Windows Application usually has only one thread, that is the main UI thread
which call the Application.Run.
Also Windows Exception worked based on Thread, one exception in certain
thread will not be caught by another thread.
If you have another thread which will have exception, you need to use try
catch in that thread's method.

For detailed information about windows SEH(structure exception handle), you
may refer to the book below.
Programming Applications for Microsoft Windows (Dv-Mps General)
http://www.amazon.com/exec/obidos/tg/detail/-/1572319968/qid=1121843806/sr=1
-3/ref=sr_1_3/102-8538810-4216146?v=glance&s=books

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
 
If the Application.ThreadException event handler is per thread then it should
NOT be a global event,
it should be an property of the Thread
(i.e. it should be used like this:
Thread backgroundThread=new Thread(...);
backGroundThread.ThreadException+=new ThreadExceptionEventHandler(...);
)

The fact that the event IS global makes users think that it IS global, i.e.
that it catchs events from all threads.

I've read the documentation for Application.ThreadException, and it does NOT
say that
that it is PER THREAD. all it says is 'Occurs when an untrapped thread
exception is thrown.'.
This event looks like a normal GLOBAL event, when in fact it is not. The
documentation should be VERY clear about that.

Now I have to go and add this event handler for EVERY thread in the
application
(and I've got quite a lot of them)

Nadav
 
Hi Peter,
I also handle AppDomain.CurrentDomain.UnhandledException.
(I hope this event is per Domain and not per thread...)

Nadav
 
Hi Peter,
Regardless of how to catch unhandled exceptions,
My original question was how do I debug my application when it throws an
unhandled exception so I can FIX it to catch this exception.

Thanks,
Nadav
 
Hi

In Win32 world, all the thread is based on thread. In .NET, we introduce an
AppDomain which is similar with a process, and we have try to handle the
exception based on AppDomain. But
AppDomain.CurrentDomain.UnhandledException will not handle the windows
forms application which will use Application object with the message
pump. We need Application.ThreadException to handle the unhandled exception
from Windows main thread that is the thread that runs Application.Run.

Here is some code snippet for your reference.
private void ThreadProc()
{
throw new Exception("Exception from thread");
}

private void button1_Click(object sender, System.EventArgs e)
{
Thread th = new Thread(new ThreadStart(ThreadProc));
th.Start();
}

private void button2_Click(object sender, System.EventArgs e)
{
throw new Exception("Exception from Windows Form");
}

private void Application_ThreadException(object sender,
System.Threading.ThreadExceptionEventArgs e)
{
MessageBox.Show("handled by Application_ThreadException" +
e.Exception.ToString());
}

private void Form1_Load(object sender, System.EventArgs e)
{
Application.ThreadException+=new
System.Threading.ThreadExceptionEventHandler(Application_ThreadException);
AppDomain.CurrentDomain.UnhandledException+=new
UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);
}

private void CurrentDomain_UnhandledException(object sender,
UnhandledExceptionEventArgs e)
{
MessageBox.Show("handled by CurrentDomain_UnhandledException" +
((Exception)e.ExceptionObject).ToString());
}

If the code above did not handle the Unhandled Exception, I think you may
need to use adplus to create a crash dump for the application on user
machine and then send back to the machine where have the debugger to
analyze.

Here is a link about how to use adplus.
286350 How to use ADPlus to troubleshoot "hangs" and "crashes"
http://support.microsoft.com/?id=286350

BTW: dump analysis is not support by newsgroup, if you have any concern,
please feel free to contact MSPSS.
http://support.microsoft.com

Thanks!


Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
 
'AppDomain.CurrentDomain.Unhand­ledException' is per AppDomain.
AppDomain is not just new!
We have seen in COM all threading apartments. So all threads (and data
- marshalling) inside apartments are held responsible for them on
apartment basis.

To me winforms are not windows (OS) independent architecture of the
dotnet framework.
Windows [win32] GUI requires UI threads (sometimes DIALOG is a worst).

Since in a winform app, underlying is a win32 form (HWND) and it runs
on a separate thread whose parent (thread) be a main thread who created
it by Application.Run()
has its own execution context (not entirely) [and may be not the same
thread apartment (as of parent) might/most probably become in a
separate STA (not new very old thing)]. I think most probably That is
why AppDomain based Unhandled Exception Handler could not capture it.
And (here in dotnet) then comes some exception handler in a message
pump as Peter Huang just told. In that you have to do it the way
mentioned in the http://support.microsoft.com/?id=324653
where you have to do 'Application.ThreadException' in the same Thread!
for which you need to capture it, i 'd guess parent i.e thread creator
cant do it for the newly creating thread. And there is no way (probably
in dotnet) if some exception might occur in NEW()/constructor of the
Object in a new thread before applying this thread exception handler.

In such situations (which mostly occur with console/winformapp/services
unlike asp.net) I (/We people) have to do WIN32 apis direct calls from
within the dotnet and that can only save the day.
(This thing I donot like about the dotnet framework)

Thanks
 
Back
Top