<p>I'm maintaining a .NET 1.1 application and one of the things I've been tasked with is making sure the user doesn't see any unfriendly error notifications.</p>

<p>I've added handlers to <code>Application.ThreadException</code> and <code>AppDomain.CurrentDomain.UnhandledException</code>, which do get called. My problem is that the standard CLR error dialog is still displayed (before the exception handler is called).</p>

<p>Jeff talks about this problem on his blog <a href="https://blog.codinghorror.com/console-apps-and-appdomain-currentdomain-unhandledexception/" rel="noreferrer">here</a> and <a href="https://blog.codinghorror.com/improved-unhandled-exception-behavior-in-net-20/" rel="noreferrer">here</a>. But there's no solution. So what is the standard way in .NET 1.1 to handle uncaught exceptions and display a friendly dialog box?</p>

<p>Jeff's response was marked as the correct answer because the link he provided has the most complete information on how to do what's required.</p>

[{'answer_id': 986, 'author': 'Jeff Atwood', 'author_id': 1, 'author_profile': 'https://Stackoverflow.com/users/1', 'pm_score': 2, 'selected': False, 'text': '<p>Is this a console application or a Windows Forms application? If it\'s a .NET 1.1 console application this is, sadly, by design -- it\'s confirmed by an MSFT dev in the <a href="https://blog.codinghorror.com/improved-unhandled-exception-behavior-in-net-20/" rel="nofollow noreferrer">second blog post you referenced</a>:</p>\n\n<blockquote>\n  <p>BTW, on my 1.1 machine the example from MSDN does have the expected output; it\'s just that the second line doesn\'t show up until after you\'ve attached a debugger (or not). In v2 we\'ve flipped things around so that the UnhandledException event fires before the debugger attaches, which seems to be what most people expect.</p>\n</blockquote>\n\n<p>It sounds like .NET 2.0 does this better (thank goodness), but honestly, I never had time to go back and check.</p>\n'}, {'answer_id': 990, 'author': 'Ray', 'author_id': 233, 'author_profile': 'https://Stackoverflow.com/users/233', 'pm_score': 1, 'selected': False, 'text': "<p>It's a Windows Forms application. The exceptions that are caught by Application.ThreadException work fine, and I don't get the ugly .NET exception box (<kbd>OK</kbd> to terminate, <kbd>Cancel</kbd> to debug? who came up with that??).</p>\n\n<p>I was getting some exceptions that weren't being caught by that and ended up going to the AppDomain.UnhandledException event that were causing problems. I think I've caught most of those exceptions, and I am displaying them in our nice error box now.</p>\n\n<p>So I'll just have to hope there are not some other circumstances that would cause exceptions to not be caught by the Application.ThreadException handler.</p>\n"}, {'answer_id': 1016, 'author': 'Jeff Atwood', 'author_id': 1, 'author_profile': 'https://Stackoverflow.com/users/1', 'pm_score': 5, 'selected': True, 'text': '<p>Oh, in Windows Forms you definitely should be able to get it to work. The only thing you have to watch out for is things happening on different threads.</p>\n\n<p>I have an old Code Project article here which should help:</p>\n\n<p><em><a href="http://www.codeproject.com/KB/exception/ExceptionHandling.aspx" rel="nofollow noreferrer">User Friendly Exception Handling</a></em></p>\n'}, {'answer_id': 1114, 'author': 'Ishmaeel', 'author_id': 227, 'author_profile': 'https://Stackoverflow.com/users/227', 'pm_score': 3, 'selected': False, 'text': '<p><strong>AppDomain.UnhandledException</strong> is an <strong>event</strong>, not a global exception handler. This means, by the time it is raised, your application is already on its way down the drain, and there is nothing you can do about it, except for doing cleanup and error logging.</p>\n\n<p>What happened behind the scenes is this: The framework detected the exception, walked up the call stack to the very top, found no handlers that would recover from the error, so was unable to determine if it was safe to continue execution. So, it started the shutdown sequence and fired up this event as a courtesy to you so you can pay your respects to your already-doomed process. This happens when an exception is left unhandled in the main thread.</p>\n\n<p>There is no single-point solution to this kind of error. You need to put a real exception handler (a catch block) upstream of all places where this error occurs and forward it to (for example) a global handler method/class that will determine if it is safe to simply report and continue, based on exception type and/or content.</p>\n\n<p>Edit: It is possible to disable (=hack) the error-reporting mechanism built into Windows so the mandatory "crash and burn" dialog does not get displayed when your app goes down. However, this becomes effective for <em>all</em> the applications in the system, not just your own.</p>\n'}, {'answer_id': 108550, 'author': 'HTTP 410', 'author_id': 13118, 'author_profile': 'https://Stackoverflow.com/users/13118', 'pm_score': 3, 'selected': False, 'text': '<p>Unhandled exception behavior in a .NET 1.x Windows Forms application depends on:</p>\n\n<ul>\n<li>The type of thread that threw the exception</li>\n<li>Whether it occurred during window message processing</li>\n<li>Whether a debugger was attached to the process</li>\n<li>The DbgJitDebugLaunchSetting registry setting</li>\n<li>The jitDebugging flag in App.Config</li>\n<li>Whether you overrode the Windows Forms exception handler</li>\n<li>Whether you handled the CLR’s exception event</li>\n<li>The phase of the moon</li>\n</ul>\n\n<p>The default behavior of unhandled exceptions is:</p>\n\n<ul>\n<li>If the exception occurs on the main thread when pumping window messages, it\'s intercepted by the Windows Forms exception handler.</li>\n<li>If the exception occurs on the main thread when pumping window messages, it will terminate the app process unless it\'s intercepted by the Windows Forms exception handler.</li>\n<li>If the exception occurs on a manual, thread-pool, or finalizer thread, it\'s swallowed by the CLR.</li>\n</ul>\n\n<p>The points of contact for an unhandled exception are: </p>\n\n<ul>\n<li>Windows Forms exception handler.</li>\n<li>The JIT-debug registry switch DbgJitDebugLaunchSetting.</li>\n<li>The CLR unhandled exception event.</li>\n</ul>\n\n<p>The Windows Form built-in exception handling does the following by default:</p>\n\n<ul>\n<li>Catches an unhandled exception when:\n\n<ul>\n<li>exception is on main thread and no debugger attached.</li>\n<li>exception occurs during window message processing.</li>\n<li>jitDebugging = false in App.Config.</li>\n</ul></li>\n<li>Shows dialog to user and prevents app termination.</li>\n</ul>\n\n<p>You can disable the latter behavior by setting jitDebugging = true in <code>App.Config</code>. But remember that this may be your last chance to stop app termination. So the next step to catch an unhandled exception is registering for event Application.ThreadException, e.g.:</p>\n\n<pre><code>Application.ThreadException += new\nThreading.ThreadExceptionHandler(CatchFormsExceptions);\n</code></pre>\n\n<p>Note the registry setting DbgJitDebugLaunchSetting under HKEY_LOCAL_MACHINE\\Software.NetFramework. This has one of three values of which I\'m aware:</p>\n\n<ul>\n<li>0: shows user dialog asking "debug or terminate".</li>\n<li>1: lets exception through for CLR to deal with.</li>\n<li>2: launches debugger specified in DbgManagedDebugger registry key.</li>\n</ul>\n\n<p>In Visual Studio, go to menu <em>Tools</em> → <em>Options</em> → <em>Debugging</em> → <em>JIT</em> to set this key to 0 or 2. But a value of 1 is usually best on an end-user\'s machine. Note that this registry key is acted on before the CLR unhandled exception event.</p>\n\n<p>This last event is your last chance to log an unhandled exception. It\'s triggered before your Finally blocks have executed. You can intercept this event as follows:</p>\n\n<pre><code>AppDomain.CurrentDomain.UnhandledException += new\nSystem.UnhandledExceptionEventHandler(CatchClrExceptions);\n</code></pre>\n'}, {'answer_id': 70889762, 'author': 'Umar Hassan', 'author_id': 1520030, 'author_profile': 'https://Stackoverflow.com/users/1520030', 'pm_score': 0, 'selected': False, 'text': "<p><strong>The Short Answer,</strong>\n<em>Looks like, an exception occurring in Form.Load doesn't get routed to Application.ThreadException or AppDomain.CurrentDomain.UnhandledException without a debugger attached.</em></p>\n<p><strong>The More accurate Answer/Story</strong>\nThis is how I solved a similar problem. I can't say for sure how it does it, but here is what I think. Improvement suggestions are welcome.</p>\n<p>The three events,</p>\n<ol>\n<li>AppDomain.CurrentDomain.FirstChanceException</li>\n<li>AppDomain.CurrentDomain.UnhandledException</li>\n<li>and Application.ThreadException</li>\n</ol>\n<p>accumulatively catch most of the exceptions but not on a global scope (as said earlier). In one of my applications, I used a combination of these to catch all kinds of exceptions and even the unmanaged code exceptions like DirectX exception (through SharpDX). All exceptions, whether they are caught or not, seem to be invoking FirstChanceException without a doubt.</p>\n<pre><code>AppDomain.CurrentDomain.FirstChanceException += MyFirstChanceExceptionHandler;\nApplication.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException); // not sure if this is important or not.\nAppDomain.CurrentDomain.UnhandledException += CurrentDomain_UnhandledException; // can't use Lambda here. need to Unsub this event later.\nApplication.ThreadException += (s, e) =&gt; MyUnhandledExceptionHandler(e.Exception);\n\nstatic void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)\n{\n    MyUnhandledExceptionHandler((Exception)e.ExceptionObject);\n}\nprivate void CurrentDomain_FirstChanceException(object sender, System.Runtime.ExceptionServices.FirstChanceExceptionEventArgs eventArgs)\n{\n    // detect the pattern of the exception which we won't be able to get in Fatal events.\n    if (eventArgs.Exception.Message.StartsWith(&quot;HRESULT&quot;))\n        MyUnhandledExceptionHandler(eventArgs.Exception);\n}\n</code></pre>\n<p>and the handler looks like</p>\n<pre><code>static void MyUnhandledExceptionHandler(Exception ex)\n{\n    AppDomain.CurrentDomain.UnhandledException -= MyUnhandledExceptionHandler;  // this is important. Any exception occuring in the logging mechanism can cause a stack overflow exception which triggers the window's own JIT message/App crash message if Win JIT is not available.\n    // LogTheException()\n    // Collect user data\n    // inform the user in a civil way to restart/close the app\n    Environment.Exit(0);\n}\n</code></pre>\n<p>Unmanaged code exceptions like DirectX exceptions appeared only in FirstChanceException where I had to decide for myself if the exception was fatal or not. I then use MyUnhandledExceptionHandler to log and let the user know in a friendly way that everything was &quot;under control&quot;.</p>\n<p><strong>IMPORTANT NOTE!</strong>\nThe scheme still didn't catch one kind of exception. It did appear in FirstChanceException, but it was hard to distinguish it from other kinds of exceptions hitting this handler. Any exception occurring directly in Form.Load had this different behavior. When the VS debugger was attached, these were routed to the UnhandledException event. But without a debugger, an old-school windows message will pop up, showing the stack trace of the exception that occurred. The most annoying thing was that it didn't let MyUnhandledExceptionHandlerr get kicked once it was done and the app continued to work in an abnormal state. The final solution I did was to move all the code from Form_load to another thread using <code>MyForm.Load += (s,e) =&gt; new Thread(()=&gt;{/* My Form_Load code*/ }).Start();</code>. This way, Application.ThreadException gets triggered which is routed to MyUnhandledExceptionHandler, my safe exit.</p>\n"}]
['https://Stackoverflow.com/questions/944', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/233/']