Unhandled Exception in Form Load in EXE but not in IDE

[Mark Lewis]

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 Block.

To see this create a simple application with two forms. Form 1 should have
one button. The code is follows. Run this in the IDE and observe the error
and then compare that behavior to what happens when you run the built EXE.

Has anyone seen this?

Thanks,

Mark

===============================================

Public Class Form1

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click

Dim f As New Form2
Try

f.Show()

Catch ex As Exception

MessageBox.Show(ex.Message)
f.Dispose()

End Try
End Sub
End Class
Public Class Form2

Private Sub Form2_Load(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles MyBase.Load

Throw New ApplicationException("error thrown in form2 load")

End Sub

End Class

[Walter Wang [MSFT]]

Hi Mark,

First, the fix to this issue is one of following options:
1) Create an application config file "app.config" for your project and edit:

<configuration>
<system.windows.forms jitDebugging="true" />
</configuration>

You need to release this <yourapp>.exe.config file with your main app to
your user.

2) If your purpose of installing your own exception handler is to show the
exception, you don't have to. By default, WinForm has a built-in global
exception handler which will catch the exception and show the default
exception dialog. You can also customize this dialog:
http://samples.gotdotnet.com/quickst...FormsAppErrorH
andler.aspx

To understand the background of this issue, read along.

======

The built-in exception dialog is shown because the message pump exception
handler is working.

If you use Reflector to see the disassembled code of
System.Windows.Forms.NativeWindow, you will see two private methods
"Callback" and "DebuggableCallback". In "Callback", we wrap the message
pump in an exception handler so that unhandled exception that gets as far
as the message pump does not actually unwind the message pump causing the
app to crash.

When an application is run in the debugger, we don't catch exceptions in
NativeWindow.DebuggableCallback because we typically want the JIT debugger
to stop the app.

We believe that the behavior we have now represents the best possible ease
of use combined with flexibility -- if you do nothing your app won't crash
if you don't handle an exception, you can customize the dialog that gets
shown and you can turn off the behavior completely.

======

Hope this helps. Please feel free to post here if anything is unclear.

Sincerely,
Walter Wang (wa****@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

[Mark Lewis]

Thanks.

The App.config change fixed this. It would seem to be more of a bug than a
feature to me<g>.... that was with my old VB6 hat on..... I had found an
MSKB article that mentioned this but it
http://support.microsoft.com/?kbid=836674

Indicates that 2005 behaved differently. Perhaps that article should be
corrected to indicate the issue is with both 2003 and 2005.

By the way, is there any disadvantages of adding this JIT line to the config
in terms of security or performance?

Thanks again,

Mark
"Walter Wang [MSFT]" <wa****@online.microsoft.comwrote in message
news:ra**************@TK2MSFTNGXA01.phx.gbl...

Hi Mark,

First, the fix to this issue is one of following options:
1) Create an application config file "app.config" for your project and
edit:

<configuration>
<system.windows.forms jitDebugging="true" />
</configuration>

You need to release this <yourapp>.exe.config file with your main app to
your user.

2) If your purpose of installing your own exception handler is to show the
exception, you don't have to. By default, WinForm has a built-in global
exception handler which will catch the exception and show the default
exception dialog. You can also customize this dialog:
http://samples.gotdotnet.com/quickst...FormsAppErrorH
andler.aspx

To understand the background of this issue, read along.

======

The built-in exception dialog is shown because the message pump exception
handler is working.

If you use Reflector to see the disassembled code of
System.Windows.Forms.NativeWindow, you will see two private methods
"Callback" and "DebuggableCallback". In "Callback", we wrap the message
pump in an exception handler so that unhandled exception that gets as far
as the message pump does not actually unwind the message pump causing the
app to crash.

When an application is run in the debugger, we don't catch exceptions in
NativeWindow.DebuggableCallback because we typically want the JIT debugger
to stop the app.

We believe that the behavior we have now represents the best possible ease
of use combined with flexibility -- if you do nothing your app won't crash
if you don't handle an exception, you can customize the dialog that gets
shown and you can turn off the behavior completely.

======

Hope this helps. Please feel free to post here if anything is unclear.

Sincerely,
Walter Wang (wa****@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
==================================================

This posting is provided "AS IS" with no warranties, and confers no
rights.

[Mark Lewis]

Actually it did not fix the problem. My error in testing. Using the small
program mentioned below I added an app.config with these contents:

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

The application behaves the same way with or without this line. I have
attached the source if that is of any help.

Any other ideas?

Thanks,

Mark

"Mark Lewis" <md*****@newsgroups.nospamwrote in message
news:Oq**************@TK2MSFTNGP04.phx.gbl...

Thanks.

The App.config change fixed this. It would seem to be more of a bug than a
feature to me<g>.... that was with my old VB6 hat on..... I had found an
MSKB article that mentioned this but it
http://support.microsoft.com/?kbid=836674

Indicates that 2005 behaved differently. Perhaps that article should be
corrected to indicate the issue is with both 2003 and 2005.

By the way, is there any disadvantages of adding this JIT line to the
config
in terms of security or performance?

Thanks again,

Mark
"Walter Wang [MSFT]" <wa****@online.microsoft.comwrote in message
news:ra**************@TK2MSFTNGXA01.phx.gbl...

>Hi Mark,

First, the fix to this issue is one of following options:
1) Create an application config file "app.config" for your project and
edit:

