CLR Exceptions not getting handled in try/catch

[Guest]

I've got a managed application that (on my computer) is not handling managed
exceptions. I've got the following:

try
{
string buf = (null as object).ToString();
}
catch(Exception e)
{
MessageBox.Show(e.Message);
}

When I run the application and perform the UI event that runs the above
code, I get the Microsoft Error Reporting dialog that asks me if I want to
send the information to microsoft. The uncaught exception reporting by the
tool is 0x80000003.

I would expect the Unhandled Exception dialog box to appear letting me
choose to continue or exit. Also, if I put a try/catch around throw new
NullReferenceException(), it works just fine.

Any ideas?

Mike

 

[Guest]

It might be that the code gets optimized, as the value is constant, and
the optimization causes unrunnable code. Try it with a more real situation:

object o = null;
try {
string buf = o.ToString();
} catch(Exception e) {
MessageBox.Show(e.Message);
}

 

[Guest]

Thanks for the reply.

I should have stated that the code snippet I provided was something I had
quickly written to reproduce the issue and to demonstrate what was happening
for this post.

Any other ideas?

 

[Guest]

When I test your code I can't reproduce the problem.

It's hard to guess what the cause might be without seeing the actual
code that has the problem.

 

[Guest]

Thanks again for your reply.

The problem I'm having is something with either my .NET Framework
configuration, or with my computer configuration. The other developers on my
team don't have the problem. I've tried reinstalling/reparing Visual Studio
..NET and that didn't do anything but burn up an hour.

When an exception is thrown by the CLR, what decides how that information is
shown to the user? All of my customers and other developers see the typical
Unhandled Exception dialog that gives them the option of continuing or
exiting. My machine is showing the "Send information to Microsoft" dialog.
What setting on my machine decides which dialog to display? I've compare the
aedebug registry folder and other .NET debug registry folders to another
installation of VS.NET and they are identical.

Mike

 

[Guest]

Have you tried to compile the code on your machine and run it on some
other, or compiled it on some other and run it on your? That would
determine if the code gets compiled differently or if it's just a
difference in how exceptions are handled.

 

[Guest]

Yeah, I put that code snippet on someone else's machine and built it. When I
ran it on their machine, it displayed a message box with the error (as we
would expect, our application caught the exception and displayed our own
message box with the error). When I copied that binary file to my machine and
ran it, I got the "Send to Microsoft" message.

It's got to be an environment issue. I've also tried uninstalling and
reinstalling the .NET Framework 1.1

 

[Oleg Starodumov]

Yeah, I put that code snippet on someone else's machine and built it. When I
ran it on their machine, it displayed a message box with the error (as we
would expect, our application caught the exception and displayed our own
message box with the error). When I copied that binary file to my machine and
ran it, I got the "Send to Microsoft" message.

It's got to be an environment issue. I've also tried uninstalling and
reinstalling the .NET Framework 1.1

It would be helpful to see the native call stack at the moment when
the exception is raised. If you are familiar with WinDbg, you can either
run the application under WinDbg and get the call stack at the moment
when the exception is thrown (using 'kb'), or attach WinDbg to the application
at the moment when error reporting dialog is shown and get the call stack
of the thread that shows the dialog (~*kb will show call stacks of all threads,
then pick the right one). (Or you can use callstacks.bat shown here:
http://www.debuginfo.com/tools/cdbbatch.html
)

If you generate a simple application with the code shown in your first post,
does it exhibit the same behavior?

What are the values of the following settings?

HKLM\Software\Microsoft\.NETFramework
DbgJITDebugLaunchSetting
DbgManagedDebugger

HKLM\Software\Microsoft\Windows NT\CurrentVersion\AeDebug
Debugger
Auto

Also, I assume that it is a WinForms application. Is it true?
Does it use unmanaged components?
Is it multithreaded?
Does it have a .config file with
<system.windows.forms jitDebugging="???" /> ?

Is the application built with debug information (/debug option),
and is it optimized (/optimize option)?

What is the operating system version and SP?
Is .NET 1.1 SP1 installed?

Oleg
http://www.debuginfo.com/

 

[Guest]

Thank you very much for you reply. Here's some more information for you:

Environment:
Windows XP SP2
.NET 1.1 (No SP yet, I just uninstalled and reinstalled the framework,
but the problem was happening with the latest 1.1 framwork)
DbgJITDebugLaunchSetting := 2
DbgManagedDebugger := "C:\Program Files\Common Files\Microsoft
Shared\VS7Debug\vs7jit.exe" PID %d APPDOM %d EXTEXT "%s" EVTHDL %d
It is a WinForms application, that does make a few Windows API calls.
It's not multithreaded and the config file doesn't have the line you
described.

Interesting Points:
I created a new project and put a button on a form that runs the code
snippet and the problem did *NOT* occur! It displayed the message box that I
told it to, rather than the Microsoft one.

Also, when the exception was thrown while running in WinDbg, everything
worked fine. My application handled the exception and displayed the proper
message to the user. No Microsoft dialog.

