Application.ThreadException/Enable JIT debugging

  • Thread starter Thread starter Armin Zingler
  • Start date Start date
A

Armin Zingler

Hi,

I've aleady asked 3 times in the Winforms group but didn't get any answer:


I'm using Framework 1.1/VS 2003 (VB.Net).

I have this code:

Try
dim f as new form1
f.showdialog
catch
'exception handling
end try

I expect that the catch block catches exceptions during the life
time of the dialog. However, it does not. Instead, the default
exception dialog of the Framework is shown. It's the one that
adivces us to enable JIT debugging in the application.exe.config or
machine.config file. Well, I've done this already. Anway, I want my
own catch block (above) handle the exception!

I've tried adding an event handler to the Application.ThreadException
event. It works, that means the handler is called instead of showing
the default exception dialog. But again, that's not what I want! How
can I have the catch block handle the exceptions thrown in the try
block?


Armin
 
I'm using Framework 1.1/VS 2003 (VB.Net).
Click to expand...
I expect that the catch block catches exceptions during the life
time of the dialog. However, it does not.
Click to expand...
How can I have the catch block handle the exceptions thrown in the try
block?
Click to expand...


Could that be a bug in .NET 1.1?

I tried that with .NET 2.0 and it worked as expected. When exception
occurred the code in Catch block was executed.

-Teemu
 
Could that be a bug in .NET 1.1?

I tried that with .NET 2.0 and it worked as expected. When exception
occurred the code in Catch block was executed.

-Teemu
Click to expand...

No... it works when the debugger is attached (f5), but when run with no
debugger (ctrl+f5), then it failes as described. I tried with both 2005 and
2008.
 
No... it works when the debugger is attached (f5), but when run with no
debugger (ctrl+f5), then it failes as described. I tried with both 2005
and
2008.
Click to expand...

That's true. I tried only with debugger attached. Now I got same results
with 2005 and 2008 when I tried again without the debugger.

It seems that it makes no difference if I use Try block or On Error
statement, both ways raise an exception.

It would be nice to know what causes this.

-Teemu
 
That's true. I tried only with debugger attached. Now I got same results
with 2005 and 2008 when I tried again without the debugger.

It seems that it makes no difference if I use Try block or On Error
statement, both ways raise an exception.

It would be nice to know what causes this.

 -Teemu
Click to expand...

You can check out Debug -> Exceptions menu, then expand "CLR
Exceptions" menu to set when a specific exception will be broken by
debugger.

Onur Güzel
 
You can check out Debug -> Exceptions menu, then expand "CLR
Exceptions" menu to set when a specific exception will be broken by
debugger.
Click to expand...

I wonder how this helps? :-)

-Teemu
 
kimiraikkonen said:
You can check out Debug -> Exceptions menu, then expand "CLR
Exceptions" menu to set when a specific exception will be broken by
debugger.
Click to expand...

Does this have an effect if you start the Exe from Explorer?


Armin
 
I wonder how this helps? :-)

 -Teemu
Click to expand...

Not exactly of course, it was just a kind of clue about why
application behaves different when debugger is attached under IDE.

Onur Güzel
 
Does this have an effect if you start the Exe from Explorer?

Armin
Click to expand...

If i tested correctly,
Using .NET 2.0 with VB 2005 Express, like Tom pointed out, if I run
application using "CTRL+F5" which means launching without debugger,
unhandled exception occurs, but with debugger it doesn't(Exception is
handled how you described in Catch block).

Regarding to your quesiton, if i run application from Windows
Explorer, it throws again classic unhandled exception of like it was
launched without debugger.

Thanks,

Onur Güzel
 
That's true. I tried only with debugger attached. Now I got same results
with 2005 and 2008 when I tried again without the debugger.

It seems that it makes no difference if I use Try block or On Error
statement, both ways raise an exception.

It would be nice to know what causes this.
Click to expand...

That is the question :) I know I'm not sure.
 
Try
dim f as new form1
f.showdialog
catch
'exception handling
end try

I expect that the catch block catches exceptions during the life
time of the dialog.
Click to expand...

It's quite interestring that if I do like this:

Try
Dim NewForm As New Form2
NewForm.RaiseError()
Catch ex As Exception
MsgBox("Error occurred")
End Try

Then that message box appears as expected wheter I have the debugger
attached or not. But if I call that same RaiseError function from Form2 then
the result is just like Armin described.

Is it possible that without debugger Form2 runs somehow in different thread
and that's the reason for this odd behavior?

-Teemu
 
Is it possible that without debugger Form2 runs somehow in different
thread and that's the reason for this odd behavior?
Click to expand...

The reason seems to be that Form1 and Form2 have their own message loops and
that causes this problem. Exceptions in Form2 can be handled in
Application_UnhandledException but not directyly in Form1.

-Teemu
 
Teemu said:
This

http://www.mobydisk.com/softdev/techinfo/exceptions_messageloop/index.html

might be the workaround you are looking for.
Click to expand...