<configuration>
<system.windows.forms jitDebugging="true" />
</configuration>

You need to release this <yourapp>.exe.config file with your main app
to
your user.

2) If your purpose of installing your own exception handler is to show
the
exception, you don't have to. By default, WinForm has a built-in global
exception handler which will catch the exception and show the default
exception dialog. You can also customize this dialog:
http://samples.gotdotnet.com/quickst...FormsAppErrorH
andler.aspx

To understand the background of this issue, read along.

======

The built-in exception dialog is shown because the message pump exception
handler is working.

If you use Reflector to see the disassembled code of
System.Windows.Forms.NativeWindow, you will see two private methods
"Callback" and "DebuggableCallback". In "Callback", we wrap the message
pump in an exception handler so that unhandled exception that gets as far
as the message pump does not actually unwind the message pump causing the
app to crash.

When an application is run in the debugger, we don't catch exceptions in
NativeWindow.DebuggableCallback because we typically want the JIT
debugger
to stop the app.

We believe that the behavior we have now represents the best possible
ease
of use combined with flexibility -- if you do nothing your app won't
crash
if you don't handle an exception, you can customize the dialog that gets
shown and you can turn off the behavior completely.

======

Hope this helps. Please feel free to post here if anything is unclear.

Sincerely,
Walter Wang (wa****@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

================================================= =
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent
issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each
follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
================================================= =

This posting is provided "AS IS" with no warranties, and confers no
rights.

[Walter Wang [MSFT]]

Hi Mark,

Thank you for your quick update.

App.config is added to your project, during runtime, it should have been
copied as <yourapp>.exe.config, which the compiler should do that for you.
So, you need to make sure the config file is renamed as
<yourapp>.exe.config and put to the same directory as <yourapp>.exe.

As for the KB, thank you for pointing out that it should state it applies
to Visual Studio 2005 too.

Regards,
Walter Wang (wa****@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

[Walter Wang [MSFT]]

Hi Mark,

How's my suggestion in my previous reply? Please feel free to post here if
anything is unclear.

Regards,
Walter Wang (wa****@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

[Mark Lewis]

Thanks, it was clear. Sorry about my dealy getting back to you but I was
away for a few days.

I tried a config, properly named, with

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

It didn't make any difference on my machine or on two others we have tried.
Also tried removing the config and putting in a False instead of a True.

Mark
"Walter Wang [MSFT]" <wa****@online.microsoft.comwrote in message
news:fp**************@TK2MSFTNGXA01.phx.gbl...

Hi Mark,

How's my suggestion in my previous reply? Please feel free to post here if
anything is unclear.

Regards,
Walter Wang (wa****@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no
rights.

[Mark Lewis]

One more thing. The config entry does fix the problem for EXE's built with
the default DEBUG options. It did not work, as I note below, for me when I
built a RELEASE Exe using the default options. Perhaps there is some
compiler option to set to work around this.

Thanks again for your help.

Mark

"Mark Lewis" <md*****@newsgroups.nospamwrote in message
news:el**************@TK2MSFTNGP02.phx.gbl...

Thanks, it was clear. Sorry about my dealy getting back to you but I was
away for a few days.

I tried a config, properly named, with

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

It didn't make any difference on my machine or on two others we have
tried. Also tried removing the config and putting in a False instead of a
True.

Mark
"Walter Wang [MSFT]" <wa****@online.microsoft.comwrote in message
news:fp**************@TK2MSFTNGXA01.phx.gbl...

>Hi Mark,

How's my suggestion in my previous reply? Please feel free to post here
if
anything is unclear.

Regards,
Walter Wang (wa****@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

================================================= =
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
================================================= =

This posting is provided "AS IS" with no warranties, and confers no
rights.

[Walter Wang [MSFT]]

Hi Mark,

Have you got time to test the project I attached in my previous reply?
Please feel free to post here if you still have problem in Release mode.

Regards,
Walter Wang (wa****@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

[Mark Lewis]

Walter,

Thanks. I have just tested that. I do see that your Button 1 works when the
Advanced Compile Time option is set to generate a PDB and the JIT line is
set in the config. If I turn off the generation of the PDB in release, as I
had in my project, then your project also fails on Button 1.

Naturally removing the JIT setting also causes your Release project to fail.

So to summarize.

1. the error is always trapped in the IDE
2. Builds either in Debug or Release mode that have the JIT setting and
build PDB files trap the error in the same manner as the IDE.
3. Builds in Release mode without PDB generation and the JIT setting do not
trap the error.
4. If I build in Release mode with JIT and tell the app to generate the
PDB..then delete it...the app does trap the error.

I would not want to ship my release with a PDB file but we might consider
shipping without one - Option 4 above.

A bit of a mystery.

Mark

"Walter Wang [MSFT]" <wa****@online.microsoft.comwrote in message
news:wO**************@TK2MSFTNGXA01.phx.gbl...

Hi Mark,

Have you got time to test the project I attached in my previous reply?
Please feel free to post here if you still have problem in Release mode.

Regards,
Walter Wang (wa****@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no
rights.

[Walter Wang [MSFT]]

Hi Mark,

Thank you for sharing your findings with the community.

Regards,
Walter Wang (wa****@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

[Mark Lewis]

Would you think this is a bug in the EXE or in the IDE. It would be best if
the two would work the same.

Mark

"Walter Wang [MSFT]" <wa****@online.microsoft.comwrote in message
news:uF**************@TK2MSFTNGXA01.phx.gbl...

Hi Mark,

Thank you for sharing your findings with the community.

Regards,
Walter Wang (wa****@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no
rights.

[Yan-Hong Huang[MSFT]]

Hello Mark,

Walter is taking leave this week. Is it OK for us to work with you next
week for it if this is not urgent?

Based on my experience, if we can get a repro sample, we can definitely
forward that to our product team for further analysis. This may need some
more time. But please rest assured that we will do our best to work with
you.

Surely you can also talk to our development directly and report it. Please
use the following web link:
http://connect.microsoft.com/site/si...spx?SiteID=210

If you feel there is any we can do, please feel free to reply here and we
will follow up.

Thanks very much.

Sincerely,
Yanhong Huang
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

[Walter Wang [MSFT]]

Hi Mark,

Sorry for late reply. I will do more research on your question and get back
to you as soon as possible. Thank you for your patience and understanding.
Regards,
Walter Wang (wa****@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

[Walter Wang [MSFT]]

Hi Mark,

If you set the "Debug Info" from "pdbonly" to "none", a required
DebuggableAttribute is not emitted in the result assembly. Internally the
framework checks this attribute to determine whether or not to use the
DebuggableCallback instead of the normal Callback.

By default, a Release configuration has setting "pdbonly", it will only
emit some attribute in the assembly; you don't need to release the .pdb
file.

So the answer to your last question about whether or not it's a bug in IDE
is: it's not a bug in IDE. As I wrote in my first reply, this should still
be considered as by design.

Back to initial requirement, if your desire is to report the exception with
your own dialog, I think customizing the built-in exception dialog is the
way to go. You also don't need to put many try-catch block in your code.
Remember, this issue only applies to the event triggered by NativeWindow
(WndProc callback), normal program exceptions are not effected.
Regards,
Walter Wang (wa****@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

[Mark Lewis]

Thanks. As I said, I believe this is a bug as errors that are trapped in the
IDE by the normal Try-Catch syntax are not caught in an EXE unless the JIT
switch is set and a PDB is generated. The product should behave consistently
one way or the other. If this is by design then it is a silly design but I
suspect that this was never thought through carefully so is not by design.

It does appear that a custom error handler is the only way to trap these
sort of errors. Hopefully this will be fixed/redesigned in a later release.

I think you can close this one out as there does not seem to be any Hotfix
and there is a work around.

Thanks again,

Mark
"Walter Wang [MSFT]" <wa****@online.microsoft.comwrote in message
news:HK**************@TK2MSFTNGXA01.phx.gbl...

Hi Mark,

If you set the "Debug Info" from "pdbonly" to "none", a required
DebuggableAttribute is not emitted in the result assembly. Internally the
framework checks this attribute to determine whether or not to use the
DebuggableCallback instead of the normal Callback.

By default, a Release configuration has setting "pdbonly", it will only
emit some attribute in the assembly; you don't need to release the .pdb
file.

So the answer to your last question about whether or not it's a bug in IDE
is: it's not a bug in IDE. As I wrote in my first reply, this should still
be considered as by design.

Back to initial requirement, if your desire is to report the exception
with
your own dialog, I think customizing the built-in exception dialog is the
way to go. You also don't need to put many try-catch block in your code.
Remember, this issue only applies to the event triggered by NativeWindow
(WndProc callback), normal program exceptions are not effected.
Regards,
Walter Wang (wa****@online.microsoft.com, remove 'online.')
Microsoft Online Community Support

==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================

This posting is provided "AS IS" with no warranties, and confers no
rights.