So, it has something to do with my program settings not using the right
debugger. It works fine with blank project, and works fine when running
inside WinDbg.

Any idea's?

Here's the call stack:

(660.df8): Break instruction exception - code 80000003 (first chance)
eax=00000000 ebx=0036afb0 ecx=7c91eb05 edx=0012eb1e esi=00000000 edi=00000000
eip=7c901230 esp=0012ebd0 ebp=0012ed9c iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
ntdll!DbgBreakPoint:
7c901230 cc int 3
0:000> kb
ChildEBP RetAddr Args to Child
WARNING: Stack unwind information not available. Following frames may be
wrong.
0012ed9c 00366843 0036a528 00000013 00000000 ntdll!DbgBreakPoint
0012edc4 00392139 00000013 00383140 00000000
vrfcore!VfCoreRedirectedStopMessage+0x86
[d:\avrf\x86fre\base\avrf\avrf30\vrfcore\stopredirect.cpp @ 103]
0012edf4 00388f19 00000013 00383140 00000000
vfbasics!VfBasicsStopMessage+0x1c9
[d:\avrf\x86fre\base\avrf\avrf30\providers\basics\basics.cpp @ 1045]
0012ee58 00388658 0012ee80 0012ee80 0012ee88
vfbasics!AVrfpCheckFirstChanceException+0x139
[d:\avrf\x86fre\base\avrf\avrf30\providers\basics\support.c @ 966]
0012ee68 7c942dcf 0012ee80 0012ef18 0012ef18
vfbasics!AVrfpVectoredExceptionHandler+0x18
[d:\avrf\x86fre\base\avrf\avrf30\providers\basics\support.c @ 313]
0012ee88 7c9377da 0012ef18 0012ef34 00000001
ntdll!RtlInitializeSListHead+0x9dbf
0012ef00 7c90eafa 0012ef18 0012ef34 0012ef18 ntdll!LdrAddRefDll+0x1c1
*** WARNING: Unable to verify checksum for
c:\windows\assembly\nativeimages1_v1.1.4322\system.windows.forms\1.0.5000.0__b77a5c561934e089_7ed0a374\system.windows.forms.dll
*** ERROR: Module load completed but symbols could not be loaded for
c:\windows\assembly\nativeimages1_v1.1.4322\system.windows.forms\1.0.5000.0__b77a5c561934e089_7ed0a374\system.windows.forms.dll
0012f250 7b82843f 07297d28 072c7ec0 0729676c
ntdll!KiUserExceptionDispatcher+0xe
0012f280 7b828248 07297ea4 00000003 7b825e81
system_windows_forms_7b810000+0x1843f
0012f2c0 7b825c95 0729676c 7b825b52 00000000
system_windows_forms_7b810000+0x18248
0012f314 7b8234a1 00000000 0729676c 0012f3c4
system_windows_forms_7b810000+0x15c95
0012f374 7b822e4e 7b822e07 7b825a9e 0729676c
system_windows_forms_7b810000+0x134a1
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
C:\WINDOWS\system32\USER32.dll -
0012f408 77d48734 000c04b2 00000018 00000001
system_windows_forms_7b810000+0x12e4e
0012f434 77d48816 0bd66ff6 000c04b2 00000018 USER32!GetDC+0x6d
0012f49c 77d4b89b 00000000 0bd66ff6 000c04b2 USER32!GetDC+0x14f
0012f4d8 77d4b903 0048aad8 0248aa28 00000001 USER32!GetParent+0x16c
0012f530 7b81f22b 00000000 0729676c 000c04b2 USER32!SendMessageW+0x49
0012f57c 7b81f0c6 7b82d6c2 072c4c18 072c487c
system_windows_forms_7b810000+0xf22b
0012f5b8 7b82d47d 072c4748 0729676c 072c4748
system_windows_forms_7b810000+0xf0c6
0012f5e4 7b851a54 072c4748 0729676c 072c4698
system_windows_forms_7b810000+0x1d47d

 

[Oleg Starodumov]

Interesting Points:
I created a new project and put a button on a form that runs the code
snippet and the problem did *NOT* occur! It displayed the message box that I
told it to, rather than the Microsoft one.

Also, when the exception was thrown while running in WinDbg, everything
worked fine. My application handled the exception and displayed the proper
message to the user. No Microsoft dialog.

So, it has something to do with my program settings not using the right
debugger. It works fine with blank project, and works fine when running
inside WinDbg.

Any idea's?

Here's the call stack:
...
0012ed9c 00366843 0036a528 00000013 00000000 ntdll!DbgBreakPoint
0012edc4 00392139 00000013 00383140 00000000
vrfcore!VfCoreRedirectedStopMessage+0x86

Do you have Application Verifier installed?
Is it configured to do something with this application?

Oleg

 

[Guest]

Yes I do! I completely forget that I had left my application to be watched by
it!

Well, I removed my application from the verifier and everything is working
as expected.

Thank you so much for helping me.

BTW, what made you think of that?