Different exception handling behavior when running application in standalone mode instead of from visual studio

[Dan Neely]

I have a try/catch block in the main method of my app that's designed to handle any fatal exceptions and shut the program down with a useful error message. If I run my program in visual studio it functions as designed, but if started directly the framework catches it and shows the unhandled exception dialog with details, continue, and quit. The code below demostrates the problem.

	static void Main() 
	{
		try
		{
			Application.Run(new Form1());
		}
		catch (System.Exception e)
		{
			MessageBox.Show(e.Message);
		}
	}

	private void button1\_Click(object sender, System.EventArgs e)
	{
		throw new System.Exception("test");
	}

[Drew McGhie]

So what is the error you get when you run it from outside the framework?

[Dan Neely]

Instead of getting a messagebox with "test". I get the framework exception catcher.

An unhandled exception has occured in your application. If you click
continue, the application will ignore this error and attempt to continue.
If you click quit, the application with be shut down immediately.

test.

details contains the following:

See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.Exception: test
at Exception.Form1.button1_Click(Object sender, EventArgs e) in c:\documents and settings\neelyd\my documents\visual studio projects\exception\exception\form1.cs:line 96
at System.Windows.Forms.Control.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ButtonBase.WndProc(Message& m)
at System.Windows.Forms.Button.WndProc(Message& m)
at System.Windows.Forms.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

************** Loaded Assemblies **************
mscorlib
Assembly Version: 1.0.5000.0
Win32 Version: 1.1.4322.2032
CodeBase: file:///c:/windows/microsoft.net/framework/v1.1.4322/mscorlib.dll

Exception
Assembly Version: 1.0.2312.14759
Win32 Version: 1.0.2312.14759
CodeBase: file:///C:/Documents%20and%20Settings/neelyd/My%20Documents/Visual%20Studio%20Projects/Exception/Exception/bin/Debug/Exception.exe

System.Windows.Forms
Assembly Version: 1.0.5000.0
Win32 Version: 1.1.4322.2032
CodeBase: file:///c:/windows/assembly/gac/system.windows.forms/1.0.5000.0__b77a5c561934e089/system.windows.forms.dll

System
Assembly Version: 1.0.5000.0
Win32 Version: 1.1.4322.2032
CodeBase: file:///c:/windows/assembly/gac/system/1.0.5000.0__b77a5c561934e089/system.dll

System.Drawing
Assembly Version: 1.0.5000.0
Win32 Version: 1.1.4322.2032
CodeBase: file:///c:/windows/assembly/gac/system.drawing/1.0.5000.

[S Senthil Kumar]

I haven't been able to figure out why this is happening, but the thing causing the difference in behavior is the presence of a debugger attached to the process. Even within VS .NET, if you hit Ctrl+F5 (Start without debugging), you can observe the same behavior. Regards Senthil _____________________________ My Blog | My Articles | My Flickr | WinMacro

[Roy Heil]

Warning: I am guessing here. Your try is in the Main() function, around the Application.Run. At the application level, there is a global exception handler, which handles exceptions that reach it without being handled in code. When you run the application from the .exe (i.e. not in Visual Studio), the default exception handler is reached without being handle in the application, so you get the unhandled exception dialog. Notice that if you select "continue", the application continues to run, because Application.Run was never exited, and your catch was not used. Now, when you run your application from Visual Studio, I think that Visual Studio has it's own exception handler (outside the Main() function), and the applications default exception handler is turned off. Thus when you throw your exception, it reaches your catch before it gets to VS's handler. This also explains why the application ends after your MessageBox, because your exception execution to exit the Application.Run. Roy.

[Dan Neely]

That sounds like a plausable guess, do you have any thoughts on a way to work around the problem that doesn't involve slapping try/catch blocks inside every event handler? Not having to clutter my code up that way was one of the main reasons I moved it there. The second was related to forcing a shutdown, but I don't recall exactly what it was.

[Roy Heil]

Try this. Instead of wrapping your Application.Run in a try..catch, write a new exception handler. (If I recall correctly, you wanted the application to end after an exception? That is the reason for the Application.Exit(). If you don't want this, go ahead and remove it.) Good luck. static void Main() { Application.ThreadException += new ThreadExceptionEventHandler( MyExceptionHandler); Application.Run(new Form1()); } private static void MyExceptionHandler(object sender, System.Threading.ThreadExceptionEventArgs e ) { MessageBox.Show(e.Exception.Message); Application.Exit(); } Roy.

[Dan Neely]

Thank you. That worked perfectly. It's always the feature I never knew existed that are the biggest problem. :-/

[Dan Neely]

actually it turns out I still do need the try/catch block. Application.ThreadException doesn't catch anything generated from a static class that initializes while the form constructor is running.