I played with that example and this seems to be the simpliest way to
implement it:

Public Class Form1

Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles MyBase.Load
AddHandler Application.ThreadException, AddressOf MYThreadHandler
End Sub

Private Sub MYThreadHandler(ByVal sender As Object, ByVal e As
Threading.ThreadExceptionEventArgs)
Throw e.Exception
End Sub

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
Try
Dim NewForm As New Form2
NewForm.ShowDialog()
Catch ex As Exception
MsgBox("Error occurred!")
End Try
End Sub

End Class

-Teemu
 
Thanks for the link and the code. However, as I wrote in my first posting, I
do not want to handle the Application.ThreadException event. The actual
problem is that setting JitDebugging=True just does not work even though the
default exception dialog pretends this is the solution. I'm not happy with
this because of the workaround I need for this problem.

I posted a bug report to MSFT:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=390547

Also thanks to Tom, Teemu and Onur.


Armin
 
Armin Zingler said:
Thanks for the link and the code. However, as I wrote in my first posting,
I
do not want to handle the Application.ThreadException event. The actual
problem is that setting JitDebugging=True just does not work even though
the
default exception dialog pretends this is the solution. I'm not happy with
this because of the workaround I need for this problem.

I posted a bug report to MSFT:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=390547
Click to expand...

I'm not sure what you are trying to achieve using JitDebugging. If I have
understood it right, it means just that when your application crashes, it'll
open Visual Studio and you can try to debug your program. How is this
related to Try-Catch block and its behavior?

All articles I read about this issue stated that only way to handle errors
from other forms is to catch ThreadException event because forms use
different message loops. It would be nice to handle errors "normally" but
seems to be impossible.

-Teemu
 
Armin Zingler said:
Thanks for the link and the code. However, as I wrote in my first posting,
I
do not want to handle the Application.ThreadException event.
Click to expand...

Oops, I forgot to ask that did you notice that my code really showed the
message box in Catch section and allowed to handle errors normally in
Try-Catch block?

Or do you just want to find a solution that doesn't have any references to
ThreadException although this was quite easy way to use Try-Catch blocks as
you wished?

-Teemu
 
Teemu said:
I'm not sure what you are trying to achieve using JitDebugging. If I
have understood it right, it means just that when your application
crashes, it'll open Visual Studio and you can try to debug your
program. How is this related to Try-Catch block and its behavior?
Click to expand...

I thought jitdebugging=true is there to suppress the default exception
dialog.

I understand what you mean, but unfortunatelly I can not verify what happens
if the jitdebugging setting would work, that means, if no default dialog was
shown: If the debugger is always started, you are right that there is no
relation (as you asked). If it otherwise enables my own code handle the
exception, maybe only if there is no debugger installed, then there is a
relation. But I do not know this because the default dialog always pops up.


Armin
 
Teemu said:
Oops, I forgot to ask that did you notice that my code really showed
the message box in Catch section and allowed to handle errors
normally in Try-Catch block?
Click to expand...

It surely works but with additional efforts. I do not accept that I must
make an exception (from the rule). I have less problems accepting something
if anybody could give an explanation why it _must_ be this way. Currently I
don't see a reason. Do you know where this behavior is documented? I mean
where is a statement that exception handling around ShowDialog is ignored?
(not the documetnation on the ThreadException event)
Or do you just want to find a solution that doesn't have any
references to ThreadException although this was quite easy way to use
Try-Catch blocks as you wished?
Click to expand...

See above.

Now there seem to be two unrelated problems:
- catch around showdialog does not work => I have to live with it and use
application.threadexception instead.
- jitdebugging=true has no effect => bug(?)

I thought they were related: The default exception dialog prevents my own
code catching the error. That doesn't seem to be true.


Armin
 
It surely works but with additional efforts. I do not accept that I must
make an exception (from the rule). I have less problems accepting
something if anybody could give an explanation why it _must_ be this way.
Currently I don't see a reason. Do you know where this behavior is
documented? I mean where is a statement that exception handling around
ShowDialog is ignored? (not the documetnation on the ThreadException
event)
Click to expand...

Here are the most reliable sources I've found:

http://bytes.com/groups/net-vb/386210-exception-handling-difference-between-design-time-run-time
http://msdn.microsoft.com/fi-fi/magazine/cc188720(en-us).aspx
http://support.microsoft.com/?kbid=836674

I thought they were related: The default exception dialog prevents my own
code catching the error. That doesn't seem to be true.
Click to expand...

Yesterday I was sure that there is no relation between these two things but
that KB Article changed my opinion. That article states that the problem
shouldn't exist in VS2005 but it is not true.

I tried to create that app.config file in VB 2008 and I pasted this code in
it:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.windows.forms jitDebugging="true" />
</configuration>

Now that Try-Catch block works as expected without debuggers and events
related to ThreadException. If I change the boolean to False, I get the same
functionality as described yesterday.

-Teemu
 
Back
Top