CLR error on program startup

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Joel Gordon - 23 Jun 2005 05:38 GMT

Hi,

I have developed a .Net application in C#, use Visual Studio 2003 (.Net
framework 1.1).

I am testing that it installs and runs OK on Windows XP (which is what it was
developed under) running under Virtual PC.

It runs fine on developer machines and appears to install fine under Virtual PC
but when we run it we get the error :

Forecaster.exe - Common Language Runtime Debugging Services
Application has generated an exception that could not be handled
Process id=0x168(360), Thread id=0x6f4(1780)
Click OK to terminate the application.
Click Cancel to debug the application.

It doesn't even get to display the splash screen so we are at a loss as to what
is causing it to crash on startup. We have had this error before when a DLL was
missing (which is very unhelpful as unmanaged code gives a good error message
stating that it cannot find a DLL and the paths it has searched).

Can anyone offer any advice on how we might track down the error ?

We are going to try to install Visual Studio and see if the just-in-time
debugger can help us (which I hope will be popped up when we click cancel when
the error message above appears).

Thanks in advance,
Joel Gordon.

Reply to this Message

"Jeffrey Tan[MSFT]" - 23 Jun 2005 09:58 GMT

Hi Joel,

Thanks for your post.

Currently, based on the error message, it is hard to find out the root
cause for the issue. However, it seems that there is unhandled exception
generated in your app.

I suggest you place a debugger in the problem machine, then register it as
the JIT debugger. Then when the unhandled exception generated, we can get
the call stack for your specific issue. And with the call stack, it is
easier for us to catch the problem cause.

Thanks

Best regards,
Jeffrey Tan
Microsoft Online Partner Support

Signature

Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

Reply to this Message

john conwell - 23 Jun 2005 22:35 GMT

Also make sure you are handling AppDomain.UnhandledException and
Application.ThreadException correctly.

> Hi Joel,
>
[quoted text clipped - 16 lines]
> Get Secure! - www.microsoft.com/security
> This posting is provided "as is" with no warranties and confers no rights.

Reply to this Message

Joel Gordon - 23 Jun 2005 23:42 GMT

Hi Jeffrey,

Thanks very much for the reply.

> I suggest you place a debugger in the problem machine, then register it as
> the JIT debugger. Then when the unhandled exception generated, we can get
> the call stack for your specific issue. And with the call stack, it is
> easier for us to catch the problem cause.

We did just that (installed Visual Studio) and you are dead right it was an
unhandled exception and from that it was obvious what the problem was.

On further investigation it looks like the take home message is :

Always have a try/catch block within Main so that no exceptions can be thrown
from Main.

If an exception is thrown out of Main AND you don't have a JIT debugger
registered then you get the very unhelpful message which gives no clues as to
what the exception was. This can be caused by something as simple as not
finding a DLL.

In my opinion this is would be easy very thing for the CLR to do (i.e. have a
try/catch around the main method and display the exception that was thrown).

Hopefully the CLR included with version 2 of the framework will handle
exceptions thrown from Main method !

Thanks again,
Joel.

Reply to this Message

"Jeffrey Tan[MSFT]" - 24 Jun 2005 10:46 GMT

Hi Joel,

Thanks for your feedback.

No, actually CLR has processed unhandled exception in .Net application.

1. For Winform application unhandled exception, in Application class, its
OnThreadException() method will handle it and pop up a customized unhandled
exception dialog. Then you can choose to terminate the app or invoke a JIT
debugger.

2. For Console app, CLR will look up in
HKEY_LOCAL_MACHINE\Software\Microsoft\.NETFramework\DbgJITDebugLaunchSetting
, then invoke the .Net JIT debugger for you. However, if you did not
register a .Net JIT debugger, Win32 OS will take the control, and display a
message box that invites you to:
Click OK to terminate the program
Click CANCEL to debug the program

If you click CANCEL, a debugger is started and attached to the process. The
registry key that controls this is called
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Current Version\AeDebug.

So CLR really takes control before OS. However, it will not do the recovery
for our .Net application defaultly. Why? Because when a unhandled exception
is thrown out, something went wrong, maybe some data is interrupted, and
the applicaiton state is unexpected. If we continue to run, the application
may destroy some important data/resource. So CLR only gives you 2 options:
1. Termiate the Application
2. Allow you to debug, if JIT debbuging is enabled

Actually, in Win32 world, why a OK/Cancel dialog can pop up? Because OS
provided a unhandled exception dialog for us, it uses the same way like
the CLR: give us 2 options termiate or debug.

For more information about unhandled exception handling in .Net, I suggest
you read "Exceptions" chapter of Jeffrey Richter's "Applied Microsoft .Net
Framework Programming". For Win32 OS unhandled exception handling, you can
get some useful information from "Unhandled Exception" chapter of Jeffrey
Richter's "Programming Application for Microsoft Windows".

At last, the below Jason Clark's article shows us how to handle unhandled
exception in .Net world:
"Unexpected Errors in Managed Applications"
http://msdn.microsoft.com/msdnmag/issues/04/06/NET/
====================================================================
Thank you for your patience and cooperation. If you have any questions or
concerns, please feel free to post it in the group. I am standing by to be
of assistance.

Best regards,
Jeffrey Tan
Microsoft Online Partner Support

Signature

Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

Reply to this Message

"Jeffrey Tan[MSFT]" - 28 Jun 2005 08:26 GMT

Hi Joel,

Does my reply make sense to you? If you still have any concern, please feel
free to tell me, thanks

Best regards,
Jeffrey Tan
Microsoft Online Partner Support

Signature

Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

Reply to this Message

Rate this thread:

CLR error on program startup

Free Magazines